[FEATURE] Stop-hook continuations render below the final answer — no way to keep the answer visually last

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

A Stop hook that returns decision: "block" (to run an end-of-task side effect — capturing notes, logging, generating a summary, continuing an iteration loop, etc.) forces a new agent turn that renders below the agent's final answer.

On small terminals this pushes the answer out of the viewport, so the last thing the user sees is the hook's side-effect work rather than the answer they asked for. The answer is what should remain visually last; the hook's bookkeeping should be secondary.

There is currently no userland workaround, because every hook that could reposition or suppress that work is disqualified (see Alternative Solutions). So the missing capability is a way for a hook to run end-of-task logic without that logic becoming the last thing on screen.

This affects first-party plugins too — e.g. the ralph-wiggum plugin in this repo uses a Stop hook to continue iteration, and any such continuation inherently renders after the final message. It's not a niche third-party need.

Proposed Solution

A "background / collapsed" render flag for Stop-triggered continuations.

Let a Stop hook mark its forced continuation as a side effect (e.g. a field in the hook's JSON output) so the TUI collapses or backgrounds that turn, leaving the agent's answer as the last visible block. The work still runs and still lands in the transcript — it just isn't the thing occupying the viewport.

This is the minimal ask: a UI/render affordance, no new execution point, and it fully satisfies "the answer stays visually last."

Alternative Solutions

Alternative primitive — a pre-finalization hook. An event that fires when the agent is about to emit its final message, whose additionalContext is handled before that message is generated, so a hook can complete side-effect work ahead of the answer within the same turn. More general (also enables "do X, then answer" patterns) but a larger ask than the render flag.

Existing events already considered and ruled out:

| Event | Why it can't solve this |
|---|---|
| Stop / SubagentStop | Fire after the final answer — the injected continuation always renders below it. |
| PostToolUse / PostToolBatch | Can inject into the current turn, but fire after every tool call with no signal for "this was the last tool before the agent summarizes," so there's no safe injection point. |
| TaskCompleted | Payload-less (continue / exit-code only, no additionalContext) and scoped to divided-task/todo completion, so it doesn't fire on ordinary turns. |
| MessageDisplay | Display-only — rewrites displayContent transiently, can't be positioned last and can't steer the model. |

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

1. A user has a Stop hook that captures durable notes after a task touches real code (a common pattern for memory/knowledge tooling).
2. On a 13" laptop, the agent finishes, prints its answer/summary, then the hook forces a capture turn.
3. The capture turn (tool calls + confirmation text) renders below the answer and scrolls the answer out of view — so the user's last visible content is note-writing bookkeeping, not the answer.
4. With a background/collapsed render flag, the capture turn would run and be recorded but stay out of the viewport, leaving the answer as the final visible block.

Additional Context

• Any hook doing meaningful end-of-turn work (notebook/memory capture, structured logging, post-run summaries, iteration loops) currently trades off against readability: the more useful the hook, the more it buries the answer.
• First-party precedent: plugins/ralph-wiggum uses the same Stop-continuation pattern and would exhibit the same behavior.
• Scope note: this is deliberately a single capability ("let a Stop continuation stay out of the answer's viewport"); the two options above are alternative implementations of it, not separate requests.