docs(teams): queue the integration kit as phase 11, last before the cutover #160

wtclaude · 2026-08-18T23:19:10Z

wtclaude commented

2026-08-18 23:19:10 +00:00

Plan-only, one file. Into edge. Follows docs#159 — this commit was pushed just after you merged that one, so it did not ride along.

Adds Phase 11 — the integration kit, on your call to queue it as the last phase before the edge→main cutover.

Why it belongs in the plan rather than an issue

The kit is the instruction book for putting a different game on this platform, written for an audience outside this org. Teams expands the contract that book teaches against, so the book is the last thing this bet owes before the cutover.

One sentence in it is already wrong

book/02-website-module.md tells the reader that core declares a slot and a module may only fill one. Phase 3 inverted exactly that — with declareModuleSlot a module declares a place on its own page and core fills it — and by phase 6 module-uo declares three. A new game's module cannot implement Teams at all without the inverted direction, so this is not a stale detail; it is the shape the reader needs and does not have.

Two shapes worth teaching, and only two

The inverted slot — why the name is namespaced under the module's own id, and why a module wants separate slots rather than one (it decides where each of core's contributions sits on a page it owns).
registerTeamProvider — the first registration where core calls the module and waits. Every other one is the module claiming a mount or core notifying it. The envelope, the 10-second budget, and the asymmetry that matters: every call fails stale except projectRoster, which fails closed, because for a visibility question "keep what you have" means serving the roster unprojected.

pageUrlTemplate is a footnote beside those — one optional string the reader meets while reading the provider.

What the phase explicitly does not do

Enumerate the contract. The kit already teaches four members and has never mentioned registerNotificationStreams, registerAnnounceLeg or registerPostHook, all of which predate Teams. That is the design: MODULE_API.md is normative, and the kit teaches one path end to end and links out. The question this phase answers is "did the teaching path change" — yes in two places, no everywhere else.

The ordering is awkward, and the phase says so

Written before the cutover, merged after it. scripts/checkCoreApi.js asserts the template's coreApi base equals the pinned core's MODULE_API_VERSION; CI clones that sha. 1.6.0 does not reach main until the cutover lands, so there is no sha to pin and no core for the template to build against until then. The pin move (ci/core-ref.json → the cutover sha, template/module.json → ^1.6.0) goes in the same PR, opened once that sha exists.

That check going red on a contract bump is the mechanism, not a bug — moving the pin is someone saying they have re-read the chapters.

AI-assisted: written with Claude Code.

🤖 Generated with Claude Code

Plan-only, one file. Into `edge`. Follows docs#159 — this commit was pushed just after you merged that one, so it did not ride along. Adds **Phase 11 — the integration kit**, on your call to queue it as the last phase before the `edge`→`main` cutover. ## Why it belongs in the plan rather than an issue The kit is the instruction book for putting a *different* game on this platform, written for an audience outside this org. Teams expands the contract that book teaches against, so the book is the last thing this bet owes before the cutover. ## One sentence in it is already wrong `book/02-website-module.md` tells the reader that **core declares a slot and a module may only fill one**. Phase 3 inverted exactly that — with `declareModuleSlot` a *module* declares a place on its own page and *core* fills it — and by phase 6 `module-uo` declares three. A new game's module cannot implement Teams at all without the inverted direction, so this is not a stale detail; it is the shape the reader needs and does not have. ## Two shapes worth teaching, and only two - **The inverted slot** — why the name is namespaced under the module's own id, and why a module wants *separate* slots rather than one (it decides where each of core's contributions sits on a page it owns). - **`registerTeamProvider`** — the first registration where **core calls the module and waits**. Every other one is the module claiming a mount or core notifying it. The envelope, the 10-second budget, and the asymmetry that matters: every call fails **stale** except `projectRoster`, which fails **closed**, because for a visibility question "keep what you have" means serving the roster unprojected. `pageUrlTemplate` is a footnote beside those — one optional string the reader meets while reading the provider. ## What the phase explicitly does not do **Enumerate the contract.** The kit already teaches four members and has never mentioned `registerNotificationStreams`, `registerAnnounceLeg` or `registerPostHook`, all of which predate Teams. That is the design: `MODULE_API.md` is normative, and the kit teaches one path end to end and links out. The question this phase answers is "did the teaching path change" — yes in two places, no everywhere else. ## The ordering is awkward, and the phase says so Written **before** the cutover, merged **after** it. `scripts/checkCoreApi.js` asserts the template's `coreApi` base **equals** the pinned core's `MODULE_API_VERSION`; CI clones that sha. 1.6.0 does not reach `main` until the cutover lands, so there is no sha to pin and no core for the template to build against until then. The pin move (`ci/core-ref.json` → the cutover sha, `template/module.json` → `^1.6.0`) goes in the same PR, opened once that sha exists. That check going red on a contract bump is the mechanism, not a bug — moving the pin is someone saying they have re-read the chapters. --- AI-assisted: written with Claude Code. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

wtclaude added 1 commit 2026-08-18 23:19:12 +00:00

docs(teams): queue the integration kit as phase 11, last before the cutover 9f90a99362

The kit is the instruction book for putting a different game on this platform,
written for an audience outside this org. Teams expands the contract that book
teaches against, so the book is the last thing the bet owes before `edge` becomes
`main` (org lead, 2026-08-18).

One sentence in it is already wrong rather than merely incomplete.
`book/02-website-module.md` tells a reader that core declares a slot and a module
may only fill one. Phase 3 inverted exactly that, and by phase 6 module-uo declares
three — a new game's module cannot implement Teams at all without the inverted
direction.

Two shapes are genuinely new and worth teaching: the inverted slot, and
`registerTeamProvider` as the first registration where core calls the module and
waits — with the asymmetry that every call fails stale except `projectRoster`,
which fails closed, because for a visibility question "keep what you have" means
serving the roster unprojected.

The phase explicitly does NOT enumerate the contract. The kit already teaches four
members and has never mentioned notification streams, announce legs or post hooks,
all of which predate Teams. MODULE_API.md is normative; the kit teaches one path
and links out.

Its ordering is awkward and is stated rather than smoothed over: it is written
before the cutover and can only merge after it, because CI clones the pinned sha
and checks the template against that core's MODULE_API_VERSION — and 1.6.0 does
not reach `main` until the cutover lands.

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech merged commit 30d964c090 into edge

2026-08-18 23:19:28 +00:00

whitlocktech deleted branch docs/teams-phase11-queue

2026-08-18 23:19:30 +00:00

whitlocktech referenced this issue from a commit

2026-08-18 23:19:31 +00:00

Merge pull request 'docs(teams): queue the integration kit as phase 11, last before the cutover' (#160) from docs/teams-phase11-queue into edge

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/docs#160