Auto Review completion notice can obscure the assistant's last real message

[cbusillo]

Observation

Auto Review can finish after the assistant has already sent a normal conversational response. When that happens, the TUI presents the Auto Review result after the assistant message.

In live use this is confusing because the Auto Review notice reads like another participant speaking after the assistant has closed out. It can be difficult to tell whether the assistant response is complete, whether the Auto Review result supersedes it, or where the last real assistant message ended.

User confusion

• The post-message Auto Review notice can make it hard to find the assistant's latest real response.
• The notice appears to compete with the assistant message instead of feeling like background status.
• When it arrives asynchronously, it can make the transcript feel out of order even if the underlying background review result is accurate.
• The user specifically described the experience as very confusing and sometimes difficult to locate the last real message.

Notes

This issue intentionally documents the observed UX confusion only. The right presentation model is still undecided.

[cbusillo]

Additional dogfood observations from 2026-06-01 while waiting to restart the Every Code harness:

• User wanted to restart the harness to verify a resume/final-message fix, but paused because an Auto Review was visibly running and restarting would kill or orphan it.
• It was not obvious from the UI whether the running review was legitimate, stale, or safe to ignore. I had to verify from the process table that it was a real /review launched by the current code resume parent and scoped to the just-merged PR Show final assistant replay after stale snapshot #318 diff.
• The review had an output path like /var/folders/.../1bec3462-4543-4601-9c6b-cb3b06303ad0.review-output.json, but that file was still missing after repeated checks.
• The same small PR Show final assistant replay after stale snapshot #318 review was still alive after roughly 15-17 minutes. That is long enough that the user reasonably described this as a constant problem and did not know whether to keep waiting or restart.
• A second Auto Review for the GPT-5.4 docs/config guidance diff appeared while the first was still pending, increasing confusion about which review was active and whether any result had landed.

UX confusion this adds beyond the original notice-placement issue:

• Auto Review needs clearer lifecycle/status presentation: queued/running/completed/stale/failed, target snapshot/PR/changed files, elapsed time, and whether a restart will cancel it.
• Long-running reviews should have an obvious timeout/stale state or recovery path.
• If multiple reviews are running or pending, the UI should disambiguate them so the user can find the last real assistant message and understand which background result, if any, is about to appear.

No proposed fix here; just preserving the observed confusion and the debugging evidence.