docs(teams): phase 11 as built, and what the rig walk found

The phase ran before the cutover as Part 12 planned, and found what it was meant
to: the inverted slot direction worked for module-uo and nobody else. Recorded
beside the phase entry, with the org lead's two decisions of the day - core
offers a contribution rather than naming a slot, and the template grows a real
provider rather than a snippet.

Also records the live-rig walk and the one defect it found that no test could:
PageHeader takes `lead`, not `subtitle`, and React drops an unknown prop in
silence, so every page built from the kit's template had been rendering its
heading with nothing under it.

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
2026-08-19 01:31:52 -05:00
parent d10f5809b3
commit 2adf397da4

View File

@@ -2932,6 +2932,35 @@ members and has never mentioned `registerNotificationStreams`, `registerAnnounce
The question this phase answers is "did the teaching path change", and the answer is yes in two
places and no everywhere else.
> **Amended 2026-08-19, as built.** The phase ran before the cutover, as planned, and it found what it
> was meant to find. Four notes.
>
> **The inverted slot did not work for anyone but `module-uo`, and the kit is what proved it.** Core
> filled three literal `uo.guild.*` names, so a second game's module declared its places under its own
> id and core filled none of them — an empty page, no error, nothing logged, because *"a fill for a
> slot nobody declared is not an error"* is exactly the rule that hides an unknown name. Settled by the
> org lead the same day: **core offers a CONTRIBUTION and never names a slot**, amended into 1.6.0 in
> place since it has only ever been on `edge` (website#160, Module-uo#15, docs#165). The kit could not
> have taught the shape honestly without this, which is the argument for having written the book
> before the cutover rather than after it.
>
> **The template grew a real provider rather than a snippet** (org lead, 2026-08-19). It registers
> `registerTeamProvider` over two tables of its own, declares three slots on a clan page, and serves
> its own `/clans` — deliberately not `/teams`, which is core's and which the loader would refuse. The
> guards that matter are the ones a reader would otherwise omit: an unreachable game refuses rather
> than reporting no clans, an empty roster is refused unless the game says the clan is empty, and one
> audience rule serves both `projectRoster` and the module's own page.
>
> **It was walked on a live rig before the PRs opened** — real MariaDB, the real loader, a browser.
> Core reconciled two Teams out of the provider on the first boot, `/public/teams/<slug>/members`
> answered `projected: true`, and the clan page rendered core's activity feed and forum in the slots
> the module declared. `module-uo`'s guild page was walked on the same core and is unchanged. The walk
> found one defect no test could: `PageHeader` takes `lead`, not `subtitle`, and React drops an unknown
> prop silently — so every page built from the template had rendered its heading with nothing under it
> since the template was written.
>
> **Phase 10's cancellation makes this the last phase**, and nothing in it changed as a result.
**Then the two mechanical lines:** `ci/core-ref.json`'s sha moves to the cutover commit and
`template/module.json`'s `coreApi` becomes `^1.6.0`, which puts `scripts/checkCoreApi.js` back to
green. That check is an **equality**, and its going red is the mechanism rather than a bug — a