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>
65 lines
4.0 KiB
JavaScript
65 lines
4.0 KiB
JavaScript
// The module API version — the single number a module's `coreApi` range is
|
|
// checked against (docs/website/MODULE_API.md §1.1).
|
|
//
|
|
// Bump minor when a member is ADDED to ctx or a new register* call appears;
|
|
// major when one is removed, its signature changes, or its behaviour changes
|
|
// without a signature change. A core-internal refactor behind an unchanged
|
|
// member is not a bump.
|
|
//
|
|
// Deliberately separate from PROTOCOL_VERSION (which versions the shard wire and
|
|
// has nothing to say about a website module) and from any module's own version.
|
|
|
|
// 1.6.0 — the Team surface (docs/website/TEAMS.md Part 11). Additions only, so
|
|
// minor: `api.registerTeamProvider({ getTeams, getTeamMembers, getTeamLeaders })`,
|
|
// `ctx.teams.publish(event)`, `ctx.teams.reconcile({ reason })`,
|
|
// `ctx.teams.activity.push(items)`, `api.registerSlashCommands([...])`, and the
|
|
// client slots `team.overview` / `team.member.row`. module-uo's `coreApi:
|
|
// "^1.3.0"` still resolves.
|
|
//
|
|
// **The number covers the whole surface; the members arrive by phase.** The three
|
|
// this phase implements are live. `activity.push` lands with the Team activity
|
|
// feed (§4, phase 3) and `registerSlashCommands` with the Discord commands (§7.1,
|
|
// phase 7) — until then each is present and THROWS rather than being absent or,
|
|
// worse, silently accepting data into a table that does not exist. MODULE_API.md
|
|
// names the phase against each member, so a module author reads what is callable
|
|
// today rather than discovering it at runtime.
|
|
//
|
|
// 1.5.0 — a CLIENT addition: `PublicLayout` takes an optional `shell` prop that
|
|
// renders the page body wrapper core's own pages write by hand (MODULE_API.md
|
|
// §3.4). Minor, not major: §3.4 makes *changing* a kit component's props a major
|
|
// bump because that breaks a call already written, and adding an optional one
|
|
// breaks nothing — omitting `shell` is 1.4.0's behaviour exactly. Nothing on the
|
|
// server changed; this file bumps for the reason below. Found by the Integration
|
|
// Kit's acceptance run (docs/modules/kit-acceptance.md), where a module built
|
|
// exactly as the kit teaches rendered outside the site's page column.
|
|
//
|
|
// 1.4.0 — no member changed. §2.7 gained one prohibition: a module does not open
|
|
// a connection to a game server from the website process; it talks to a sidecar,
|
|
// which owns the durable copy of the game's state. Minor rather than major
|
|
// because the SURFACE is identical to 1.3.0 — module-uo's `coreApi: "^1.3.0"`
|
|
// still resolves, and it already complies — but a module written against 1.3.0
|
|
// could satisfy every member and still be built the wrong way round, which is
|
|
// what this number now says. The one §2.7 rule with no CI behind it: an outbound
|
|
// socket is not statically detectable the way an internal require is.
|
|
//
|
|
// 1.3.0 — three CLIENT additions from Phase 3 slice 3: a nav item may carry an
|
|
// `icon`, core declares a `player.invite.accepted` slot, and `window.__rg.api`
|
|
// gained `BASE` (which §3.5 always specified and shared.js never published).
|
|
// Nothing on the server changed; this file bumps for the reason below.
|
|
//
|
|
// 1.2.0 — the CLIENT registry gained `registerExtension` and core gained client
|
|
// extension slots (MODULE_API.md §3.7): the twin of this half's declareSlot /
|
|
// registerExtension, for module content inside a core *page* rather than under a
|
|
// core route prefix. Nothing on the server changed, and this file bumps anyway —
|
|
// the two halves state ONE version, because a module declares a single `coreApi`
|
|
// range and is served one chunk (client/src/modules/version.js).
|
|
//
|
|
// 1.1.0 — `ctx` gained `activity.log`, `users.getById` and `site.baseUrl`, each
|
|
// because module-uo's extraction needed it and none of them could be vendored:
|
|
// an admin action a module performs belongs in core's one audit log, the
|
|
// extension slot needs the user its prefix names, and §2.7 forbids a module
|
|
// reading core's `APP_BASE_URL` for itself. Additions only, so minor.
|
|
const MODULE_API_VERSION = '1.6.0'
|
|
|
|
module.exports = { MODULE_API_VERSION }
|