Thread outbox: UI polish, queue images, send-and-interrupt — and decide whether the queue should survive

[radroid]

Follow-up on the thread outbox (queue-while-running) feature from #26. Three concrete gaps plus one
design decision that should be settled first, because it changes how much of the rest is worth
building.

---

0. The decision: does the queue earn its keep?

The queue exists because you can't talk to a running turn. The alternative is send-and-interrupt:
type, hit send, the current turn is interrupted and your message starts the next one immediately.
That is what most agent UIs do, and it is what people reach for reflexively.

I checked whether upstream already covers this — it does not:

// packages/contracts/src/provider.ts:87
export const ProviderInterruptTurnInput = Schema.Struct({
  threadId: ThreadId,
  turnId: Schema.optional(TurnId),
});

Interrupt is a pure stop with no message payload, so there is no upstream path that both stops the
turn and submits text. The queue is not redundant today.

But if we add send-and-interrupt, the queue's genuinely unique value shrinks to:

• Deferred send — "finish what you're doing, then do this" (interrupting would discard in-flight work)
• Disconnected buffering — composing while the backend is unreachable
• Survives reload — localStorage-backed, so a refresh doesn't lose the message

Those are real, but they are a much smaller feature than what exists now. Decide first: keep the
queue as the primary mid-turn path, demote it to a secondary "send after this turn" affordance behind
send-and-interrupt, or remove it. Everything below assumes it survives in some form.

---

1. The queue UI is visually heavy

From the current build (screenshot in thread):

• The queued-message list renders as a full-width bordered card stacked on a bordered composer,
  producing a heavy double-border container that dominates the bottom of the thread.
• A one-line message gets a card with card-sized vertical padding. With 3-4 queued messages this
  pushes the composer far up the viewport.
• QUEUED MESSAGE · 1 sits as a caption colliding with the container's top border.
• Edit (pencil) and delete (trash) icons are pinned to the far right, visually detached from the text
  they act on, and are always visible rather than on hover/focus.
• The footer now carries three competing controls — a progress spinner, a saturated red stop
  button, and a blue "Queue" button. The red is the highest-contrast element in the composer despite
  being the secondary action.
• Nothing states the contract: that these send automatically when the turn finishes.
• No reordering. removeThreadOutboxMessage exists but there is no move-up/move-down or drag.

Suggested direction: collapse each queued item to a single dense row (one line, truncated, hover-
revealed actions), drop the nested border so the queue reads as part of the composer chrome rather
than a second panel, and add a short "Sends when this turn finishes" hint.

2. Images can't be queued

Reproducer: attach an image while a turn is running, add text, press Queue. The text queues, the image
is dropped, and you get a warning toast:

Images aren't queued — Queued messages are text-only; attached images were not added to the
queued message.

Image-only (no text) is refused outright with a similar toast.

The current behaviour is deliberate and correctly implemented — the code comments in
ChatView.tsx explain the reasoning, and the toast fires only after a successful enqueue so a failed
enqueue never misreports. The limitation is the storage layer:

// apps/web/src/outbox/threadOutboxStorage.ts
// localStorage-backed persistence for the thread outbox ...

localStorage is string-only with a ~5MB quota, so blob-backed image previews cannot survive a
reload. Queuing images needs the outbox moved to IndexedDB (stores Blobs natively, far larger
quota), with the queued item holding a blob reference and the drain rehydrating it at send time.
Needs a migration path for messages already in localStorage, and a quota/eviction story.

Note this also affects the mobile outbox, which mirrors the same design.

3. Send-and-interrupt

Add a way to stop the running turn and immediately send the composed message. Requires a contract
change — either a new RPC or an optional message payload on the interrupt input, since the current
one carries none. Should be explicit rather than the default Enter behaviour, so nobody discards a
long-running turn by muscle memory.

---

Suggested order

1. Settle §0 — it determines whether §1 is polish or removal.
2. §3 send-and-interrupt (contract change, highest user value).
3. §1 UI polish, scoped by the §0 outcome.
4. §2 images — largest change (storage migration), lowest urgency given the toast is honest today.

[radroid]

Decisions and status

§0 — the queue stays, and send-and-interrupt is not being built. The existing Stop button is
good enough for the "stop this and do my thing instead" need, so the queue keeps its current role
rather than being demoted or removed. Nothing merged in #26 is being deleted.

Worth recording why Stop covers it, because it is not obvious from the issue text: reading the
code, Stop already behaves as send-and-interrupt when something is queued. thread.turn.interrupt
leaves the turn interrupted with a completedAt and the session interrupted/stopped
(ProjectionPipeline.ts:1299-1332, :1103-1112), and canSettle accepts any session status that is
not starting/running (threadSettled.ts:78-91). So resolveThreadOutboxDeliveryAction returns
send and the drain dispatches the head within a tick of the Stop. Queue a message, press Stop, and
it starts immediately — which is exactly the §3 interaction, with no contract change.

Two caveats on that. It is a code-reading result, not a runtime one — I could not produce a real
running turn in a sandbox (the local provider's OAuth is stale). And the flip side is that Stop
does not stop the queue: with three messages queued, Stop fires the next one rather than stopping
everything. There is no pause or clear-all affordance. If that turns out to be the wrong default, the
seam is a new input to resolveThreadOutboxDeliveryAction (threadOutbox.logic.ts:146), which is a
pure function and already fully unit-tested.

§1 has landed on t3x/issue-35-outbox-interrupt-and-polish: dense single-line rows, the nested
card border removed so the queue reads as the top section of the composer surface, the caption moved
inside the padded block and now carrying the contract ("Sends automatically when the chat is ready"),
hover/focus-revealed row actions, a scroll cap so a long queue stops pushing the composer up, and
move up/down reordering. A four-message queue now occupies ~130px against ~230px before. Stop also
drops to a quiet outline when it sits beside Queue, so the red circle is no longer the
highest-contrast element in a composer whose primary action is Queue.

One correction to the §1 list: the "progress spinner" in the footer is upstream's context-window
meter (ContextWindowMeter.tsx), an SVG ring that renders whenever a context window is known, not
a progress indicator for the running turn. There is no spinner in the running-turn footer. I left it
alone — it is upstream's and it is doing its job.

---

§2 (queued images) — deferring, and this is why

Closing this out as not worth the effort right now. Recommend leaving it parked rather than
scheduling it.

The one-line version of the issue text — "move the outbox to IndexedDB" — undersells it, and the
premise is also slightly off. Mobile does queue images today, and it does not use a blob store to
do it: QueuedThreadMessageSchema carries a required attachments array persisted as inline
base64 data URLs (apps/mobile/src/state/thread-outbox-model.ts:46). So the web port did not
simply skip a feature; base64 inflates payloads ~33%, and localStorage's ~5MB quota is per-origin and
shared with every other thing the app stores there. Two screenshots would plausibly exhaust it, and
the failure mode is a QuotaExceededError that rejects the enqueue. Copying mobile's approach is not
an option on web, which is why IndexedDB comes up at all.

The port itself is genuinely cheap. ThreadOutboxStorage is a clean three-method,
already-Promise-returning seam (threadOutboxStorage.ts:35-39), injected in exactly one place
(threadOutbox.ts:16-19), and no call site reaches into localStorage directly. An IDB
implementation is one new module plus one changed line.

Everything around it is where the cost is:

1. A data migration with a silent-data-loss trap. Existing t3code:thread-outbox:v1:* records
   have to be read, upserted into IDB and deleted, including the case where both stores hold the same
   messageId. Adding attachments also means a schema change, and schemaVersion is a
   Schema.Literals([1]) (threadOutbox.logic.ts:34) while storage swallows decode failures as
   console.warn "skip invalid" (threadOutboxStorage.ts:82-94). Bump it without accepting the old
   value and every user's queued messages are silently deleted on upgrade, with no error anywhere.
2. Blob rehydration at send time. The drain currently sends attachments: []
   (useThreadOutboxDrain.ts:210-226). Queued images mean holding a blob reference, rehydrating it at
   dispatch, and deciding what happens when the blob is gone but the text is not.
3. A quota and eviction story that does not exist today. IDB quota errors are async and
   per-transaction; the manager's durable-write-first invariant depends on storage rejections
   rejecting (threadOutboxManager.ts:104-112). Someone has to decide what gets evicted, when, and
   what the user is told.
4. Invariants the new backend must preserve or quietly break things. load must return every
   message across all environments — clearEnvironment depends on it surfacing persisted-only
   "zombies" so a re-added server cannot resurrect and silently deliver old messages
   (threadOutboxManager.ts:173-188, covered by test). Per-record fault isolation must survive. And
   the no-window/blocked-storage fallback needs handling (today write silently no-ops with no
   window, so an enqueue "succeeds" non-durably — a pre-existing hole worth fixing regardless).
5. More delta on the repo's worst seam. Removing the two toasts and the image-only refusal means
   editing ChatView.tsx (:4571-4589, :4619-4631), already the highest-risk file in the fork
   ledger at risk 9540.
6. Mobile. Web-on-IDB and mobile-on-base64 diverge further, so either the divergence is recorded
   or mobile converges too — a second, unrelated migration.

Against all that, the current behaviour is honest rather than broken. The toast fires only after a
successful enqueue, so a failed enqueue never misreports; an image-only submit is refused outright
and the draft is left intact so the image is never destroyed; and the user is told plainly that they
can wait for the chat to idle and send with the image. The gap is disclosed, not silent — which is
what makes it safe to leave.

Happy to pick this up if it starts biting in practice; the storage seam means the work will not have
gotten harder in the meantime.