core: a read-only window refuses the reads its own screens ask for #2267

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: e41bbd6fb40f4902bfba93c12d3d4f17
Branch: dev/1-readonly-window-reads
Base: 03a1253
At: 2026-11-03T05:05:26Z

In a read-only window, core/src/host/channel.js refuses requests to endpoints that the same window's own screens ask for on open. The refusal is bot/read-only, which is the right shape for a write and the wrong one for a read: the panel then draws an error where a list belongs, and the reader is told their window is read-only when what actually happened is that the host did not recognise the endpoint as a read.

Reproduction

node probes/readonly-gate.mjs 03a125306226158ae13c1b3a1185e4db30c7ca67 (the host is mounted read-only, the calls are the ones the screens make):

PROBE_OTHER_READS   {"tasks":"bot/read-only","folder-list":"bot/read-only","connector-app-status":"bot/read-only"}
PROBE_PROJECT_READS {"project-read":"bot/read-only","project-board":"bot/read-only","project-team":"bot/read-only",
                     "project-of":"bot/read-only","project-decision":"bot/read-only", …}
PROBE_PROJECT_WRITES {"project-create":"bot/read-only", …}
PROBE_ENV           {"state":"ok","schedules":"ok","workflows":"ok"}

state, schedules and workflows answer, which is the control: the window is read-only, not broken. The nine reads above are refused, and each of them is a call a screen makes to draw itself — the Projects panel, the Bot card's task list, the folder picker's list, the connector status line. Writes are refused too, and must stay refused.

Expected behaviour

• The read endpoints the window's own screens call answer in a read-only window: tasks, projects/project-read, project-board, project-team, project-of, project-decision, project-memory, folders/folder-list, connector-app-status.
• No write endpoint is added. project-create, project-bind, task-create, folder-pick, connector-connect, set-prefs, create-bot, workflow-save still answer bot/read-only in the same window — that refusal is the counter-case, and it is asserted, not assumed.
• A writable window answers exactly as it does today: the change adds entries to the read list and moves nothing else.

Scope

• core/src/host/channel.js — the READS list (+11/−1): the nine endpoints above.
• core/test/readonly-window-reads.test.js — new: the nine reads answer in a read-only window, the eight writes above are still refused, and a writable window is unchanged.
• docs/subsystems/core-host.md — one line on what the read list covers.
• changelog.d/2267-readonly-window-reads.fixed.md — one line.
• Generated: patches/ds-bot/0005-social-seams.patch, patches/ds-bot/files/test/readonly-window-reads.test.js. core/client.js and the 0008 bundle do not move: this is host-side only, which was checked with npm run build and generate leaving both untouched.

Triage

risk-tier computed with the gate's own rule function: T3 — core/src/host/channel.js is T3, the new test and the two patch paths are T1, docs/subsystems/core-host.md is T0. 5 files, +340/−4.

Already checked for a duplicate

Searched before opening: read-only window in titles (34, all either open and about the client's write surfaces — #2246, #2247, #2248, #2253, #2261, #2264, #2265 — or closed client work), "bot/read-only" (130, none about this read list), channel.js READS (104; the two that matter are closed: #1225 "channel: READS lacks delivery-board and delivery-probe, so read-only mode denies both" and its fix #1230 — the same class of defect, a different pair of endpoints, already landed), read-only reads in titles (7, none open on this list). No open issue covers tasks, the project reads, folders/folder-list or connector-app-status in the host read list.