host: a group settings change leaves no line in the room #1962

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 5649bf55a1de4607a0130dd98ce6755c
Branch: dev/1-p303-room-settings-line
Base: 54dad6b
At: 2026-11-01T01:28:59Z

What happens today (live main 54dad6b856c5ea8c387b2a62ea9143e67126acd3; unchanged by #1961)

core/src/host/roster.js updateRoom (:364) already works out every effective change and collects it in changes — added …, removed …, made X the admin, made X the task lead, plain messages now go to the admin first / every member now replies in turn, updated the notice, cleared the notice, renamed it "…" — and returns it to the caller. Nothing writes any of that into the room. The only room-visible effects of a settings patch are the title update (retitleRoom, :468) and, for a name or a notice, the remote join push added by #1949 (:475). So a person who changes the admin, the task lead, the reply mode, the notice or the name leaves no trace in room.log: the members sitting in the room never see it, and the next turn's transcript has no line saying it happened.

Reproduction (red first, runs on 54dad6b8)

core/test/remote-room.test.js:2457, the PR's test against the pristine roster.js:

not ok 1 - a settings patch leaves one visible line in the room, and only when a value changed
    one rename is one line: []
    0 !== 1
# tests 1 / # pass 0 / # fail 1

updateRoom is called with a rename; it returns changes with one entry and the room log is still empty. With the fix the case is green and the log carries exactly one line.

Expected

• At most one line per patch, written through the room's own writer — rt.postToRoom(room, { id: 'face-notice', name: who }, '<who> <sentence>', { quiet: true, notice: true }) — so it is stored and rendered like every other room event, carries no Bot turn and opens no round.
• who = actor?.displayName ?? rt.botOf(actorId)?.name ?? 'Someone', because the API passes actor and the tool surface passes self only; both sides must name the same person.
• Several fields in one patch collapse into one sentence (A and B), never one line per field.
• Only when a value actually changed: writing the same value back posts nothing (the rule #1939 settled for the notice).
• Member changes keep their own lines: added/removed stay joined/left and do not also produce a settings line; an implicit clear (patch.admin / patch.taskLead absent while a member leaves) posts nothing; the automatic title following membership posts nothing.
• No new envelope, and no change to the join push for name and notice.

Scope

• core/src/host/roster.js — updateRoom: after rt.save() and the join push, render the collected settings phrases into that one line.
• core/test/remote-room.test.js — the case above (one patch, one line; unchanged value, no line; several fields, one sentence).
• core/test/task-drive.test.js — its existing calls('war') === 0 assertion takes its baseline after setup, because the setup's own updateRoom calls now emit a line. That case guards the driver not posting into the room, not updateRoom; no other assertion moves.
• docs/subsystems/core-host.md — one sentence next to the settings/notice paragraph, with this issue's link.
• changelog.d/<this issue>-room-settings-line.fixed.md.
• patches/ds-bot/ regenerated (generate, then check): 0002-flybot-api-host.patch, files/test/remote-room.test.js, files/test/task-drive.test.js.

Not in scope: workDir (the five fields above only); pushing settings to remote seats (that is #1949/#1939 for name and notice, and stays their own path); store.js's startup recompute; the shape of the returned changes array or its API consumers.

Overlap with #1961 (adjacent, not the same change)

#1961 (merged as 4accf1e2cb40445f4dd7dd37b4a2704bb1cc6508) touched docs/subsystems/core-host.md in the Room context budget (#1203) paragraph (:183). This issue adds one sentence to the shared room bullet (:329). The two hunks are 146 lines apart, neither rewrites the other's wording, and the two changelog.d/ fragments have different names (1960-… vs 1962-…); the remaining 7 files do not overlap at all. So the only common file is that one doc, and even there it is paragraph adjacency, not one shared edit. The PR rebases onto 4accf1e2, so no hunk here sits on top of #1961's.

Dedupe (against live main 4accf1e2)

• core/src/host/roster.js updateRoom has no postToRoom call: it collects changes and posts nothing.
• Closed issues searched: #1949/#1952 (a rename reaches the guests already seated), #1939/#1942 (an edited notice reaches the guests), #1764/#1771 (a face-to-face room's rename check) — all about remote propagation or validation, none about a visible line in the room. "room settings" search: 0 hits. face-notice hits are unrelated features.

Line numbers are against 54dad6b8; the PR tree may shift them by the import it adds.

Found by us: the failing test and the fix were both verified before this issue was opened.