Settings: a read-only window still draws the write controls on seven pages #2474

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: 73f744da5bfa4285928e180dec40d156
Branch: dev/3-settings-pages-readonly
Base: 9371874
At: 2026-11-05T00:39:33Z

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

Written-by: FlyBot Lead

What happens

A window that holds the team read-only still draws the switch, the field and the button on seven Settings pages. Pressing one is refused by the host with bot/read-only, so the control is drawn, clickable, and answers an error — the person learns the window cannot change the team only after trying.

Verified on live main = 9371874e01059445dfc82d1d72e49434ed605952 (read, not recalled):

lockedWindow is the existing predicate (core/src/client/schedules.js, used by details-drawer.js, create-bot.js, schedules.js, and already by the Projects page in settings.js:275 / :343). The five page modules above contain 0 references to it and 0 to readOnly; settings.js uses it only for the two Projects entry points, so the dialog's own header still only explains the state (bt-hint bt-read-only, role="status") while the pages below keep their live controls.

Expected

In a read-only window each of the seven pages draws no write control: no select, no input, no button that calls a mutating action, no switch. The fact the page is about stays readable as plain text where it carries information (the current Main Bot's name, the current theme's label, the motion setting, the accent in use, each Bot's and group's details, the connected connectors, the granted capabilities, the stored secret names), so a locked window is a readable view rather than a blank page. A page with nothing readable to say may draw the host's own sentence and no section at all.

In a writable window every one of those pages is byte-for-byte what it is today.

Acceptance (red first)

1. For each page: mount it with a read-only roster, count the write controls — select 0, input 0, button 0 whose handler is a mutating action, SwitchRow 0. Red on 9371874e.
2. For each page: mount it writable and compare the rendered tree with today's — unchanged, byte for byte.
3. Facts that carry information survive as text: a Main Bot's name, the theme label, the motion label, the accent in use, the Bot's name/role/model line, the group's name/members, a connector's state, a capability's grant, a secret's name.
4. The dialog header's bt-hint bt-read-only sentence stays exactly once per page (it is the standing explanation; do not duplicate it into every section).
5. Existing Settings tests keep passing unchanged: core/test/settings*.test.js, core/test/settings-pages.test.js (if a rename is unavoidable, say so in the PR body with the reason).

Scope

• core/src/client/settings.js, bot-settings.js, group-settings.js, connectors.js, capability-settings.js, secret-card.js — pass the existing locked/lockedWindow(roster) down and branch on it; no new predicate, no new host field, no new endpoint.
• core/client.js and patches/ds-bot/** regenerated (build-client + generate), since the client bundle is generated from these files.
• tests under core/test/, one changelog.d/*.fixed.md, and one sentence in docs/subsystems/core-client.md.
• Not in this issue: the Groups list page's Create group chat button (P-570, tracked separately), the Projects page and the Project board (already fixed by Settings: a read-only window still draws the Projects write controls #2463 / Project board: a read-only window still draws the settings write controls #2464), the Create-Bot form (Draw the read-only sentence instead of Create in the new-Bot form #2465), the drawer's group settings (client: a read-only window's drawer group settings still draw the live form and say nothing #2387 / client: a read-only window's drawer group settings say so instead of the live form #2389).

Tier: every changed path here is core/src/client/**, core/test/**, docs/**, patches/ds-bot/** or changelog.d/** — all exempt, so this is T0/T1 and needs no Verdict: PASS; enqueue-guard goes green on green checks alone.

Dedupe (checked 2026-11-05 before opening)

repo:ThinkFlowLab/FlyBot "settings" "read-only", lockedWindow settings, "Main Bot" read-only, "Bot animation" — the hits are closed and each is a different page: #2264 / #2253 (menus), #2307 / #2465 (Create-Bot form), #2305 / #2463 (Projects), #2306 / #2464 (Project board), #2176 / #2181 (Workflows Edit), #2310 (approval cards), #2387 / #2389 (drawer group settings), #2333 (Feedback Clear), #2199 (the dialog header sentence this issue keeps). MainBotsSection and MotionSection have zero hits anywhere, and "Bot animation" returns only the unrelated #1459. Nothing open covers these seven pages.

Update 2026-11-05 (after Dev-3 read the code)

The New Bot button on the Bots list is not in scope as a write control: it only opens the form, and that form is already read-only (create-bot.js, #2465). Keep the entry, keep its form locked. The same reasoning as #2305 / #2306: an entry point may stay visible while nothing it opens can write.

host evidence that every control above is refused today: core/src/host/channel.js READS (:237-239) holds neither set-prefs nor set-main, and :307 refuses any endpoint outside READS with bot/read-only.