client: a read-only window's face-room overview still draws the Room lead's Change, and a hint that is false there #2512

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: 660434858f894844b50bfa7688ee56ae
Branch: dev/2-face-lead-readonly
Base: e5fc62d
At: 2026-11-05T07:01:59Z

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

Written-by: FlyBot Lead

What a user sees

In a read-only (locked) window, the Drawer overview of a face-to-face room still draws the Room lead card's Change control. Nothing is disabled about it, so pressing it looks like a live action — and the only thing it can return is the host's bot/read-only refusal.

The same card also prints Only the person who created this room can change it. whenever canPick is false. In a read-only window that sentence is false for the room's creator: the creator can change the lead, just not from this window, so the line explains the wrong reason.

A read-only window should show the lead's name and the lead's own hint only. A writable window must stay byte-identical: Change → picker → one press sends exactly one social/face-lead.

Reproduction (live main e5fc62de)

Harness copied from core/test/details-group-overview-readonly.test.js; one face room whose lead is { handle: '@chief.me.home', picked: true, canPick: true, supported: true } (core/test/details-face-lead-readonly.test.js):

# PROBE locked Change buttons: 1
# PROBE writable Change buttons: 1
# PROBE locked face-lead row drawn: 1
row text: Room leadChief (Me)Writes the plan…Change
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

Root cause: FaceLead (core/src/client/group-settings.js) decides with canPick = room.face.lead.canPick === true && typeof pick === 'function'. The host always answers canPick: true for the room's creator, and social/face-lead is registered in plugins/social/src/social.js without { read: true }, so the host's channel layer refuses the write with bot/read-only and the refusal lands in the card's own .bt-error. The card has the roster already, so it can tell a locked window from a writable one itself; passing pick down from details-drawer.js is not the load-bearing part.

Expected behaviour

• read-only window: the lead's name and the lead's own hint, nothing else. No Change, no picker, and no Only the person who created this room can change it. (that sentence is not true here).
• writable window: unchanged — Change opens the picker, and one press sends exactly one social/face-lead; a non-creator still sees the only-the-person sentence.

Scope

• core/src/client/group-settings.js: FaceLead learns the locked state from the roster it already receives and folds it into canPick; the only-the-person hint is skipped when locked.
• core/test/details-face-lead-readonly.test.js: the two read-only cases above plus the writable positive control (red-first on e5fc62de).
• docs/subsystems/core-client.md: the read-only sentence for this card.
• changelog.d/: one fragment.
• Regenerated core/client.js and patches/ds-bot/ (bundle + patch copies), as the repo's build requires.

Dedup

Checked live main and closed issues before opening: face-lead+read-only (7 hits), Room lead+read-only+drawer (17), face+lead+Change+readonly (10).

• client: a read-only window's face-to-face group settings names no Bot, and drops who answers and the working folder #2492 / Name a read-only face room's people instead of calling each one Human #2505 fixed the face room's Settings page (naming the Bots, who answers, working folder) — a different surface.
• client: a read-only window's drawer group settings still draw the live form and say nothing #2387, client: the drawer's overview view hides its refusal line, and a read-only window still draws its write entries #2391, client: a group's overview in a read-only window still draws its rename and Remove my Bot #2400, client: a read-only window still draws Approve/Reject on the room overview card, and the refusal vanishes #2381, social: a read-only window still draws the room overview's Leave, Auto-send and invite, and every one of them only fails #2228 are the other read-only surfaces, all closed.
• The rule behind this class (client: a read-only window's group overview draws no write controls #2401) covered the non-face half only; no issue covers this card's Change control.

Not in scope

A plain (non-face) group's read-only Settings does not draw Who answers / Working folder while the writable page draws both. That is a separate candidate and is not part of this issue.