docs(teams): Team pages and the activity feed, and what phase 3 disproved

TEAMS.md gains a dated amendment on phase 3 with five corrections, all found by
building the thing it describes:

  - §3.2 and §3.4 contradict each other about `team.member.row`'s props, and
    §3.2 wins because it is the security rule. A client slot can only receive
    what the browser was sent, so §3.4's `{ memberKey, userId, displayName }`
    means publishing both identifiers in every public roster, module installed
    or not. The slot is redeclared with what core can honestly supply.
  - §3.3's projection is an EIGHTH MODULE_API member where 1.6.0 listed seven.
    Settled by the org lead: 1.6.0 is amended in place, on the rule Protocol 4
    was given in phase 2 — a contract owes a bump only once it has reached
    `main`.
  - "the module declines" needed splitting in two before it could be built. No
    module at all withholds nothing and must serve the roster whole; a module
    whose rungs could not be consulted must serve none of it. Only the second
    fails closed, or bare core shows an empty roster on every Team page.
  - the module answers with member KEYS, not rows, so it can narrow what is
    published and cannot widen it.
  - core's five activity kinds are four until the forum lands, and a Team's
    FIRST roster emits no join items at all.

§2.11's route table gains the activity endpoint it never had, and MODULE_API.md
documents `projectRoster`, the inverted fail-closed semantics that make it
different from every other provider call, and `ctx.teams.activity.push`'s item
shape and its four contractual properties.

BACKEND_DESIGN.md: the seventh Team table, its retention, and the three public
routes' new behaviour — `enabled` on the index, the slot props on the single
Team, the per-caller row projection on the roster, and the feed.

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

website/MODULE_API.md

@@ -33,17 +33,23 @@ The client half carries the same number (`client/src/modules/version.js`) and a
 agree. Duplicated rather than fetched because the value has to be on `window.__rg` before the first
 module chunk evaluates, which is earlier than any network round trip could answer.
 
-**1.6.0 — Teams, the whole surface.** Seven additions, no removals and no changed signature, so minor;
+**1.6.0 — Teams, the whole surface.** Eight additions, no removals and no changed signature, so minor;
 `module-uo`'s `coreApi: "^1.3.0"` still resolves. `api.registerTeamProvider(...)` and
 `ctx.teams.publish` / `ctx.teams.reconcile` (§2.3, §2.4a) · `ctx.teams.activity.push` ·
-`api.registerSlashCommands(...)` · the client slots `team.overview` and `team.member.row`.
+the provider's optional `projectRoster` · `api.registerSlashCommands(...)` · the client slots
+`team.overview` and `team.member.row`.
 
-**The number covers the whole surface; the members arrive by phase, and each is marked below.** Three
-are live now. `ctx.teams.activity.push` and `api.registerSlashCommands` are **present and throw**, with
-an error naming the phase that will implement them — chosen over leaving them absent so that a module
-written against the published version fails at registration with a sentence explaining itself, rather
-than at whatever moment someone first exercises the feature. Do not call them yet; do not treat a
-throw as a bug.
+> **Amended 2026-08-17 (phase 3), on the org lead's decision: the eighth member joins 1.6.0 in place
+> rather than getting a 1.7.0.** The rule is the one Protocol 4 was given in phase 2 — *a contract
+> owes a bump only once it has landed on `main`* — and 1.6.0 has only ever been on `edge`. The same
+> amendment marks `ctx.teams.activity.push` and both client slots live, and narrows
+> `team.member.row`'s props (TEAMS.md §3.4).
+
+**The number covers the whole surface; the members arrive by phase, and each is marked below.** Seven
+are live now. `api.registerSlashCommands` is **present and throws**, with an error naming the phase
+that will implement it — chosen over leaving it absent so that a module written against the published
+version fails at registration with a sentence explaining itself, rather than at whatever moment
+someone first exercises the feature. Do not call it yet; do not treat its throw as a bug.
 
 **`registerTeamProvider` is the first registration where core calls the MODULE and waits.** Every
 existing one is either the module claiming a mount or core notifying it; the closest precedent is
@@ -201,13 +207,36 @@ module-uo does not need is on the list.
 | `ctx.moduleId` | the id from `module.json` | loader | log tags, table checks |
 | `ctx.teams.publish` | `(event) => Promise<void>` | `model/teams/teamSync` | the Team provider's module (1.6.0) |
 | `ctx.teams.reconcile` | `({ reason }) => void`, returns at once | `model/teams/teamSync` | after a fresh account link (1.6.0) |
-| `ctx.teams.activity.push` | `(items) => Promise<void>` — **throws until the Team activity feed lands** | — | (1.6.0, declared) |
+| `ctx.teams.activity.push` | `(items) => Promise<void>`, fire-and-forget | `model/teams/teamActivity` | the Team provider's module (1.6.0) |
 
 **`ctx.teams` is push only, and that is the contract.** There is no reader: a module *answers*
 questions about Teams, it does not ask them. Every Team table is core-internal (§1.2), and a
 `getTeamRoster` on `ctx` would be core offering to read back the module's own answer — which the
 module already holds, in its own store.
 
+**`ctx.teams.activity.push(items)`** writes the per-Team feed (TEAMS.md §4.1). Each item is:
+
+```js
+{ externalId, kind, summary, occurredAt?, visibility?, actorMemberKey?, actorUserId?, payload?, dedupeKey? }
+```
+
+Four things about it are contract rather than implementation:
+
+- **`summary` is already rendered and core stores it verbatim.** Core cannot phrase "gained 15,000
+  gold" for a game whose vocabulary it does not know, and a core that templated it would have
+  re-acquired exactly the semantics the module system exists to remove. `kind` and `payload` are
+  likewise opaque — core filters on them and only the module's `team.overview` slot renders anything
+  richer than the text.
+- **A Team is named by the module's own `externalId`**, which core maps, and only that module's
+  ACTIVE Teams resolve. There is no id a module can send that reaches another module's Team, and an
+  archived Team is not writable — its feed is a closed record of what happened before the rename.
+- **`visibility` defaults to `'members'` — fail closed.** The module chooses it per item; core
+  enforces it on the read path.
+- **It never throws at the call site and never rejects.** This is called from inside a game-event
+  handler, and a storage problem of core's must not become the module's control flow. A malformed
+  item is dropped and logged; a `dedupeKey` collision is a successful no-op, which is what makes a
+  sidecar reconnect backfill safe to replay.
+
 Both live members are **fire-and-forget**. `publish` is an optimisation that makes a membership
 change visible at once; `reconcile` is a debounced *request* that returns immediately and never
 rejects. Correctness comes from reconciliation either way, so neither can make a module's own call
@@ -364,14 +393,16 @@ module becomes the authoritative source of Teams for this deployment.
 **One provider per deployment.** Unlike every other registry, this holds a single value: Teams have
 one authoritative source by construction, and two modules answering "what Teams exist" would produce
 two disjoint sets under one table with no rule for merging them. A second registration is a
-collision, reported against the module that holds it. All three methods are required — a provider
+collision, reported against the module that holds it. Three methods are required — a provider
 that could list Teams but not their members would leave core holding Teams it can never populate,
-which is not the same as a call that fails.
+which is not the same as a call that fails. The fourth is optional; see below.
 
 ```js
 getTeams()                  // () => Promise<{ ok, complete?, teams }>
 getTeamMembers(externalId)  // (string) => Promise<{ ok, complete?, members }>
 getTeamLeaders(externalId)  // (string) => Promise<{ ok, leaders }>   // leaders = [memberKey]
+projectRoster(externalId, members, viewer)   // OPTIONAL (1.6.0, phase 3)
+                            // => Promise<{ ok, members }>            // members = [memberKey]
 
 // authoritative
 { ok: true,  complete: true, teams: [ { externalId, name, abbr?, meta? } ] }
@@ -393,6 +424,29 @@ the one a module returns while its sidecar is still connecting.
 A refusal costs staleness and nothing else: core keeps the projection it has, records the reason, and
 surfaces it. It never empties a roster on an answer it does not trust.
 
+**`projectRoster` is the exception to that last paragraph, and the exception is deliberate.** It
+answers *who is allowed to look at a roster*, on the request path, because the audience model and its
+configuration are the module's and core does not have one (TEAMS.md §3.3). For a visibility question,
+"keep what you have" is a leak: leaving the answer alone means serving the roster unprojected to
+whoever asked. So this one call **fails closed**.
+
+Core distinguishes two refusals, and a module does not have to do anything to get the right one:
+
+- **no provider, or a provider without `projectRoster`** — there is no audience model to consult and
+  nothing is being withheld, so core serves the roster whole at its own public shape. This is what
+  makes the member genuinely optional: bare core, and a module with no rungs of its own, both render
+  the page core writes.
+- **a provider that HAS `projectRoster` and refused, threw, timed out or answered malformed** — core
+  serves an empty roster and says so in the response (`projected: false`,
+  `projectionUnavailable: true`).
+
+Core hands over the roster rows it holds plus a described viewer — `{ userId, role }`, or `null` for
+an anonymous caller — and never the `users` row, which would make every column of that table part of
+this contract. **The module answers with member KEYS, not rows.** Core keeps ownership of what a
+published row looks like and re-normalises whatever comes back through its own public shape, so a
+module can narrow which rows appear and cannot widen which fields do: the member key and the site
+account id are withheld from every public roster whatever a module returns.
+
 `complete: false` means "valid but partial": core applies additions and updates and performs **no**
 removals. It defaults to `true` when omitted, so the ordinary authoritative case needs no ceremony.