Steered input is not inserted as the newest history entry: it lands above in-flight work and reads as out of order

[Hmbown]

What the user sees

Steering a message while the agent is working does not place it as the newest
thing in the transcript. It appears above some of the work that is already on
screen, so the timeline the user reads does not match the order things happened.
Reported as confusing: you send a correction, and it shows up in the middle of
the output rather than after it.

Why it matters

Steering is a control action. If the transcript does not show the steer as the
most recent event, the user cannot tell whether it was received, when it took
effect, or what the agent had already produced when it arrived. The ordering is
the receipt.

Expected

A steered message should be the newest entry in the transcript at the moment it
is accepted, and whatever the agent produces afterwards should follow it.
Anything already accepted before the steer stays above it.

To be confirmed

• Whether the transcript ordering or the underlying message ordering is at
  fault (or both).
• Whether this is TUI-only or shared with other clients on the same event
  stream.
• Whether the in-flight assistant message is split at the steer boundary, and
  what the intended presentation is for the partial response that precedes it.

Not yet investigated; filed so it is not lost.

[Hmbown]

Intended behaviour (founder, 2026-09-15)

it should land like exactly where it would in the transcript i think? so maybe it needs to interrupt thinking or something like that. maybe we don't have it quite working as steering vs. queueing after all?

So the intended placement is the natural transcript position — a steer should appear exactly where it happened relative to the other entries, not appended after output that was produced before it arrived. If the assistant is mid-thought when the steer lands, the thinking should be interrupted so the steer can take its correct place.

The open question this raises: whether steering and queueing are actually distinguished today. A steer that takes effect only after the current turn finishes is a queue, not a steer — and if the two paths share machinery, the visible ordering is a symptom of that rather than a separate defect. Worth establishing which is true before changing the placement logic.

[Hmbown]

Diagnosis

Two mechanisms combine, and they are the reason this reads as confusing rather than as a simple ordering bug.

1. Steer does not interrupt. It lands at the next provider-request boundary.

crates/tui/src/core/engine.rs:1285 -- next_turn_steer() drains rx_steer
non-blockingly. The only two places it is called are step boundaries:

• core/engine/turn_loop.rs:808 -- top of the tool-step loop, before the next
  provider request. "Steer input accepted".
• core/engine/turn_loop.rs:2074 -- the no-tool-use branch, where the loop
  would otherwise end. "Continuing — queued steer input".

Nothing watches rx_steer during a provider stream. The stream select at
turn_loop.rs:1518 covers only cancellation and the initial
create_message_stream. So while the model is mid-generation, a steer sits in
the channel until the current generation finishes.

That is queueing with a shorter wait, not steering. It is exactly the
distinction the founder suspected.

2. The transcript splits the in-flight message around the steer.

tui/ui/dispatch.rs:1187 -- steer_user_message calls app.flush_active_cell()
and then paints the steer cell, deliberately: the comment says the steer
should appear below the content that chronologically preceded it.
tui/app.rs:5214 finalizes the active cell.

The engine, meanwhile, appends the steer at the boundary -- after the whole
assistant message. So:

live       [ message part 1 ] [ steer ] [ message part 2 ]
persisted  [            message                ] [ steer ]

The steer appears above work that the session record places before it. That is
the reported symptom, and it is why the position looks wrong: live and replayed
transcripts genuinely disagree, rather than one of them being merely odd.

Flushing is not itself the mistake. Painting the steer below in-flight content
without flushing would produce the mirror problem -- the steer above the work,
because the active cell flushes into history after the steer was appended. Both
orderings are wrong while the engine places the steer last.

Why interrupting is the coherent fix

If the steer ends the current generation, then splitting at that point is
correct and both views agree:

[ partial message ] [ steer ] [ new message ]

The founder's instinct -- "maybe it needs to interrupt thinking" -- is the
design, not a workaround. It is also what makes the existing
flush-then-paint sequence right instead of wrong.

What implementing it requires

Add a steer branch to the provider event-consumption loop, following the
tokio::select! { biased; ... } pattern already used at turn_loop.rs:1518
and :3774:

1. Break the stream loop when a steer arrives for the active turn.
2. Finalize the partial assistant content as a message, so the record matches
   what was shown.
3. Append the steer message.
4. Continue to the next step without executing any half-emitted tool call.

The hard parts are not the select. They are: what happens to a tool call that
was mid-emission when the steer lands (it must not execute, and must not be
recorded as completed); whether the partial message is kept or dropped, and how
that interacts with retries; and whether the abort should reuse
cancel_token or be a distinct signal, since a steer is not a cancellation and
the turn must continue afterwards.

This is a change to the hottest path in the engine, so it wants its own slice
with real turn-loop tests rather than a drive-by. It is NOT implemented yet.

[Hmbown]

Investigation (read-only source inspection, v0914-chunk2)

The prior diagnosis is partially right but the mechanism is different in an important way.

What actually happens. The engine queues mid-stream steers and commits them at step boundaries after the in-flight step — correct in the record (turn_loop.rs:808-827 step-boundary drain; :4732-4745 in-stream queueing into pending_steers; committed after the assistant message at :2074-2092 / after process_tool_results at :2682-2691). The TUI meanwhile paints a settled HistoryCell::User and pushes api_messages at steer time (dispatch.rs:1173-1237).

The sharper violations the original diagnosis missed:

• Case D (worst): painted-but-dropped steers. next_turn_steer (engine.rs:1285-1299) is a drain-and-discard filter, not a queue — a steer stamped with a stale/None turn id (the post-TurnControlGuard::drop window before TurnComplete is handled) is popped and dropped silently. Same for pending_steers on interrupt/failure/stream-retry (turn_loop.rs:1675, 1717, 1866). The toast says "Sent into turn", the + steer cell stays in history forever, api_messages grows — and the record never contains it. Replay drops it entirely. Live transcript permanently shows a steer the model never saw. (One layer down: spawn_steer_receipts emits item.completed on channel acceptance, so the runtime journal can durably record a completed steer the engine later drops.)
• Case B: active-group split. Thinking/tool entries in active_cell flush above the steer cell; content streaming after it lands below — while the record keeps all of it before the steer inside one assistant message.
• Case C: transient api_messages reorder. Steer pushed at index N; the in-flight assistant lands at N+1 at MessageComplete; next SessionUpdated rewrites it back. record_context_references froze the steer at N.

Fix direction — move presentation, not the engine (the record order is semantically right: the steer scopes the next step):

1. steer_user_message: on steer() Ok, push an inflight-steer rendered through the existing pending-preview bucket (frame.rs:1377 pending_steers) — not a settled cell, not push_api_message.
2. On SessionUpdated (apply_engine_session_projection): a new user message matching the steer's content marks acceptance at that index → flush_active_cell() → append the user cell → record_context_references with the matched index. Live order then equals record order by construction.
3. At TurnComplete: any unmatched inflight steer was dropped → app.rejected_steers (scaffolding already exists, app.rs:2277, currently unused) + toast.
4. + marker is live-only; not reconstructable on replay — document or drop.
5. Keep next_turn_steer a discard filter — the stale-drop is tested behavior (new_turn_does_not_inherit_previous_turn_controls).

Traps: the streaming assistant cell lives in history, not active_cell; list_items_for_turn sorts by started_at not item_ids; echo_queued_user_turn has the same paint-before-acceptance class for queued messages (adjacent gap).

Note: the DSH-wishlist fold (comment on #6192) generalizes this — a durable identified inbox (W17) would make steer acceptance a journaled event instead of a SessionUpdated diff. This fix stands alone; W17 can replace the matching later.

[Hmbown]

claiming: implementing the "move presentation, not the engine" plan from your v0914-chunk2 investigation — steps 1, 2, 3 and 5. The record order stays as it is; the steer stops being painted as a settled cell at send time and becomes one at acceptance.

Files: crates/tui/src/tui/app/types.rs + app.rs + app/init.rs (an inflight_steers bucket), crates/tui/src/tui/ui/dispatch.rs (steer_user_message), crates/tui/src/tui/ui/event_loop.rs (apply_engine_session_projection matches acceptance; TurnComplete settles what was never accepted), crates/tui/src/tui/ui/frame.rs (render through the existing preview bucket), tests in crates/tui/src/tui/ui/tests.rs.

Not touching the engine, next_turn_steer, or echo_queued_user_turn's paint-before-acceptance (your adjacent gap).

[Hmbown]

Fixed by 9efb4ba90 on fix/lost-work-batch-a-20260915 (local branch — not pushed).

Implemented your v0914-chunk2 plan: move the presentation, not the engine. Steps 1, 2, 3 and 5.

What changed. steer_user_message no longer paints a settled cell or pushes api_messages; it records an InflightSteer (crates/tui/src/tui/app/types.rs). apply_engine_session_projection promotes it when the engine's record contains it — flush_active_cell(), paint, record_context_references against the matched index, which is Case C gone as a side effect. TurnComplete moves whatever was never accepted to rejected_steers (Case D). next_turn_steer is untouched, per step 5.

Two things from your plan I did differently, both smaller than proposed:

1. You suggested an inflight-steer rendered through the pending_steers preview bucket. I chained inflight_steers into that bucket in build_pending_input_preview rather than adding a fourth. The existing labels turned out to be exactly right as written — PendingSendingIntoTurnPrefix for the in-flight case and PendingCouldNotSendIntoTurnPrefix for the rejected one — so this needed no new MessageId and no sixteenth string in fifteen locale files. The "scaffolding" comment on rejected_steers ("no engine path produces these yet") is now false; I left it for whoever wants to reword it, since the field's doc comment above it is the one that is accurate.

2. Matching is on the exact text handed to EngineHandle::steer, compared against the accepted user message's first text block — the engine appends a turn_meta block after it in user_text_message_with_turn_metadata_for_route_and_provenance, so a whole-message comparison would never match. The search starts at the api_messages.len() captured when the steer was sent, and claimed indices are tracked within a pass, so two identical steers cannot claim the same message.

Tests. Two new, both in crates/tui/src/tui/ui/tests.rs:

• steer_becomes_the_newest_transcript_entry_only_when_the_engine_records_it — asserts no HistoryCell::User and no api_messages growth at send time, the preview shows it as still sending, and after a SessionUpdated carrying [user, assistant, steer] the steer is history.last(). Fails against the old code at the first assertion, which is the defect itself.
• steer_the_turn_never_accepted_is_reported_not_left_in_the_transcript — Case D: settles to rejected_steers, leaves no cell and no api_messages entry.

live_steer_crosses_message_submit_transform_exactly_once asserted the transformed steer was in api_messages at send time. That assertion was the reorder, so I changed it with the code: it now pins that the transform's output is what the engine was handed and that it is not in the local transcript until the engine records it.

test result: ok. 30 passed; 0 failed; 0 ignored; 0 measured; 12711 filtered out; finished in 1.76s   (-- steer)
test result: ok. 845 passed; 0 failed; 0 ignored; 0 measured; 11897 filtered out; finished in 24.82s (-- tui::ui::)
test result: ok. 475 passed; 0 failed; 0 ignored; 0 measured; 12267 filtered out; finished in 3.93s  (-- tui::app:: tui::widgets::)

cargo fmt --all -- --check clean; CI's clippy line clean on -p codewhale-tui --all-targets --all-features.

What this does not do.

• The engine still does not interrupt. A steer lands at the next step boundary, which is your first diagnosis's "queueing with a shorter wait". This makes the transcript tell the truth about that; it does not change it. The founder note — "maybe it needs to interrupt thinking" — is a separate engine slice and I did not open it.
• Your step 4: the + marker is still live-only and not reconstructable on replay. Documented in the commit rather than fixed.
• echo_queued_user_turn keeps its paint-before-acceptance for queued messages — your adjacent gap, untouched.
• I could not run the full codewhale-tui lib suite: with --all-features it wedged on a runtime-chat scope lock (lsof showed it holding runtime-chat.owner.lock and runtime-process.owner.lock with 29s of CPU over 45 minutes, nothing to do with this change), and scripts/dev-test.sh tui provisions an isolated build dir and starts from proc-macro2. Evidence above is the three targeted runs, which cover every module this touches. CI owns the rest.