Group serialized edit and write continuations

[alejandro-ao]

Summary

• group consecutive completed edit or write calls emitted by same-tool model continuations
• rebuild the same grouping when older sessions are restored
• derive eligibility from canonical assistant blocks, preserving assistant text, thinking, different-tool, and custom-renderer boundaries in live and restored views
• retain every edit/write invocation and result under Ctrl+O
• keep grouping entirely in TUI state; canonical messages and JSONL persistence remain unchanged

Motivation

Some providers serialize tool use as one assistant file-mutation call, one tool result, then another assistant call of the same type. Although these edits or writes are visually consecutive, response-local batching leaves each in a separate transcript row. This follow-up makes that common sequence one Edited N files or Written N files group.

User experience

A restored sequence such as:

assistant(edit a) → result → assistant(edit b) → result

now renders as:

→ Edited 2 files
  - a
  - b

The same applies to writes. Assistant text, thinking, or a different tool still starts a new transcript boundary.

Validation

• uv run pytest (1520 passed, 2 Windows-only skipped)
• uv run ruff check .
• uv run ruff format --check .
• uv run mypy
• uv build
• hugo --minify
• npx --yes pagefind@latest --site public

Manual validation

1. Open a session containing consecutive same-tool edit or write continuations.
2. Confirm they restore as one file group with all paths listed.
3. Press Ctrl+O and confirm every invocation and result remains visible.
4. Confirm assistant text, thinking, or a different tool keeps subsequent calls separate.

[alejandro-ao]

There is a live/restored inconsistency when assistant text follows a file mutation in the same response.

For this canonical sequence:

assistant: write(a), then text
result(a)
assistant: write(b)
result(b)

restoring the session keeps the writes separate, as expected. During live event handling, however, MessageEndEvent projects the text before ToolExecutionStartEvent appends the first tool row. The visible state therefore becomes text → write(a), and _can_append_file_mutation_continuation() later sees write(a) as items[-1] and incorrectly groups write(b) with it.

The live transcript consequently renders the assistant text followed by Written 2 files, even though assistant text should be a grouping boundary. The same session changes appearance after restart.

Could continuation eligibility be derived from canonical assistant block ordering rather than display adjacency? In particular, cross-response grouping should only be allowed for mutation-only continuations. Please add live adapter coverage for text/thinking both before and after the first tool call, and verify live/restored parity.

[alejandro-ao]

Addressed in 092b2800.

Continuation eligibility now comes from the canonical assistant block sequence and is carried to live tool-start events. Both the previous and current responses must be same-tool mutation-only responses, so transient display adjacency cannot bridge text or thinking.

Added parameterized live/restored coverage for text and thinking before and after the first write call. All cases keep the writes separate, while mutation-only continuations still group.