[HugoXK]

Fixes #2512

Owner: Dev-2
Reviewer: Birfy
Written-by: FlyBot Dev-2
Claim-Id: 660434858f894844b50bfa7688ee56ae
Risk tier: T1

What changes

A read-only (locked) window's Drawer overview of a face-to-face room still drew the Room lead card's Change, and, for anyone the host reports as not able to pick, the sentence Only the person who created this room can change it.. Neither belongs there:

• social/face-lead is registered without { read: true } (plugins/social/src/social.js:4684), so the host's channel layer answers it bot/read-only. Pressing Change is therefore a live-looking control whose only possible result is a refusal.
• the "only the person who created this room" sentence is false for the creator in a locked window: the creator can change the lead, just not from this window, so the line explains the wrong reason.
• FaceLead (core/src/client/group-settings.js) decided with lead.canPick === true && typeof pick === 'function', and the host reports canPick: true for the room's creator regardless of the window (plugins/social/src/face-rooms.js:519, core/src/host/face-lead.js:29 passes it through). The card already receives the roster, so it can tell a locked window from a writable one itself; nothing has to be threaded down from details-drawer.js.

The fix is one guard in the card: FaceLead reads lockedWindow(roster) (the same helper every other read-only surface uses, core/src/client/schedules.js:141), folds it into canPick (!locked && lead.canPick === true && typeof pick === 'function'), and skips the only-the-person hint when locked. A locked card keeps the lead's name, its Bot (person) label, its Lead tag and the sentence about what the lead does; it draws no Change, no picker, no Make lead, no Use the default lead and no refusal hint. A writable window is byte-identical to the base: Change → picker → one press sends exactly one social/face-lead, and a non-creator still reads the only-the-person sentence.

Rebased onto b38ec011d7dc3df13d76c8bf60af205534b2d69d (#2509, merged after this branch was first pushed). The rebase merged patches/ds-bot/0008-client-bundle.patch and patches/ds-bot/0012-room-membership.patch without a conflict, and generate stayed a no-op afterwards, so no patch was hand-edited or regenerated for the rebase.

Scope: core/src/client/group-settings.js, one new test file, one doc sentence, one changelog fragment, and the regenerated core/client.js plus the patches/ds-bot/ copies the repo's build requires. details-drawer.js, the host's social/face-lead registration, face-rooms.js and every other read-only surface are untouched.

Acceptance

In a read-only window, opening a face room's Drawer overview:

• the Room lead card is still drawn and still names the lead (Room lead, Chief (Ann)) with the sentence about what the lead does;
• the card offers no button at all — the case asserts buttonLabels(card) is [], not merely that a drawn button is disabled — so Change, Make lead and Use the default lead are all absent;
• the Only the person who created this room can change it. hint is not drawn (it is false for the creator here), for the creator and for a non-creator alike;
• drawing the card reaches the host with nothing (hostCalls is empty), so nothing is attempted and no bot/read-only can come back.

The neighbouring writable control, in the same test file, is unchanged: Change is drawn, pressing it lists the other seat with Make lead, one press is exactly [['social/face-lead', { roomId: 'face', bot: '@writer.bob.home' }]], someone who is not the creator still sees no Change and does read the only-the-person sentence.

Red first

On the clean base b38ec011d7dc3df13d76c8bf60af205534b2d69d (the rebased base), in a throwaway detached worktree at that commit with the base source untouched and only this branch's test file added, node --import ./test/harness-resolve.mjs --test test/details-face-lead-readonly.test.js under TZ=UTC:

not ok 1 - a read-only window draws the room lead as text: no Change, no picker, no refusal hint
    the card itself offers no control
  + [ 'Change' ]  − []
not ok 2 - a read-only window draws no Change for the creator and no refusal hint for anyone else
    the creator cannot change the lead in a read-only window either
  + { type: 'button', props: { className: 'bt-mini', children: [ 'Change' ], onClick: [Function: onClick] } }  − undefined
ok 3 - a writable window keeps Change, the picker and exactly one social/face-lead write
# tests 3
# pass 1
# fail 2

These are the same two not ok lines the pre-rebase run produced on e5fc62dea0c067a308fbf8f122d691a35e455fb1: 3 tests, 1 pass, 2 fail. With the fix in place the same file is 3/3 green, and the writable positive control is unchanged from the base.

What I ran at fc6a6fa84845274f5631f6a7b837392555265dd0 (TZ=UTC, clean tree, tree 347a8a98)

• node core/scripts/build-client.mjs then node scripts/ds-bot-patches.mjs generate on the committed tree: both wrote the same bytes back (git status --porcelain empty afterwards), and npm run verify's own canonical gate reports ok patches/ds-bot/ is what generate writes (generate is a no-op).
• node scripts/ds-bot-patches.mjs check (inside verify) — ok 10 patches apply cleanly in order, ok core/ equals ds-bot/ + patches/ds-bot/.
• TZ=UTC ARCH_DOCS_BASE=b38ec011d7dc3df13d76c8bf60af205534b2d69d npm run verify — exit 0. Segment counts, each # fail 0: core 2920 passed, plugins/social 577, plugins/tree 137, plugins/timeline 141, plugins/workflow 440, .github/scripts + policy 671, test:interop 37, test:live-e2e 26 — 4949 tests, 0 failed. arch-docs: OK (8 changed file(s)); lint Found 0 warnings and 0 errors.; build-client.mjs --check green in the same run.
• The 13 neighbouring read-only suites (face-lead, settings-readonly-pages, settings-readonly-head, details-bot-settings-readonly, details-face-lead-readonly, details-group-overview-readonly, details-group-settings-readonly, details-overview-readonly, room-approvals-readonly, group-create-readonly, composer-send-readonly, readonly-window-reads, approvals-readonly): 52/52, 0 failed.
• git status --porcelain — empty on the committed tree.

What I did not run

• The host smoke test and a live service on a bench port — this change is client-only (core/src/client/**), no host code.
• #2509 / #2510's surfaces and any other read-only card — out of scope for this issue and untouched here.

Files

8 files, +400/−11 (git diff --numstat b38ec011...fc6a6fa8), tree 347a8a98:

• core/src/client/group-settings.js (+8/−2) — FaceLead reads lockedWindow(roster), folds it into canPick, and skips the only-the-person hint when locked; hand-written.
• core/test/details-face-lead-readonly.test.js (+187, new) — the two read-only cases plus the writable positive control; hand-written.
• docs/subsystems/core-client.md (+1/−1) — the face-room lead paragraph gains the locked-window sentence and points at the test.
• changelog.d/2512-face-lead-readonly.fixed.md (+1, new).
• core/client.js (+3/−2), patches/ds-bot/0008-client-bundle.patch (+4/−3), patches/ds-bot/0012-room-membership.patch (+9/−3), patches/ds-bot/files/test/details-face-lead-readonly.test.js (+187, new) — generated by build + generate, never hand-edited.

{
  "pr": 2513,
  "claim": "Dev-2",
  "issue": 2512,
  "summary": "A read-only window's face-room overview no longer draws the Room lead card's Change: social/face-lead is a write the host answers bot/read-only, and the host still reports canPick true for the room's creator. FaceLead now reads lockedWindow(roster) itself, so canPick is false even for the creator and the 'only the person who created this room' hint is skipped as false there. A locked card keeps the lead's name and its sentence only; a writable window is unchanged, one press still sends exactly one social/face-lead.",
  "files": [
    "core/src/client/group-settings.js",
    "core/test/details-face-lead-readonly.test.js",
    "docs/subsystems/core-client.md",
    "changelog.d/2512-face-lead-readonly.fixed.md"
  ],
  "checks": { "ran": "TZ=UTC ARCH_DOCS_BASE=b38ec011 npm run verify (plus build-client and ds-bot-patches check/generate)", "result": "green", "at": "fc6a6fa84845274f5631f6a7b837392555265dd0" },
  "next": "none — ready for review"
}