test: pin the three settings silences #1964 introduced (unnamed title, cleared task lead, mode write-back) #1965

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: 3f5368ad4cc745d39e5a600f9c876d6f
Branch: dev/1-settings-silent-tests
Base: beba27a
At: 2026-11-01T02:17:38Z

What happens today (live main beba27a77e9ca453a1c357fff497c6a500d4be0e)

#1964 (core/src/host/roster.js updateRoom) draws at most one settings line per patch, and it is careful to stay silent in three cases. All three behaviours are correct today, and none of them has a test. Deleting the guard leaves the whole core suite (2362 cases) green.

The guards, as of this ref:

• An unnamed room's title follows its members. roster.js:477 recomputes room.name = autoRoomName(...) when !room.named, and :483 only draws a rename when the patch itself carried a name:

  if (patch.name !== undefined) settings.push(`renamed the room to “${room.name}”`)

• A seat change that empties the task lead is not a settings change. :403 clears taskLead when it is no longer a member, but only :443 draws the line, and only for an explicit patch field:

  if (patch.taskLead !== undefined) settings.push(...)

• Writing back the reply mode the room already holds says nothing. :445:

  if (patch.mode !== undefined && patch.mode !== room.mode) { ... }

Why this is worth a test

#1964's own body claims the new case covers "an unnamed room's automatic title". It does not: swapping any of the three guards out under the new case leaves it green. The silence is the behaviour, so without a case the next refactor of updateRoom can turn any of the three into a line in every room — and nothing goes red. That is how #1962 happened in the first place: a settings save that said nothing when it should have.

The three behaviours were confirmed by direct probes on the merged tree (real relay, not postToRoom arguments): adding a member to an unnamed room moves the title You, Chief, Writer → You, Chief, Writer, Extra and posts 0 lines; removing the task-lead member posts 0 lines; writing back the same mode posts 0 lines. With the guard removed, the probes post exactly one line each (Someone renamed the room to “…”, Someone let the admin lead the board again, Someone switched …) — that is the mutation each new case has to catch.

What to add

Three cases in core/test/remote-room.test.js, beside the existing a settings patch leaves one visible line in the room, and only when a value changed case, driving the public updateRoom (same fixtures as that case):

1. unnamed room + member added → the title moves, postToRoom got no settings line. Assert the new title too, so the case cannot pass by the title never moving.
2. member removed who was the task lead → room.taskLead is cleared and no settings line is posted.
3. mode written back with the value the room already holds → no settings line, and room.mode unchanged.

Each case must fail when its guard is removed and only that case, on the same tree — that is the acceptance, not "the suite is green".

Scope

• core/test/remote-room.test.js — the three cases.
• patches/ds-bot/files/test/remote-room.test.js — mirror, by generate (do not hand-edit).
• changelog.d/<this issue>-settings-silences.tests.md (or the type changelog.mjs check accepts for a test-only change — run the checker and use what passes).

Not in scope

• Any change to core/src/host/roster.js or any other source file: the behaviour is right, this issue only pins it. If a new case cannot be made green without a source change, stop and report — that is a finding, not a licence to edit the source.
• Re-testing the three paths that #1964 already covers (explicit rename, notice, admin, several fields in one patch, write-back of the values the room holds).
• workDir, which draws no line by design.

Duplicate check

Open issues searched for unnamed room automatic title, settings line, taskLead clearing — no issue covers this; #1962/#1964 are the change itself (closed).

Residual note carried with #1967

These three are silences, not naming: closing this issue says nothing about which name a settings line carries. When #1967 closes, a default install may still read owner-1 updated the group notice, because the bootstrap member record carries no displayName (see the residual section on #1967). Do not read this issue's closure as "the local user is now named".