A read-only window's composer still writes: Send to a Bot, and a multi-pick Send creates a room #2499

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: 6d33e6a7139c42a98d694733c9a2bbc4
Branch: dev/2-newchat-send-readonly
Base: e1b8b3e
At: 2026-11-05T03:50:06Z

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

Written-by: FlyBot Lead

What happens

In a window that holds the team read-only (roster.readOnly set by the host), the new-chat composer still offers a working Send, and two of its three shapes write to the host and only then get refused with bot/read-only.

core/src/client/new-chat.js on live main (e1b8b3eb) has no lock check on the send path at all:

• sendMessage (:138-156): one pick → actions.send(picked[0], text) (:143); several picks with no admin → actions.createRoom(members, …) (:153) followed by actions.send(room.id, text) (:154).
• openBot (:101-107): not in group mode and nothing picked → actions.send(bot.id, message.trim()) (:105).

So a reader in a read-only window types a message, presses Send, and the host refuses it after the fact — for the multi-pick shape the refusal lands on create-room, which is a write too. send and create-room are not in the host's READS set (core/src/host/channel.js:241), so :312 (!READS.has(endpoint) && !flybotRead → fail(readOnly, 'bot/read-only')) rejects both.

Expected behaviour

• In a read-only window, pressing Send never reaches the host: no send, no create-room.
• The picker stays usable as a preview (the same shape #2479/#2489/#2492/#2496 use for their pages).
• The host's own sentence (hostText(roster.readOnly)) appears once near the composer in .bt-hint.bt-read-only with role="status", instead of the user finding out from a failed call.
• openBot's send path is covered by the same lock; opening a session may stay possible (it is a read).
• A writable window renders and behaves exactly as before (readOnly undefined, '', or whitespace).

Why this is a separate issue from #2496

#2496 covers the two group-creation entries (Settings → Group chats and the New… menu row); its diff leaves the composer's own Send alone on purpose, and it says so in its body ("out of scope: the plain Send to one Bot, and the multi-pick Send with no admin"). This issue is that remainder — same file, different function.

Scope

• core/src/client/new-chat.js — the send path (sendMessage, openBot) and the composer's hint.
• A regression test that drives the composer in a read-only roster and asserts zero send / create-room calls, plus the writable control.
• docs/subsystems/core-client.md and a changelog.d/ fragment; regenerate core/client.js and the patches/ds-bot/* this file belongs to.
• Do not touch: the group-creation paths from #2496, service.js, core/src/host/**.

Red-first shape

Four cases, three red on a clean main with only the new test applied (one green control): read-only single-pick Send sends nothing; read-only multi-pick Send creates nothing; read-only openBot with typed text sends nothing; writable single-pick Send still sends once. A run of the file in a writable roster must be unchanged.

Dedupe (2026-11-05, before opening)

• search read-only send in:title → 2 hits, both closed and unrelated (#2188 sidebar sentence, #2167 diagnostics report).
• search readonly send NewChat and read-only NewChat → only #2496/#2498 (the same issue, group creation only).
• No open or closed issue covers the composer's Send path; no live claim.