RunicGateway/docs
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(link): protocol 4 — guild membership on the wire #153

Merged
whitlocktech merged 1 commits from feat/teams-phase1-guild-roster into edge 2026-08-17 19:28:10 +00:00
Conversation 0 Commits 1 Files Changed 4 +293 -5
wtclaude commented 2026-08-17 18:03:12 +00:00
Member
Copy Link

Teams Phase 1, docs half. Targets edge; edge → main is the v4 cutover.

Pairs with servuo-plugins #12, link #31, Module-uo #8, installer #20.

New: link/v4.md

The spec of record for guild.roster and guild.leave. It documents what the phase found as well as what it built — the missing store migration and the user_version decision, why the roster lives in its own column rather than inside the guild.update snapshot, why a split roster is reassembled in memory rather than appended, and why guild.leave gets no board projection at all.

§6 records that the reassembly bug was invisible to every unit test — they all exercised single-frame rosters — and only the live rig caught it. Kept because it is the argument for why Phase 0 existed.

Corrected: PROTOCOL_2.md §10.1

§10.1 already described this design in 2.0 — hold a member-serial set, diff it each sweep, emit join/leave — and 2.0 then shipped only the half needing no new state, folding membership into the board signature as a serial sum. The section has read ever since as though the whole thing were built.

It now says which half shipped, and carries the correction that building the rest produced: a sum is not a safe stand-in for a set, because one member joining and another leaving between two sweeps offset each other and the guild reads as unchanged.

Corrected: INTEGRATION.md

Both kinds in the event catalogue, the roster key on GET /guilds, and the three things an integrator gets wrong otherwise:

  • guild.leave's who is a bare serial string, not an actor object — the mobile has already left, so there is nothing to attribute
  • acct is genuinely optional on a member (a character can have no account at all)
  • a guild with no roster key is not the same as one with an empty roster

Amended: website/TEAMS.md

Two places where this phase disagreed with the design of record:

  • Phase 1 spans five repos, not four — installer joins, because backup.rs justifies skipping the sidecar DB on reasoning the migration falsifies.
  • The user_version decision is recorded, since TEAMS.md did not contemplate a migration mechanism at all.

The amendment is marked inline as an amendment with its date, rather than silently rewriting the plan.

AI-assisted: written with Claude Code. Commits carry Co-Authored-By: Claude <noreply@anthropic.com>.

Teams **Phase 1**, docs half. Targets `edge`; `edge` → `main` is the v4 cutover. Pairs with servuo-plugins #12, link #31, Module-uo #8, installer #20. ## New: `link/v4.md` The spec of record for `guild.roster` and `guild.leave`. It documents what the phase **found** as well as what it built — the missing store migration and the `user_version` decision, why the roster lives in its own column rather than inside the `guild.update` snapshot, why a split roster is reassembled in memory rather than appended, and why `guild.leave` gets no board projection at all. §6 records that the reassembly bug was invisible to every unit test — they all exercised single-frame rosters — and only the live rig caught it. Kept because it is the argument for why Phase 0 existed. ## Corrected: `PROTOCOL_2.md` §10.1 §10.1 **already described this design** in 2.0 — hold a member-serial set, diff it each sweep, emit join/leave — and 2.0 then shipped only the half needing no new state, folding membership into the board signature as a serial *sum*. The section has read ever since as though the whole thing were built. It now says which half shipped, and carries the correction that building the rest produced: **a sum is not a safe stand-in for a set**, because one member joining and another leaving between two sweeps offset each other and the guild reads as unchanged. ## Corrected: `INTEGRATION.md` Both kinds in the event catalogue, the `roster` key on `GET /guilds`, and the three things an integrator gets wrong otherwise: - `guild.leave`'s `who` is a bare **serial string**, not an actor object — the mobile has already left, so there is nothing to attribute - `acct` is **genuinely optional** on a member (a character can have no account at all) - a guild with **no `roster` key** is not the same as one with an empty roster ## Amended: `website/TEAMS.md` Two places where this phase disagreed with the design of record: - **Phase 1 spans five repos, not four** — `installer` joins, because `backup.rs` justifies skipping the sidecar DB on reasoning the migration falsifies. - **The `user_version` decision is recorded**, since TEAMS.md did not contemplate a migration mechanism at all. The amendment is marked inline as an amendment with its date, rather than silently rewriting the plan. --- AI-assisted: written with Claude Code. Commits carry `Co-Authored-By: Claude <noreply@anthropic.com>`.
wtclaude added 1 commit 2026-08-17 18:03:14 +00:00
docs(link): protocol 4 — guild membership on the wire b369e728c2 
Adds v4.md as the spec of record for `guild.roster` and `guild.leave`, and
corrects the two older documents that Protocol 4 makes wrong.

PROTOCOL_2.md §10.1 already described this design — hold a member-serial set,
diff it each sweep, emit join/leave — and 2.0 then shipped only the half needing
no new state, folding membership into the board signature as a serial *sum*. The
section has read ever since as though the whole thing were built. It now says
which half shipped, and carries the correction that doing it produced: a sum is
not a safe stand-in for a set, because one member joining and another leaving
between two sweeps offset each other and the guild reads as unchanged.

INTEGRATION.md gains both kinds in the event catalogue, the `roster` key on
GET /guilds, and the three things an integrator gets wrong otherwise — that
`guild.leave`'s `who` is a bare serial rather than an actor object (the mobile has
already left, so there is nothing to attribute), that `acct` is genuinely optional
on a member, and that a guild with no `roster` key is not the same as one with an
empty roster.

v4.md documents what the phase found as well as what it built: the missing store
migration and the user_version decision, why the roster lives in its own column
rather than inside the guild.update snapshot, why a split roster is reassembled in
memory rather than appended to the column, and why guild.leave gets no board
projection at all. §6 records that the reassembly bug was invisible to every unit
test — they all exercised single-frame rosters — and only the live rig caught it.

TEAMS.md is amended where this phase disagreed with it: Phase 1 spans five repos,
not four, because installer/backup.rs justifies skipping the sidecar database on
reasoning the migration falsifies. The user_version decision is recorded there too,
since the design of record did not contemplate a migration mechanism at all.

Co-Authored-By: Claude <noreply@anthropic.com>
whitlocktech merged commit 11696d14e3 into edge 2026-08-17 19:28:10 +00:00
whitlocktech deleted branch feat/teams-phase1-guild-roster 2026-08-17 19:28:10 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
bug
Something is not working
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
invalid
Something is wrong
question
More information is needed
wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ksfixitman whitlocktech wtclaude
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: RunicGateway/docs#153
No description provided.
Delete Branch "feat/teams-phase1-guild-roster"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?