core: a read-only window's task board still draws Add task, Start, Complete and drag, and every one is refused #2248

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: 6b7eb5f3029f40dd83a1ebb4cd1e6b0b
Branch: dev/1-p455-readonly-board
Base: 5a21d5b
At: 2026-11-03T01:17:30Z

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

Written-by: FlyBot Lead
Credit: found by FlyBot Product (P-455; same read-only family as #2232, #2235, #2220).
Kind: defect — a read-only window's task board still draws every write control and accepts drags, and each of those writes can only be refused by the host.
Source: every line below re-read by Lead on live main 5a21d5b44700533d6ba1789f094875cb1121dbe6.

Dedupe (searched before opening)

Searched open and closed issues for kanban read-only start complete, task board read-only drag, board New task read-only, kanban readOnly: 18 / 10 / 86 / 1 hits. None covers this surface: #1714/#1183/#1701 are about a read-only projection board over other data; #2215/#2190/#2232 are the workflow, social and schedules surfaces of the same family. grep -n readOnly core/src/client/kanban.js on live main returns 0.

What happens today

core/src/client/kanban.js has no read-only branch at all, so a read-only window draws the board exactly like a writable one:

• New task form / Add task button are drawn and can be submitted;
• every movable card draws Start / Complete and stays draggable;
• a drag onto a column runs the same move path as a writable window.

The host refuses each write (bot/read-only), so the user presses controls that cannot work and gets no explanation in the page.

Reproduction

Open a second window on the same home (the later window is read-only) → open the task board → Add task, Start, Complete are all drawn and cards drag; each action is refused by the host and nothing on the board changes or explains why.

Red-first (captured on 5a21d5b4, tests only, sources untouched)

node --test core/test/kanban.test.js → # tests 28 / # pass 27 / # fail 1:

not ok 27 - P-455: a read-only window draws no write on the task board
  a read-only board draws none of its four writes
  actual   { buttons: ['Add task','Start','Complete'], newTaskForms: 1, draggable: ['task-open123','task-working456'] }
  expected { buttons: [], newTaskForms: 0, draggable: [] }
ok   28 - counter-proof: a writable board keeps all four writes

ok 28 is the counter-proof that must stay green: a writable board keeps Add task / Start / Complete, one New task form, both cards draggable, and still sends taskUpdate on Start and taskCreate from the form.

After the fix the same file is 28/28/0; npm --prefix core test is 2677/2677/0.

Expected

1. A read-only window's board draws none of the four writes: no Add task, no Start/Complete, no drag, no New task form.
2. Everything readable stays: the rail, the three columns, the cards, the archive page and the Done timestamps.
3. A writable window behaves exactly as today (counter-proof above).
4. No new copy is invented on the board; the sidebar's read-only sentence is the explanation that already exists.

Scope

• core/src/client/kanban.js — one locked read of roster.readOnly (the same reading the other client pages use), applied to the form, Start/Complete, the drag handlers and the move/create entry points.
• core/test/kanban.test.js — the two cases above; docs/subsystems/core-client.md one line; changelog.d/ fragment.
• Regenerated core/client.js and patches/ds-bot/0008-client-bundle.patch (bundle lane).
• Out of scope: a read-only sentence drawn inside the board itself.