website/TEAMS.md

@@ -1824,8 +1824,9 @@ 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 — 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
+> 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
 > 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.
 
@@ -2113,6 +2114,14 @@ 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
@@ -2399,6 +2408,9 @@ 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
@@ -2807,8 +2819,11 @@ 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`. 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
+`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
 **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.
@@ -2887,13 +2902,35 @@ 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`)
+### 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.
 
 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