wtclaude
92631347f9
Core's projection of the module's Teams, kept in step (docs/website/TEAMS.md
§2.4), plus the two ctx members a module pushes through.
The four gates are the file, and each is invariant 1 in a different costume --
module unavailability is staleness, never emptiness:
1. getTeams() not ok -> record the failure, touch NOTHING, return.
2. ok but empty, core holds >=1 -> quarantine; apply only if the NEXT
authoritative answer, an interval later,
agrees.
3. getTeamMembers() not ok -> that Team's roster untouched and stale; the
other Teams sync normally.
4. ok but zero members, had some -> the same two-strikes quarantine, per Team.
Gates 2 and 4 exist because an authoritative-looking empty answer during a cold
start is the one failure indistinguishable from a real wipe. "Every Team on the
shard disbanded at once" costs one interval to confirm; getting it wrong empties
every roster on the site.
Events are an optimisation, never the source of truth. Member and leadership
deltas apply at once for a Team core already knows; team.created and
team.disbanded only ask for a run. §2.2 scopes archival to an authoritative full
list, so a repeated or spurious disband event costs a reconcile rather than a
Team -- and a Team invented from a delta would have no name, no roster and no
leaders anyway.
Two columns TEAMS.md did not contemplate, both on `teams`:
- roster_synced_at, because team_sync_state holds one row per MODULE and gate 3
leaves ONE Team behind while the others sync. Without a per-Team stamp that
Team's page would report the module's last success as its own -- exactly the
staleness the gate exists to surface.
- members_empty_since, gate 4's per-Team quarantine. The twin of
team_sync_state.pending_empty_since, which is per module and cannot express it.
One real bug found by its own test. The roster upsert was writing is_leader, so a
refused getTeamLeaders() left every member demoted -- the roster had already
written `leader: false` before the authoritative call was even made. §2.5 is
explicit that path 2 is answered by getTeamLeaders(), so is_leader is now set on
INSERT only (seeding a Team so it is not leaderless while that call fails) and
moved afterwards by setLeaders() alone. Two writers for one column was the whole
defect.
MODULE_API_VERSION 1.6.0 on both halves -- they state one contract and a module
declares one coreApi range. The number covers the whole Team surface per Part 11;
the members arrive by phase. registerTeamProvider, ctx.teams.publish and
ctx.teams.reconcile are live. ctx.teams.activity.push (§4, phase 3) and
api.registerSlashCommands (§7.1, phase 7) are present and THROW with a sentence
naming their phase, rather than being absent or silently accepting data into
tables that do not exist yet.
39 tests here, and the ctx surface guard in moduleLoader.test.js updated -- it
caught the addition, which is what it is for. Server 809 passed, client 192
passed, 0 failed.
Refs docs/website/TEAMS.md §2.2, §2.3, §2.4, Part 11, Part 12 phase 2
Co-Authored-By: Claude <noreply@anthropic.com>
49 lines
3.3 KiB
JavaScript
49 lines
3.3 KiB
JavaScript
// The client's copy of MODULE_API_VERSION. It must equal the server's
|
|
// (server/src/modules/version.js) — the two halves version ONE contract
|
|
// (docs/website/MODULE_API.md §1.1), and a module checks whichever half it is
|
|
// talking to: `coreApi` against the server's at load time, `window.__rg.version`
|
|
// against the client's before it registers anything.
|
|
//
|
|
// Duplicated rather than fetched, and that is deliberate. The value has to be on
|
|
// `window.__rg` before the first module chunk evaluates, which is earlier than
|
|
// any network round trip could answer — a fetched version would mean either an
|
|
// await before render or a module reading `undefined`. The cost of the copy is
|
|
// that the two files can drift, so a test asserts they agree
|
|
// (client/test/moduleRegistry.test.js) rather than trusting a bump to remember
|
|
// both.
|
|
// 1.6.0 — the Team surface (docs/website/TEAMS.md Part 11). Nothing on this half
|
|
// changed yet: the two client additions the version covers are the `team.overview`
|
|
// and `team.member.row` slots, and a slot can only be declared by the page that
|
|
// hosts it, which lands with the Team pages in phase 3. This file bumps anyway,
|
|
// for the reason at the top — the two halves state ONE version, and a module
|
|
// declares one `coreApi` range against both.
|
|
//
|
|
// 1.5.0 — `PublicLayout` takes an optional `shell` prop ('narrow' | 'mid' |
|
|
// 'wide') that renders the `shell-… page-body` wrapper core's own pages write by
|
|
// hand. Additive: omitting it is 1.4.0's behaviour, so §3.4's "changing a kit
|
|
// component's props is major" does not bite — nothing already written changes
|
|
// meaning. It exists because the kit's acceptance run proved a module cannot
|
|
// discover the wrapper: the class names are theme.css's and appear in no
|
|
// contract, so a module page rendered outside the site's column while doing
|
|
// everything the kit said (docs/modules/kit-acceptance.md).
|
|
// 1.4.0 — a rule, not a member: §2.7 forbids a module opening a connection to a
|
|
// game server from the website process (it talks to a sidecar, which owns the
|
|
// durable copy). Nothing on window.__rg changed and nothing on the server's ctx
|
|
// changed either; this half bumps because the two halves state ONE version.
|
|
// 1.3.0 — three additions, all from Phase 3 slice 3 needing them: a nav item may
|
|
// carry an `icon` component (§3.3), core declares a third slot
|
|
// `player.invite.accepted` (§3.7), and `window.__rg.api` gained `BASE`, which
|
|
// §3.5 always documented and shared.js never published. Additive throughout: a
|
|
// module written against 1.2.0 is unaffected. The server half is untouched and
|
|
// bumps anyway, for the reason below.
|
|
// 1.2.0 — `registry` gained `registerExtension` and core gained extension slots
|
|
// (MODULE_API.md §3.7). The first change to window.__rg since 1.0.0, and an
|
|
// addition: a module that never fills a slot is unaffected. The server half is
|
|
// untouched and bumps anyway, for the reason below.
|
|
// 1.1.0 — the server's ctx gained activity.log, users.getById, site.baseUrl and
|
|
// the rate-limit factory (MODULE_API.md §2.3). Nothing on window.__rg changed,
|
|
// but the two halves state ONE version: a module declares a single coreApi range
|
|
// and is served one chunk, so a client that claimed 1.0.0 while the server
|
|
// answered 1.1.0 would be two answers to one question.
|
|
export const MODULE_API_VERSION = '1.6.0'
|