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>

website/TEAMS.md

@@ -1826,9 +1826,8 @@ identical to `announce` and `mod-reverse`.
 > worker is a great deal of machinery to buy the opposite outcome.
 >
 > **The admin surface is its own panel under Admin → Teams**, beside the forum settings, and not an
-> extension of the Discord Bot panel — a second integration would make the platform a registry lookup
-> (§8.2), and what should change then is what fills the panel, not where it is. That holds whether or
-> not the capability layer is ever built; Phase 10, which would have built it, is cancelled. It is **admin-only**, the one such corner of a
+> extension of the Discord Bot panel — phase 10 makes the platform a registry lookup, and what should
+> change then is what fills the panel, not where it is. It is **admin-only**, the one such corner of a
 > staff-wide router: configuring where a Team's content leaves the site for is deployment
 > configuration rather than the §2.9 kind of decision a moderator files a request for.
 
@@ -2116,14 +2115,6 @@ installed.
 **No Matrix implementation is built.** §8 is research to shape the Discord contract, exactly as the
 brief asks.
 
-> **And no capability registry is built either** (2026-08-19). Phase 10 would have extracted the one
-> above from Phases 7–9's Discord code; it is cancelled and deferred until a second integration is
-> wanted. Everything in §8 stays as it is — the comparison is what makes the *shape* of the Discord
-> work defensible, and it did its job by keeping core's calls phrased as eligibility questions rather
-> than as Discord operations. What is not there is the indirection: `discord` is named directly in the
-> bridge, the voice provisioner and the command dispatcher, and a second platform is a phase, not a
-> configuration change.
-
 ---
 
 ## Part 9 — The explicit answers
@@ -2410,9 +2401,6 @@ makes §0.1's roster possible:
 Every phase is independently shippable and leaves the site working. Phases 1 and 2 are the only hard
 serial dependency in the list.
 
-**Phase 10 is cancelled** (org lead, 2026-08-19), deferred until a second integration is wanted or
-it is asked for by name — see its own entry. Phase 11 is therefore the last phase of the bet.
-
 **Phase 11 is the exception to "independently shippable", and it is last on purpose** (org lead,
 2026-08-18). The integration kit teaches an outside audience to build against this contract; Teams
 expands the contract, so the book is the last thing owed before `edge` becomes `main`. It is also the
@@ -2824,11 +2812,8 @@ does not move.
 #### Where the admin surface lives, and why it is not in the Discord panel
 
 Its own panel under **Admin → Teams**, beside the forum settings, rather than an extension of
-`DiscordBotAdmin`. A second platform would replace "Discord" with whatever a capability registry
-declares (§8.2); what should change then is what fills the panel, not where an operator goes to find
-it. Phase 10 would have built that registry and is cancelled — which changes nothing here, because
-the reason this panel is not inside the Discord one is that an operator should not have to know which
-platform is configured to find it. It is the one
+`DiscordBotAdmin`. Phase 10 replaces "Discord" with whatever the capability registry declares; what
+should change then is what fills the panel, not where an operator goes to find it. It is the one
 **admin-only** corner of a staff-wide router: this is not the §2.9 kind of decision a moderator files
 a request for, it is deployment configuration, and it sits with the role that already holds the bot
 token.
@@ -2907,35 +2892,13 @@ and an admin removal working anyway, with a 404 for a Team that has none.
   moves §3's public freshness banner as much as this phase's suspension. Pre-existing and not fixed
   here; recorded because it is invisible until something depends on it.
 
-### Phase 10 — the capability layer (`website` + `docs`) — **CANCELLED 2026-08-19**
-
-> **Not built, and not scheduled.** The org lead cancelled this phase after Phase 9, deferring it
-> until a second integration is actually wanted or it is asked for by name. What follows is what it
-> would have done, kept because the argument for it survives its cancellation.
+### Phase 10 — the capability layer (`website` + `docs`)
 
 Refactor Phases 7–9's Discord code behind the declared-capability registry (§8.2) and prove it by
 rendering the admin UI from the declaration rather than from a hardcoded "Discord" assumption. Last on
 purpose: extracting a capability surface from one working implementation is honest; designing it before
 one exists is speculation.
 
-**Why cancelling it costs little.** The same argument that put it last is the argument for not doing it
-yet: with exactly one integration built, the refactor would extract a capability surface from a single
-implementation and have nothing to check the extraction against. §8.2's Matrix column is research, not
-a second implementation, and a registry whose only consumer is the thing it was extracted from is a
-layer of indirection that has not yet been paid for. The work is cheaper *and* better-informed the day
-a second platform exists, because that platform is what proves which of the five capabilities the
-seam actually needs.
-
-**What it leaves behind, stated so nobody has to re-derive it.** Phases 7–9 name Discord directly —
-in the bridge config (`team_discord_config`), the voice provisioner, the slash-command dispatcher and
-their admin panels. That is not a defect and no code is placed differently in anticipation of a layer
-that may never come. Two decisions were made *for* this phase, and both stand on their own:
-the notification bridge and the voice panel live under **Admin → Teams** rather than inside the
-Discord Bot panel (§7.2, §7.3), because where an operator goes to find them should not depend on which
-platform fills them; and core's calls are already phrased as questions about eligibility — *these user
-ids are eligible for Team 3* — rather than as instructions about overwrites. A second integration
-would be a new phase against that surface, not a rescue of this one.
-
 ### Phase 11 — the integration kit (`integration-kit`) — **the last phase before the cutover**
 
 The kit is the instruction book for putting a *different* game on this platform, written for an
@@ -2969,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