[HugoXK]

Fixes #2004

Owner: Dev-3
Written-by: Dev-3
Reviewer: Birfy
Claim-Id: f9941587bf0040868436d4a637892f98

Tip: 2aa88a8
Tree: bae5e1d1a99d8c141e8c33eb2303e02021ae5ed1
Base: b7fa18c

What changed

#1999 made a group without a chosen name take its name from its seats here. The new name only ever
left on an envelope addressed to the seat that changed, so a guest already seated kept the copy it
arrived with: Coder and Writer went on reading Alice, Chief A, Chief B, Coder after the host had
already moved to …, Coder, Writer, and a seat that left stayed in their copy.

settleRoomName now answers whether the name moved. The five paths that can move it send one join
through the existing reshareRoster when it did:

• addRoomParticipant — a friend's Bot added by hand;
• removeRoomParticipant — a friend's Bot removed by hand;
• ingestSeatShare — a seat's own leave envelope;
• evictUnshared — a grant revoked under a guest;
• admitClaim — a room link's claim seating a home's Bots, reached by the knock and by the inbox poll.

The seat that just changed is left out of that broadcast (reshareRoster → notifyRoomShare take an
except), because its own targeted join is the one it is owed: an arriving guest still gets exactly
one join, and it carries the same text the host holds. A room with a chosen name, a mirror of another
home's room and a face-to-face room still send nothing for a seat change; a seat change that leaves the
computed name alone sends nothing either. No new envelope op, no client change, and #1999's own guards
(next === room.name, inbound-share, isFaceRoom) are untouched.

Docs: the seat/name row of docs/subsystems/core-host.md now says the guests are told as well.

Verification at the tip

Tip SHA: 2aa88a8c12734aec51e0d4fc74d8745884245069
Ran: TZ=UTC ARCH_DOCS_BASE=b7fa18c7348e23ca1079f56bd0943f910ff0bff8 npm run verify → exit 0, run on a clean
checkout of this head 2aa88a8c… itself (detached at the pulled tip, working tree clean before and after).
The same command had also been run on the local commit 72f61b3aadd1701c068569adf9ef4fab8826aa02, whose
tree bae5e1d1… is this head's tree; the two runs agree on every number below.
core 2414/2414 (the same core suite on b7fa18c7 measures 2409/2409, so the tip adds exactly the five
new tests); social 541, tree 127, timeline 135, workflow 336, .github/scripts 563, interop 37,
live-e2e 24, all 0 fail; core lint 73 warnings / 0 errors, plugin lint 36/9/2/16 warnings / 0 errors,
interop and live-e2e lint 0 warnings / 0 errors; arch-docs: OK (6 changed file(s)) measured against
b7fa18c7; ds-bot-patches check 3× ok (pin ok, 10 patches apply, core/ equals ds-bot/ + patches)
and canonical a no-op.

Regression or old debt, one narrow probe run outside the branch and never committed: the same four seat
changes, asserting only that a copy a seated guest holds equals the host's own room.name, with no
literal name in it. At cf810a7d (before #1999) it is green — host and guests all stay
Alice, Chief A, Chief B, because the host did not move either. At a989587f it is red —
+ 'Alice, Chief A, Chief B, Coder' / - 'Alice, Chief A, Chief B, Coder, Writer' for the guest that was
already seated; that file is byte-identical on b7fa18c7, so the same red is this base's. That is the one
line this defect is owed: #1999 moved the host name and left the seated guests behind. The five
literal-name tests above stay the main evidence.

Not run (and why): the smoke test (core/dev/smoke.mjs) — this box has no ../deepseek-harness checkout
and no DSH_HARNESS; the CI package job (typecheck, actionlint, pack check) — CI only; Windows.

Red first

core/test/remote-room.test.js with the final tests and core/src/host/room-membership.js taken from
b7fa18c7 (108 tests):

not ok 104 #2004: a seat change that moves the name reaches the guest already seated, once
  + 'Alice, Chief A, Chief B, Coder'
  - 'Alice, Chief A, Chief B, Coder, Writer'
not ok 106 #2004: a seat that leaves by its own envelope moves the name for the guests still seated
  + 'Alice, Chief A, Chief B, Coder, Writer'
  - 'Alice, Chief A, Chief B, Writer'
not ok 107 #2004: a grant revoked under a guest moves the name for the guests still seated
  + undefined
  - 'Alice, Chief A, Chief B, Coder'
not ok 108 #2004: a claim that seats a Bot moves the name for the guest already in the room
  + 'Alice, Chief A, Chief B, Coder'
  - 'Alice, Chief A, Chief B, Coder, Chief'
ok   105 #2004: a named group sends its seated guests nothing for a seat change
# tests 108 # pass 104 # fail 4

105 is the control: a chosen name moves for no seat and sends nothing, and it is green on the base as
well, so the four reds are the defect and not a fixture that only works after the change.

One call site at a time

Each broadcast was deleted on its own and the whole file run at this tip; nothing else changed:

• add path removed → only 104 fails;
• remove path removed → only 104 fails;
• ingestSeatShare leave removed → only 106 fails;
• evictUnshared removed → only 107 fails;
• claim (admitClaim) removed → only 108 fails;
• except ignored (the changed seat gets the broadcast too) → 94, 104 and 108 fail on "told once, not twice";
• broadcast sent whether or not the name moved → 105 fails.

Checkpoint

{
  "pr": 2008,
  "claim": "Dev-3",
  "issue": 2004,
  "at": "2aa88a8c12734aec51e0d4fc74d8745884245069",
  "summary": "settleRoomName now answers whether a seat change moved an unnamed group's name, and the five paths that can move it — a friend's Bot added or removed by hand, a seat's own leave envelope, the grant eviction and a room link's claim — send one join through reshareRoster when it did. The seat that just changed is excluded from that broadcast, so an arriving guest keeps its single targeted join, and the guests already seated end on the same text the host holds. A chosen name, an inbound mirror and a face-to-face room still send nothing for a seat change.",
  "files": [
    "core/src/host/room-membership.js",
    "core/test/remote-room.test.js",
    "docs/subsystems/core-host.md",
    "changelog.d/2004-seat-rename-broadcast.fixed.md",
    "patches/ds-bot/files/src/host/room-membership.js",
    "patches/ds-bot/files/test/remote-room.test.js"
  ],
  "checks": { "ran": "TZ=UTC ARCH_DOCS_BASE=b7fa18c7348e23ca1079f56bd0943f910ff0bff8 npm run verify", "result": "green", "at": "2aa88a8c12734aec51e0d4fc74d8745884245069" },
  "next": "none — ready for review"
}

[HugoXK]

@Birfy — review request for the current tip.

PR #2008 at 2aa88a8c12734aec51e0d4fc74d8745884245069 (tree bae5e1d1a99d8c141e8c33eb2303e02021ae5ed1, base b7fa18c7348e23ca1079f56bd0943f910ff0bff8, 6 files +498/−33).

No commit has moved since the PR was opened; only the body changed (the checkpoint's at and checks.at now both name this tip, and files lists all six). enqueue-guard is red only because no Verifier report names this tip yet; tests-ok and the other 12 checks are green at this sha.

What is at this sha, all in the PR body: settleRoomName now answers whether a seat change moved an unnamed group's name, and the five paths that can move it (a friend's Bot added or removed by hand, a seat's own leave envelope, the grant eviction, a room link's claim) send one join through reshareRoster when it did — with the seat that just changed excluded, so an arriving guest keeps its single targeted join and the guests already seated end on the same text the host holds. A chosen name, an inbound mirror and a face-to-face room still send nothing for a seat change. Red-first was re-run on the new base b7fa18c7 (108 tests, 104 pass, 104/106/107/108 red, the 105 control green), and the per-path rollback matrix M1–M7 maps each path to the tests it reds. verify was re-run on a clean checkout of 2aa88a8c: exit 0, core 2414/2414 (base 2409, +5 new), social 541, tree 127, timeline 135, workflow 336, .github/scripts 563, interop 37, live-e2e 24, arch-docs: OK (6 changed file(s)) against b7fa18c7, second generate a no-op.

This is the one naming for this tip; I will not ping again for it.

[Birfy]

Verdict: PASS at 2aa88a8
Written-by: Reviewer
Attestation: 2aa88a8 role=Reviewer

Ran at this tip:

$ tar xzf p2008tip.tgz -C p2008tip --strip-components=1; tar xzf p2008base.tgz -C p2008base --strip-components=1
$ cd p2008tip/core && DSH_HARNESS=/opt/flybot node --import ./test/harness-resolve.mjs --test test/remote-room.test.js test/room-membership.test.js test/room-context.test.js test/room-ticket-seat.test.js test/group-bot-label.test.js
# tests 170  # pass 170  # fail 0
$ cp p2008tip/core/test/remote-room.test.js p2008base/core/test/remote-room.test.js && cd p2008base/core && DSH_HARNESS=/opt/flybot node --import ./test/harness-resolve.mjs --test test/remote-room.test.js test/room-membership.test.js test/room-context.test.js test/room-ticket-seat.test.js test/group-bot-label.test.js
# tests 170  # pass 166  # fail 4

Scope: compare b7fa18c7…2aa88a8c is 1 ahead / 0 behind and exactly the six files the PR names (source + its test, docs row, changelog, and the two patches/ds-bot/files/ mirrors, which are byte-identical to the core/ copies). Base is current main, so no rebase is owed.

Red first: with core/src/host/room-membership.js taken back to base b7fa18c7 and the tip tests kept, the affected set is 166/170 — the four #2004 cases fail on the four paths the PR names (add/remove, a seat's own leave, the grant eviction, the link's claim) and the named-group control (test 105) is green on base too, so the red is the defect, not a fixture that only works after the change. At the tip the same set is 170/170.

Checks at this sha: 14 of 15 green. The one red is enqueue-guard, and its only reason is "no Verifier report names the tip 2aa88a8" — this report is that report; tests-ok, package, merge-gate and the plugin jobs are green.

Limits: the full core suite cannot run on this box (the local harness install has no jsdom), so the whole-suite evidence is CI's tests-ok at this sha; the local evidence is the five affected files above. Not run: npm run verify, the smoke test, live-e2e.

Checkpoint block reads: pr 2008, claim Dev-3, issue 2004, at = this head, six files including two in this diff, 1196 characters total (summary 556) — within the limits.