harness: queue messages while busy (edit + cancel queue)

[btipling]

Summary

While a turn is busy (model streaming / tools running), operators often already know the next prompt(s). Today the harness only has a single in-flight submit path: type → send → wait. There is no way to queue follow-up messages, or to edit / cancel them before they run.

Wanted product behavior: queue one or more messages that fire when the current turn finishes (or according to a clear queue rule), with full control to cancel or edit items still waiting.

Motivation

• Multi-step agent work: prepare the next instruction without waiting for Stop or turn end.
• Avoid losing a typed follow-up when Send is blocked or when focus is on watching tools.
• Safer than spamming Send mid-turn: queue is explicit, reviewable, and cancellable.

Proposed UX (sketch — not a locked plan)

Capability	Behavior
Enqueue	From the Wasm composer while Busy (and optionally when idle): send goes to a queue instead of starting a parallel turn
Visibility	Queued items visible in-canvas (compact list near composer or under Busy chrome) — not a DOM dual chat
Edit	Open/edit queue item text before it starts; save updates the pending payload
Cancel	Remove one item or clear the whole queue; no side effects on the in-flight turn
Ordering	FIFO by default; optional reorder is nice-to-have, not required for v1
When it runs	After the current turn reaches a terminal state (success / error / user Stop), dequeue next and submit as a normal user turn. If a session TODO list is active (#536), queued operator messages run first; only an empty queue may auto-continue the next TODO
Stop interaction	Stop cancels the in-flight turn only unless the user also clears the queue; document the rule. Stop does not erase a cloud TODO list (#536)

Feature-divide: all of this stays Wasm-primary (composer + queue chrome in canvas). Host may hold queue state only as needed for bridge/session restore — no second React chat.

Acceptance ideas

• While Busy, operator can enqueue ≥1 follow-up without aborting the current turn.
• Each queued item can be edited and cancelled before it starts.
• When the turn ends, the next queued message submits automatically as a normal user message (transcript + session consistent). If feat: session TODO lists — one item per turn, host auto-continues with full list in the prompt #536 TODOs are open, queue drains before any TODO auto-continue.
• Empty / whitespace queue payloads rejected like normal send.
• Clear session / Clear transcript also clears the queue (or documents why not).
• Mobile ~390px: queue list usable (scroll or collapse), no dual DOM composer.
• Living docs: docs/harness-limits.md (composer / busy / submit behavior).

Non-goals (v1)

• Parallel multi-turn inference (multiple concurrent Gateway streams).
• Server-side durable job queue across devices (unless later tied to cloud session).
• Editing messages that have already been sent into the transcript (separate feature).

Related

Issue / surface	Role
Protocol v9 Stop cancel	In-flight abort only today
docs/feature-divide.md	Wasm composer is primary input
#349	Keyboard / a11y scoping (queue should stay keyboardable)
#339	Sticky last-user chip — orthogonal scroll UX
#536 session TODOs	Queue before next TODO auto-continue. Either issue can ship first; this precedence is the lock. Stop keeps the TODO list.

What good looks like

Operator is mid-agent turn, types the next three steps into a queue, edits step 2, cancels step 3, and when Busy ends the remaining items run in order without re-fighting the composer.

[btipling]

Cross-locked with #536 (session TODOs, cloud envelope SoT):

Queued operator messages run before the next TODO auto-continue. Stop does not erase that list. Neither issue is a hard blocker of the other.

[btipling]

Plan drafted: #664 (plan: queue messages while busy).

Locks in short: Wasm-ephemeral FIFO, Busy ▶ + Ctrl/Cmd+Enter enqueue, ■ Stop keeps the queue, protocol v18 inv_queued_count so #536 can drain operator messages first. Next: plan-review on #664.

[btipling]

Shipped on main via PR #666. Plan #664 already auto-closed; this source was only Refs’d.

Operators can queue follow-ups while Busy and edit/cancel them in-canvas (protocol v18).