Docs-Sync
Every RoboCo release changes something the docs site ought to reflect — a new flag, a new page, a changed default. Nothing enforces that automatically unless you ask it to. Docs-sync watches for the moment a release publishes and, if the docs site looks like it's drifted, opens one docs-update task into the normal delivery flow — the same PM → dev → QA → PR-review → merge path any other task takes.
It's off by default.
What it does
- Release-triggered, not a background loop. Docs-sync doesn't poll on an interval — it hooks directly into the gated release manager's publish step. The moment a release actually publishes, it checks whether the docs site needs an update and, if so, opens exactly one task carrying the new version and the release's own changelog as context.
- Rides the real delivery lifecycle. The task it opens is a normal Main-PM coordination root against the docs site's own project — it gets decomposed, claimed, built, QA'd, and passes through the in-path PR-review gate like any other task. There's no special-cased shortcut for docs work.
- Never auto-merges. Docs-sync's job ends at opening the task. The resulting PR still needs your merge (or your PM's, per the normal lifecycle) — same posture as self-heal and the CI-watch / dependency-update bots: detect and queue, never publish on its own.
- Bounded. A rolling cap on open docs-sync tasks and a per-cycle cap on how many it opens keep a run of releases from flooding the docs project with duplicate work.
Docs-sync opens its task against a real RoboCo project record for the docs site — it needs that project to exist, with a git token configured, so a dev agent can actually clone it and open a PR. If the docs site isn't registered as a project yet, docs-sync silently skips (logged, not an error) rather than failing the release.
Enable it
Register your docs site as a project first (Workstation → Projects, with a git token set), then Settings → Feature Flags → "Docs sync".
The feature flag persists in the settings store and applies on the next backend restart. It only matters at your next release publish either way.
See the environment reference for the full flag list.
What changes when it's on
- With the flag off, publishing a release never opens a docs-update task — you'd need to notice and update the docs site yourself.
- With the flag on and the docs site registered, a publish checks for drift and, when it finds some, queues one task for a PM to pick up — the update still ships through the exact same review and merge gates as any other change.
- Without a registered docs-site project, the flag being on changes nothing observable — it skips every time, quietly.
Next
→ Autonomous Maintenance — the gated release manager whose publish step docs-sync hooks into. → PR Review — the gate the resulting docs PR still passes through. → Workstation — where you register the docs site as a project. → back to Optional subsystems.