2GT-RichandClaude Opus 5
e10f7ba568
Documentation only — no functional change.
The README was carrying two jobs for two different readers. Its Reference section was
the single largest block at 154 lines, and nobody deciding whether to try the project
reads an InfluxDB environment variable table — while the people who need it were
scrolling past the pitch to reach it.
Split along that seam: anything you would read before installing stays in the README,
anything you would read after installing moves to docs/.
README.md 430 lines sell, prove, install, feature overview
docs/change-guard.md 193 safety system, settings, guard states
docs/architecture.md 116 data stores, polling model, module layout
docs/capsman.md 84 role model, radio matching, current limits
docs/alerting.md 81 rules, channels, webhooks, maintenance windows
docs/api.md 77 scoped tokens, preflight, scripting
docs/configuration.md 76 environment, secrets, rotation, TLS
docs/sso-oidc.md 71 identity provider setup and behaviour
docs/README.md 20 index
In-repo rather than a documentation site, deliberately. A change to Change Guard's
semantics can edit its documentation in the same commit as the code — which, given how
often that behaviour has been refined recently, is the property that actually matters.
A static site generator can point at docs/ later without moving a file.
The Change Guard pitch stays on the front page: the problem framing, the verified
recovery timeline and the quoted prediction warning are what make someone care, and a
reference page is the wrong home for them.
Three sections are new rather than relocated, written because the split exposed the gaps:
- architecture.md did not exist. It now records why there are three data stores, the
polling cadences, and which modules are pure functions over a snapshot and why.
- Scoped API tokens shipped without usage documentation. api.md shows preflighting a
change from a script and reading the guard block afterwards.
- change-guard.md records why ip-on-bridge-port is informational rather than critical
on RouterOS 7 — reasoning that previously existed only in a commit message.
Every internal anchor and cross-file link verified to resolve, including anchors into
other documents. No content dropped, checked by keyword comparison against the previous
single file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MikroTik Manager documentation
Reference material for people already running the platform. If you are still deciding whether to try it, the project README is the better starting point.
| Document | Covers |
|---|---|
| Configuration | Environment variables, secret management and key rotation |
| Change Guard and Config Health | How the safety system works, its settings, and what to expect when it fires |
| Alerting | Alert rules, delivery channels, webhooks, scheduled reports, maintenance windows |
| Single sign-on (OIDC) | Identity provider setup, group-to-role mapping, break-glass behaviour |
| CAPsMAN | How centrally provisioned access points are modelled, and current limits |
| API and automation | Scoped tokens, authentication, and driving the platform from scripts |
| Architecture | How the system is put together, for contributors |
Conventions used here
- Settings in the UI are stored in the database and apply without a restart.
- Environment variables live in
.envand require a container restart to change. - Anything described as read-only makes no writes to your devices.