The automatically managed command and feature inventories follow the newest healthy deployed room-worker release, not just the shared supervisor's version. A fresh worker heartbeat must establish the running version, the immutable release must have passing sealed validation and compatible shared contracts, and its reviewed documentation manifest must match its source fingerprints before verified facts are published. A queued target is not deployment evidence.
The shared supervisor still has its separate successful-deployment check. The preparation job reads only a read-only binding of sanitized public worker status; it does not read player databases, credentials or chat, import bot code, call osu! or operate the bot. It writes a short-lived root-owned deployment attestation for the wiki-only publisher. The publisher checks that attestation, source version, shared-supervisor link, page locks and ownership hashes before native revisions.
The check runs every five minutes. An unchanged inventory creates no new article revisions or drafts. Statistics and occupancy history update every five minutes; current lobby status uses its separate ten-second exporter.
Compatible per-room rollouts in v6.7 can leave lobbies on different versions. The verified inventory describes the newest reviewed release with healthy deployed-worker evidence, not a guarantee that every room has reached it. The freshness notice identifies that inventory version, the observed worker-version range and the shared supervisor separately. Check each room title for availability. A queued release can have authored release notes and an upcoming article without becoming the current verified command inventory.
Detailed explanations, diagrams, worked examples, troubleshooting, and historical patch-note summaries remain authored articles. Their Behavior reference records when that explanatory text was reviewed. A verified inventory does not imply every linked paragraph was rereviewed.
After a new verified inventory is published, a small draft job compares it with the previous verified manifest. It prepares a private release review packet for editors and maintainers: changed commands, features, style spellings, affected articles, source fingerprints, and suggested checks. It never publishes explanatory prose. Maintainers review the live behavior and save article changes as normal wiki revisions.
No writing model or API integration is enabled. The draft job uses templates and the reviewed manifest; it cannot establish behavior that the manifest did not describe.
A queued or failed deployment does not become current documentation. Stale or unhealthy worker evidence, incompatible or altered sealed code, a missing reviewed manifest or linked article, a source fingerprint mismatch, changed/expired attestation, or an editing conflict keeps the previous inventory and shows verification pending. Older facts remain readable with their verified version identified. The legacy successful shared-release gate remains for installations without rolling workers.
Maintainers resolve the cause and rerun the update. Automatically managed tables are protected against silent overwrites: changing one creates a conflict. Propose corrections through the manifest, or edit the ordinary explanation surrounding the table. Existing explanations and contributor edits outside the generated command table are preserved.
Add a reviewed documentation manifest to a staged release as docs/wiki-manifest.json. It records player commands, syntax, mode-specific aliases, permissions, feature gates, timing, feature links, and source fingerprints. Validate it against that staged release before queuing deployment. The publishing service has wiki write access and no bot deployment or restart authority.
See the documentation health report for broken links and editorial review candidates.
See command reference, feature inventory, release history, and contributing.
Maintainer-reviewed future commands can appear as explicitly labeled editorial supplements in the command reference and the room-worker feature guide, with detailed guides and minimum-version labels. The finder combines the supplement and generated table without duplicate cards. Once a reviewed release is deployed and verified, its commands and facts enter the generated inventory automatically. This never bypasses fingerprint, deployment or editing-conflict checks and does not claim that every room runs the latest worker.