Problem
After #345 the composer shows a live disposition hint (`↵ steer into current turn`, `↵ queue for next turn`, `↵ offline queue`). That fixed the silent-fates bug but did NOT fix the underlying UX confusion: the user shouldn't have to know what `steer` vs `queue` means.
Today the user has to model the engine's state machine in their head:
| Engine state |
What Enter does |
Wait, why? |
| Idle + online |
Sends immediately |
OK fine |
| Busy + streaming |
Queues for next turn |
Why isn't this sending? |
| Busy + tool running |
Steers into current turn |
Why is this different from streaming? |
| Offline |
Offline queue |
OK fine |
Two of the four cases require the user to understand the difference between "the model is generating tokens" and "the model is waiting for a tool result" — which is internal state we shouldn't ask them to track.
Proposal: collapse to one model
Default behaviour: every Enter queues the message. The pending-input-preview widget above the composer (already wired) shows the queue. The engine drains the queue at every turn boundary in FIFO order. No surprise mid-turn steering. Predictable.
Power user opt-in: `Ctrl+Enter` to steer. Forces the message into the current turn even if mid-stream — the existing Steer path, just opt-in instead of default. Hint chip explains.
Composer hints become:
```
↵ send — when idle (queue is empty, engine ready, sends right away)
↵ queue (3) — when busy or queue non-empty (joins the queue, runs after current turn)
Ctrl+↵ steer — advanced: forces into current turn
↵ offline — when offline (joins persistent offline queue)
```
Three states, not four, and the user never has to think about "streaming vs tool".
What stays
What changes
- `App::decide_submit_disposition` defaults to Queue when busy (regardless of streaming vs tool execution); only returns Steer when the user explicitly modifier-keyed.
- Composer hint text simplified per above.
- /help updated.
Acceptance
Problem
After #345 the composer shows a live disposition hint (`↵ steer into current turn`, `↵ queue for next turn`, `↵ offline queue`). That fixed the silent-fates bug but did NOT fix the underlying UX confusion: the user shouldn't have to know what `steer` vs `queue` means.
Today the user has to model the engine's state machine in their head:
Two of the four cases require the user to understand the difference between "the model is generating tokens" and "the model is waiting for a tool result" — which is internal state we shouldn't ask them to track.
Proposal: collapse to one model
Default behaviour: every Enter queues the message. The pending-input-preview widget above the composer (already wired) shows the queue. The engine drains the queue at every turn boundary in FIFO order. No surprise mid-turn steering. Predictable.
Power user opt-in: `Ctrl+Enter` to steer. Forces the message into the current turn even if mid-stream — the existing Steer path, just opt-in instead of default. Hint chip explains.
Composer hints become:
```
↵ send — when idle (queue is empty, engine ready, sends right away)
↵ queue (3) — when busy or queue non-empty (joins the queue, runs after current turn)
Ctrl+↵ steer — advanced: forces into current turn
↵ offline — when offline (joins persistent offline queue)
```
Three states, not four, and the user never has to think about "streaming vs tool".
What stays
What changes
Acceptance