diff --git a/website/TEAMS.md b/website/TEAMS.md index 650ab2c..06f5f9b 100644 --- a/website/TEAMS.md +++ b/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