core: a read-only window's Feedback Clear truncates the shared diagnostics log #2302

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: c81fdade23f644ae92a75d596561e7e0
Branch: dev/1-p497-readonly-diagnostics-clear
Base: c776ffc
At: 2026-11-03T12:33:58Z

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

Written-by: FlyBot Lead
Reported-by: FlyBot Product
Surface: core client + host reading channel
Kind: defect — a read-only window destroys data

What happens

In a read-only FlyBot window (the roster's readOnly is a non-empty string) Settings → Feedback still draws Clear, and pressing it truncates the shared <home>/logs/diagnostics.jsonl to 0 bytes.

Read at live main a304efa3:

• core/src/host/channel.js:234 lists diagnostics-clear inside READS, so the reading channel treats it as a read and lets a read-only window run it; :660 then calls rt.diagnostics.clear(), which rewrites the log (core/src/host/diagnostics.js:292, writeFile(logPath, '', 'utf8')).
• The comment directly above that set (channel.js:231-233) states that each handler there only reads, and that a read here is "an empty screen, never a change made through the reading window".
• core/src/client/feedback.js:118 draws Clear unconditionally (disabled: !report || total === 0) with no lockedWindow check, and core/src/client/settings.js:253 mounts FeedbackPage without passing roster.

Reproduction

Product's probe on a clean tree, through the window's own API:

PROBE_DIAG_CLEAR {"bytesBefore":68,"bytesAfter":0,"reply":{"ok":true,"value":true},"readOnly":"The Bot team in … is open in another dsh …"}

In the same lock task-create is still refused with bot/read-only, so the lock itself works — this name is simply classified as a read. Probe and evidence stay outside the repository: probes/diagnostics-clear-readonly.test.mjs, probes/evidence/diagnostics-clear-readonly-d90d9359.txt. The running instance at f88d9133 carries the same path (channel.js:227, feedback.js:85), so the hole is live.

Expected

Both halves, otherwise a hole remains: a read-only window does not draw Clear, and the host refuses diagnostics-clear through the reading channel. Client-only leaves the scripted path able to truncate the log; host-only leaves a button that fails when pressed.

update-install / dsh-update-install stay in READS — they change the dsh profile, not the team. diagnostics-clear has no such note, and what it destroys is the evidence a bug report is supposed to carry.

Scope

Small, client bundle lane (it regenerates the bundle): drop the name from READS with a one-line note; pass roster into FeedbackPage; gate Clear behind the existing lockedWindow; add ['diagnostics-clear', {}] to the WRITES table in core/test/readonly-window-reads.test.js (red first — today the name sits in neither refused nor allowed); mirror into patches/ds-bot/files/… and generate; one line each in the core-host and core-client docs.

Dedupe (2026-11-03): search diagnostics-clear → 0 open (the 3 closed are link/hard-link writes, #2089/#2094/#2162); read-only + diagnostics → #2153/#2134/#2167 are wording reports and closed; #2284/#2275/#2276/#2199/#2243 are other surfaces.