host: a group settings line names the local user as Someone #1967

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: 29db8c1809d04d729b9f1375e39f4148
Branch: dev/1-settings-line-attribution
Base: beba27a
At: 2026-11-01T02:26:27Z

What happens today (live main beba27a77e9ca453a1c357fff497c6a500d4be0e)

#1964 added one line in the room for every group-settings save, and it named the person who saved:

// core/src/host/roster.js:499
function showSettings(room, settings, actor, actorId) {
  const who = actor?.displayName ?? rt.botOf(actorId)?.name ?? 'Someone'

actor is the signed-in member session and actorId is the Bot asking — both come from the room route (core/src/host/channel.js:742), where actorId is undefined for the user and actor is built only from an x-flybot-member-session header. The web client sends that header only when localStorage['flybot-member-session'] exists (core/src/client/api.js:13-15), and nothing in this repository ever writes that key — grep -rn "flybot-member-session" core/src finds the client read, member-auth.js's comment, channel.js and the tests, no writer.

So on the default single-user deployment every rename, notice edit, mode or admin/taskLead change runs with actor = undefined and actorId = undefined, and the line that is the whole value of #1964 — who changed what — says:

Someone updated the group notice

Reproduction (reported by FlyBot Product, verified on this ref)

A full createRuntime with the real update-room route, intercepting rt.postToRoom:

$ node --test --test-name-pattern="PROBE: the settings line"
# PROBE lines=["Someone updated the group notice","Alice renamed the room to “War room 2”"]

The first line is the local path with no session header; the second is the same driver renaming with Alice's signed-in token, which is named correctly. The defect is only the unsigned-in path, which is the path every local user takes.

Expected

• A settings save made by the local user names that user, not Someone. The host already has the exact answer for this case: implicitRoomOwner(room, state) (core/src/host/room-membership.js:116), whose comment is "Unsigned-in cloud UI has no member session. A face room still has one local owner…", and it returns { memberId, displayName } with displayName from displayNameFor (:142).
• Keep the existing order of precedence: an explicit actor.displayName (signed-in member) and rt.botOf(actorId)?.name (a Bot acting) must both still win over the implicit owner — this change may only fill the hole they leave.
• When neither a session nor an implicit owner exists, fall back to the host's own wording for the local person (the user) rather than Someone; the room line should never read as a third party when the local user is the actor.
• No change to what the line says about the change itself, to when it is sent (only when a value actually moves), or to the quiet/notice flags that keep it from opening a turn.

Scope

• core/src/host/roster.js — showSettings only: extend the name fallback with the implicit room owner, then the local-user wording.
• core/test/remote-room.test.js — one case: a settings save with no session header produces a line carrying the room owner's name and no Someone in it (same setup as the existing a settings patch leaves one visible line in the room case).
• patches/ds-bot/ regenerated (generate, then check); changelog.d/<this issue>-settings-line-attribution.fixed.md.

Not in scope: making the web client write and keep a member session (that is a client/identity change, not this line); the attribution of any other event line; implicitRoomOwner's own semantics; anything #1964 already settles (one line per save, no line for a write-back of the same value, no turn opened).

Dedupe (against live main beba27a7)

• Open issues searched for Someone, settings line, attribution, implicitRoomOwner: no hit describes this. #1965 is the adjacent test-only issue for the three silences #1964 introduced — different subject (a line that should not be sent vs. a line sent with the wrong name), so these stay two issues.
• Closed issues: #1962/#1964 are the落地 issue and PR that added the line; neither discusses the name it carries.

Found by FlyBot Product; the probe and the run above are theirs, and the Lead verified the code path on this ref.

Residual behaviour (recorded 2026-11-01, before this closes)

Closing this issue must not read as "the person's name now appears". implicitRoomOwner names the author through displayNameFor (core/src/host/room-membership.js:142), which reads, in order: the member session's displayName, a human participant of that room, members[<id>].displayName, and only then the member id. The bootstrap member record is { id: 'owner-1', createdAt, designatedChiefId } and carries no displayName (core/src/host/member-auth.js:95-103), and nothing in this repository writes one back. So a settings save reads:

• <name> updated the group notice when a display name exists in the session, a room participant or the member record;
• owner-1 updated the group notice when the member record carries no display name — a real identifier, not a person's name;
• the user updated the group notice when there is no member record at all.

The defect this issue reports — the local user's own save speaking as a third party, Someone — is fixed in all three cases. Putting the person's name on that line in a default install needs a display name on the owner's session or member record, which is the profile/identity line and deliberately outside this scope.