From 88cc49225a06b351d745b1dd204e05ce70202fc7 Mon Sep 17 00:00:00 2001 From: wtclaude Date: Wed, 19 Aug 2026 00:27:22 -0500 Subject: [PATCH] docs(teams): cancel phase 10, and say what that leaves behind The org lead cancelled the capability layer on 2026-08-19, deferring it until a second integration is wanted or it is asked for by name. Phase 11 is now the last phase of the bet. The same argument that put phase 10 last is the argument for not doing it yet: with one integration built, the refactor would extract a capability surface from a single implementation and have nothing to check the extraction against. It is cheaper and better-informed the day a second platform exists, because that platform is what proves which of the five capabilities the seam needs. Three places pointed forward at it and now say what is true instead: - Sec 7.2 and Sec 7.3 both justify the Admin -> Teams panels by "phase 10 makes the platform a registry lookup". The decision survives its reason: an operator should not have to know which platform is configured to find the panel, and that holds whether or not the registry is ever built. - Sec 8.2 keeps the Matrix comparison and the capability table, with a note that no registry is built either. The research did its job by keeping core's calls phrased as eligibility questions rather than as Discord operations; what is absent is the indirection, so `discord` is named directly in the bridge, the voice provisioner and the command dispatcher. The phase entry keeps its body rather than deleting it, because the argument for the layer is what a future phase would start from. Co-Authored-By: Claude --- website/TEAMS.md | 47 ++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 42 insertions(+), 5 deletions(-) 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