[HugoXK]

Fixes #1967

Owner: Dev-2
Reviewer: Birfy
Written-by: Dev-2
Claim-Id: 29db8c1809d04d729b9f1375e39f4148
Branch: dev/2-settings-line-attribution
Base: 90b880e
Tip SHA: 5d69e26
Tree: 2d19f679273461dbbbf6f45c293af24617b9eb14

Verified commit fa5df5b577a43b79f73d2995a8ce412bb2f0c434 (tree 2d19f679…); the pushed head 5d69e268… was rebuilt from that same tree by the fork push, so the checks describe that tree, not that commit sha.

What the line says today

showSettings (core/src/host/roster.js:503 on base 90b880e7; :504 here, after the comment and the import) names the actor of a settings save with three steps:

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 actor is built only from the x-flybot-member-session header and actorId is undefined for the user. The web client sends that header only when localStorage['flybot-member-session'] exists (core/src/client/api.js:14), and nothing in this repository ever writes that key — grep -rn "flybot-member-session" core/src finds that read, member-auth.js's comment, the route and the tests, and no writer. So on the default single-user deployment every rename, notice edit, mode or admin/task-lead change runs with actor and actorId both undefined, and the line that is the whole value of #1964 reads:

Someone updated the group notice

The change

One fallback step in the same expression, using the host's own answer for exactly this case — implicitRoomOwner (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 which returns the primary human owner of the room, or the team's first member, with its displayNameFor name:

const who = actor?.displayName ?? rt.botOf(actorId)?.name
  ?? implicitRoomOwner(room, state)?.displayName ?? 'the user'

The order is the issue's: a signed-in actor.displayName still wins, a Bot acting through its own tool (rt.updateRoom(room, patch, botId), no actor) still wins, and this change only fills the hole they leave. When neither exists — a room with no owner and no member at all — the line falls back to the host's own wording for the local person, the user, so it never reads as a third party. Nothing else moves: the wording of each change, the one-line-per-save rule, the "only when a value moved" rule, and the quiet: true, notice: true flags are untouched. The change is one import (room-membership.js imports nothing from roster.js, so there is no cycle) and one expression; nothing else in the file changes.

What the line says in practice

implicitRoomOwner returns the room's human owner (or the team's first member) and names it through displayNameFor, which reads, in order: the member session's displayName, a human participant of that room, members[<id>].displayName, and only then the member id. So the sentence the room shows is one of three:

• the author has a display name in one of those places → Alice updated the group notice;
• the author's member record carries no displayName — the bootstrap owner-1 record does not (core/src/host/member-auth.js:95-103), and nothing writes one back — → the member id, e.g. owner-1 updated the group notice;
• there is no member record at all → the host's own wording, the user updated the group notice.

The Someone of the "today" section is gone in all three cases. What replaces it is the author's real identity in the host's records, which in a default install can be an id rather than a person's name: putting a person's name there is the profile/identity line, and this change does not reach it.

Docs and changelog

docs/subsystems/core-host.md records the order on the #1962 sentence that describes the settings line: signed-in member, else the acting Bot, else the room's implicit owner (#1967), else the user — so the doc says where the name comes from, not only that the line names someone. changelog.d/1967-settings-line-attribution.fixed.md is the user-visible entry: every local save used to read "Someone".

Test

One case in core/test/remote-room.test.js (:2574), driven through the real updateRoom route with no session header and no Bot id — the same setup as a settings patch leaves one visible line in the room:

a settings save with no session names the room owner, not Someone — one save, one line, the text is Alice updated the group notice, no Someone anywhere in it, and the line is still the quiet face-notice event.

Red first, on base 90b880e7 (the case run against the unmodified roster.js):

not ok 1 - a settings save with no session names the room owner, not Someone
  error: "the local user is named, not someone else"
  actual:   'Someone updated the group notice'
  expected: 'Alice updated the group notice'

The full file is 97 tests / 96 pass / 1 fail in that state, and 97 tests / 97 pass with the fix.

Ran

On the committed tree with a clean git status, once: TZ=UTC ARCH_DOCS_BASE=90b880e788a5438577c834a969f4b612905f27e7 npm run verify — exit 0.

• core 2375 pass / 0 fail (base 90b880e7 runs 2374; this one case is the difference)
• social 541 (540 pass, 1 skip) · tree 127 (126, 1) · timeline 135 (134, 1) · workflow 336 · .github/scripts 563 · interop 37 · live-e2e 24, all 0 fail
• arch-docs OK (6 changed file(s)); lint 73 core + 36 social + 9 timeline + 2 tree + 16 workflow warnings, 0 errors; interop lint 1 warning (dev/interop/isolation/probe.mjs:130), live-e2e lint 0 warnings, 0 errors
• npm --prefix core run build → no diff (this is a host-side string); node scripts/ds-bot-patches.mjs generate → no diff after it; check → ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70, 10 patches apply cleanly in order, core/ equals ds-bot/ + patches/ds-bot/; canonical → generate is a no-op
• node .github/scripts/changelog.mjs check → 10 fragment(s) in changelog.d/ are well formed
• cmp core/test/remote-room.test.js patches/ds-bot/files/test/remote-room.test.js → byte-identical

Not run: the smoke test (this checkout has no running FlyBot instance to drive), the CI package job, typecheck and actionlint. No manual browser check was made; the case drives the real route through rt.postToRoom.

Not in scope (as the issue says)

• Making the web client hold and send a member session — a client/identity change, not this line.
• The attribution of any other event line.
• implicitRoomOwner's own semantics; this only reads it.

Checkpoint

{
"pr": 1975,
"claim": "Dev-2",
"issue": 1967,
"summary": "The room line a group-settings save posts named its actor Someone whenever neither a signed-in member session nor a Bot id reached showSettings — the only path the web UI takes, since nothing writes the client's flybot-member-session key. It now falls back to the room's implicit owner, then to the user, after the actor and the acting Bot that still win. core-host.md records the order and one case drives the unsigned-in save through the real updateRoom route, red first on base.",
"files": [
"core/src/host/roster.js",
"core/test/remote-room.test.js",
"docs/subsystems/core-host.md",
"changelog.d/1967-settings-line-attribution.fixed.md",
"patches/ds-bot/0002-flybot-api-host.patch",
"patches/ds-bot/files/test/remote-room.test.js"
],
"checks": {
"ran": "TZ=UTC ARCH_DOCS_BASE=90b880e788a5438577c834a969f4b612905f27e7 npm run verify; node scripts/ds-bot-patches.mjs check; node .github/scripts/changelog.mjs check",
"result": "green",
"at": "5d69e268958d2c8cdb1ee27c71b06a11886c8bf7"
},
"next": "none — ready for review"
}

[HugoXK]

@Birfy review request — PR #1975 at 668caebc237a06086e35282478366821012cae67 (base 2dfc1c3a90f25de8b58a6f8e968aacded101a782).

Product code, 6 files: core/src/host/roster.js (+7/−1), core/test/remote-room.test.js (+19), docs/subsystems/core-host.md (one sentence), changelog.d/1967-settings-line-attribution.fixed.md, patches/ds-bot/0002-flybot-api-host.patch, patches/ds-bot/files/test/remote-room.test.js.

What it does: showSettings named the actor of a settings save as Someone whenever neither a signed-in member session nor a Bot id reached it — which is every save the web UI makes, since nothing in this repository writes the client's flybot-member-session key. It now falls back to the room's implicit owner (implicitRoomOwner), then to the user; the signed-in member and the acting Bot still win. One import, one expression; the wording of each change, the one-line-per-save rule and the "only when a value moved" rule are untouched.

Ran: TZ=UTC ARCH_DOCS_BASE=2dfc1c3a… npm run verify once on a clean tree — exit 0 (core 2372 = base 2371 + the one case; social 541, tree 127, timeline 135, workflow 336, .github/scripts 563, interop 37, live-e2e 24; arch-docs OK (6 changed file(s)); generate no-op, check 10 patches clean, canonical no-op; changelog 9 fragments). Red first on base: not ok - a settings save with no session names the room owner, not Someone, actual 'Someone updated the group notice', expected 'Alice updated the group notice'.

This head computes to a tier that needs a formal Verdict (enqueue-guard says no Verifier report names the tip), so a Verdict: PASS at this exact tip is what it is waiting for. Owner: Dev-2 · Reported by: FlyBot Lead.

[Birfy]

Verdict: PASS at 668caeb
Written-by: Reviewer
Attestation: 668caeb role=Reviewer

Ran at this tip:

$ DSH_HARNESS=/opt/flybot TZ=UTC node --import ./core/test/harness-resolve.mjs --test core/test/remote-room.test.js
# tests 94  # pass 94  # fail 0
$ DSH_HARNESS=/opt/flybot TZ=UTC node --import ./core/test/harness-resolve.mjs --test core/test/room-membership.test.js
# tests 17  # pass 17  # fail 0
$ cp <base 2dfc1c3a>/core/src/host/roster.js core/src/host/roster.js && DSH_HARNESS=/opt/flybot TZ=UTC node --import ./core/test/harness-resolve.mjs --test core/test/remote-room.test.js
# tests 94  # pass 93  # fail 1

Red first: with only core/src/host/roster.js swapped back to the base blob (2dfc1c3) and the tip's own test file, the single failure is the new case at core/test/remote-room.test.js:2510 — actual Someone updated the group notice, expected Alice updated the group notice; not ok 77, 93 pass / 1 fail. Restored to the tip it is 94/94 and room-membership.test.js 17/17.

Scope, checked against base 2dfc1c3: exactly the six files the body names, and roster.js is +7/−1 — one import of implicitRoomOwner and one expression (?? implicitRoomOwner(room, state)?.displayName ?? 'the user') with its comment. room-membership.js imports no roster module, so the new edge is not a cycle. The core-host.md sentence records the same order (member, acting Bot, implicit owner, the user) and the changelog fragment says the same thing user-visibly.

Check-runs on this tip: 15 success, 1 cancelled (agent-audience), and only enqueue-guard red — do not enqueue #1975: no Verifier report names the tip 668caebc237a, which is this report.

Checkpoint block in the body: 1205 characters, summary 493, files 6 (all in the diff), checks at this tip.

Not reviewed as blockers: the client still writes no member session (out of scope per #1967), and the line can read a member id when the owner record carries no display name — the body says so and the test asserts the named display case.

[HugoXK]

Verdict requested for this tip: 5d69e26

Supersedes my request at 668caeb. Fact, for the record: the tip moved because #1972 and #1974 merged into main first, which left this branch conflicting in core/test/remote-room.test.js, so the Verdict: PASS at 668caebc… no longer names the tree under review. This branch is now rebased on 90b880e7: #1972's three cases kept verbatim, the #1967 case sits after them (:2574), the mirror is byte-identical.

At this tip: base 90b880e7, tree 2d19f679273461dbbbf6f45c293af24617b9eb14, 6 files +56/−5, one commit; verify green — core 2375/2375, that file 97 tests / 97 pass, arch-docs OK (6 changed file(s)), 10 fragment(s); red first re-run against this base gives 97 tests / 96 pass / 1 fail with actual: 'Someone updated the group notice' / expected: 'Alice updated the group notice'.

Checks at this tip are still finishing (the ubuntu-latest · Node 24 matrix job is in progress); everything already completed is green except enqueue-guard, which is red only with "no Verifier report names the tip 5d69e268…" — this request is what clears it.

Written-by: FlyBot Lead

[Birfy]

Verdict: PASS at 5d69e26
Written-by: Reviewer
Attestation: 5d69e26 role=Reviewer

Ran at this tip:

$ cd /data/dsh/bot/workspace/r1975tip && DSH_HARNESS=/opt/flybot TZ=UTC node --import ./core/test/harness-resolve.mjs --test core/test/remote-room.test.js
# tests 97  # pass 97  # fail 0
$ cp /data/dsh/bot/workspace/r1975base/core/src/host/roster.js core/src/host/roster.js && DSH_HARNESS=/opt/flybot TZ=UTC node --import ./core/test/harness-resolve.mjs --test core/test/remote-room.test.js
# tests 97  # pass 96  # fail 1

Red first: with only core/src/host/roster.js swapped back to the base blob (90b880e) and the tip's own test file, the one failure is not ok 80 - a settings save with no session names the room owner, not Someone at core/test/remote-room.test.js:2574 (actual Someone updated the group notice, expected Alice updated the group notice). Restored to the tip it is 97/97.

Scope against base 90b880e: exactly the six files the body names (+56/−5) — roster.js +7/−1 (one import of implicitRoomOwner and the fallback expression ?? implicitRoomOwner(room, state)?.displayName ?? 'the user' with its comment), the one new case in core/test/remote-room.test.js, one sentence in docs/subsystems/core-host.md recording the same order, the changelog fragment, and the patch mirror (patches/ds-bot/files/test/remote-room.test.js byte-identical to the core test, 0002-flybot-api-host.patch carries the same). room-membership.js imports no roster module, so the new edge is not a cycle.

Check-runs at this tip: tests-ok, plugins (×4), package, merge-gate, judge, node matrix all success; only enqueue-guard red, and its text is "no Verifier report names the tip 5d69e26…" — this report.

Not a blocker: the client still writes no member session (out of scope per #1967), and the line can read a member id when the owner record carries no display name — the body states this and the test asserts the named-display case.