website/EVENTS_PLAN.md

@@ -15,6 +15,14 @@ UO actions, the integrations, the authoring UI, the public surface — needed no
 Those fourteen phases reach the game only to *announce*, over verbs the write plane already carries; nothing in them creates or
 changes a thing in the world.
 
+**COMPLETE as of 2026-09-10.** All seventeen phases are built and on `main` in every repository they
+touch. P16 ran as three legs — **16a** the acceptance walk from `edge`, **16b** the six-step cutover
+and the re-verify against released artefacts, **16c** `runicgateway.com` and `.profile` — and 16c
+opened by closing the seventh cutover step 16b had left standing (`docs#232`). The platform the
+workstream leaves behind is sidecar **v2.2.0**, overlay **v1.2.0**, bundle **2026.09.10** on
+**protocol 7**, `Module-uo` **v1.2.2**, and `MODULE_API_VERSION` **1.10.0**. Each phase's record is
+in its own section below; `edge` stays standing, unused, in every repository.
+
 ---
 
 ## Before anything: three facts about the ground
@@ -2025,6 +2033,75 @@ core, docs, then the kit's re-pin and `runicgateway.com`.
 - **`.profile`** — the org landing page is updated when the *shape* of the project changes, which a new
   subsystem is.
 
+> **16c BUILT (2026-09-09/10) — and it began by closing the cutover's missing seventh step.**
+> `runicgateway.com#30` and `.profile#6`, both onto `main`; the leg's first act was `docs#232`.
+>
+> #### The step 16b left on `edge`
+>
+> Six repositories were cut over and every one of them showed **0 commits on `edge` that are not on
+> `main`**. This one showed **46**. Step 6 (`#231`) landed the record *on* `edge` rather than cutting
+> `edge` over — an easy thing to miss, because the step's own PR merged green and closed. The
+> consequence was quiet and total: `docs` `main` opened `EVENTS.md` with *"revision 5. **No code
+> written.** Read against … `MODULE_API_VERSION` 1.9.0 · sidecar protocol 5"* while six repositories
+> shipped the engine on protocol 7, and `link/v6.md` and `v7.md` — the specs of record for two
+> protocol versions — existed on no default branch anywhere.
+>
+> **Nothing in this workstream could have caught it.** Every check that guards a contract lives in
+> the repository that *depends* on the contract, and a documentation repository has no dependants.
+> What found it was the one check that reads `docs` from outside: `runicgateway.com`'s
+> `checkReference.mjs` asserts every canonical document it names still exists on `main`, and adding
+> the current protocol spec failed with `✗ canonical doc link/v7.md`. **The site is the docs
+> repository's only dependant, and 16c is the only phase that would ever have run that check.**
+>
+> The merge was clean, and both `PROJECT_TREE.md` files stayed on `main`'s newer automated syncs —
+> `edge` never edited them, so git kept `main`'s side. `edge` stays standing, per 16b's decision,
+> now four generated commits behind.
+>
+> #### The site
+>
+> The checks were red before the phase started and named their own answers, which is the whole
+> bargain §12 of that repository's plan struck: nine `checkFacts` values (protocol 5 → **7** in all
+> three declaration sites, `moduleApi` → **1.10.0**, the bundle triple, `link` **v2.2.0**, `Module-uo`
+> **v1.2.2** — a third module release, one past the v1.2.1 the cutover cut), and **twenty-seven
+> `Bridge.cfg` keys** the site listed nowhere. Those became five groups rather than an appendix,
+> because `EventsEnabled` is a *second consent switch* and belongs beside the ceilings it governs
+> rather than filed under `AdminWriteEnabled`.
+>
+> Two pages, the treatment Teams has: **Scheduled events** under Administration and **Events
+> architecture**. Two capability entries, so the homepage, `/features/` and `/modules/` stop omitting
+> the subsystem — and the calendar one is deliberately **not** `needsModule`, because a bare core can
+> author and run an event and that marker means "present, correct and permanently empty".
+>
+> **`/privacy` owed a row and had none.** `event_run_participants` is personal data — scores and
+> ranks against a module-opaque member key, linked to an account where one is linked, feeding a
+> participant's own history. The new `deploy-events` row states the retention exactly, including the
+> asymmetry that matters: the diagnostic log is swept after 90 days **and only on terminal runs**,
+> while the run, its steps and its participants are never swept, because they are the record of what
+> was done to a shared world.
+>
+> **A naming collision worth fixing while it was cheap.** `reference/event-catalog` is about what a
+> shard *emits*; with a scheduled-event system shipped, two things in the documentation were called
+> an event catalog. Retitled **"Shard event catalog"**, with the route left alone so nothing outside
+> that repository breaks — and the page now opens by saying which of the two it is, since the kinds
+> it lists are exactly what a phase can wait for.
+>
+> **No screenshots**, and stated as a choice: capturing the events surfaces means standing the whole
+> rig back up for images no check requires, and the engagement workstream's site leg added none
+> either.
+>
+> #### `.profile`
+>
+> One bullet, and two stale numbers. The bullet says the posture rather than the feature list — off
+> by default, caps in the database, cleanup generated from a ledger, and *an event does not edit the
+> world, it holds a lease the game restores on its own deadline*. The numbers are protocol **5 → 7**
+> in the four values the installer prints (the block a reader copies into Admin → Shard, where a
+> wrong number is a pairing failure with no obvious cause) and **module-uo v1.1.0 → v1.2.2**.
+>
+> #### What 16c did not need
+>
+> No `EVENTS.md` change, no `MODULE_API_VERSION` change, no protocol change, no release. The phase
+> moves no contract — it makes the ones already moved legible from outside the organisation.
+
 ---
 
 ## What this plan does not do