SIGN IN SIGN UP

feat(relay): ship a diff with every file edit

A tool call arrived as one flat sentence -- `Edit(/repo/x.py) → 1 edit applied` -- and that was
all any client could ever show, because nothing else survived parsing. Yet both sides of the
change were sitting in the transcript the whole time: an Edit's input carries old_string and
new_string verbatim.

Build the diff here, with difflib, rather than shipping both sides and making five clients
reimplement it. Alongside it the call gets structured fields -- the tool's name, the one argument
worth showing, and on a failure the reason -- so a client renders the call instead of re-parsing
the sentence. `text` is untouched: the macOS, iOS, Windows and TUI clients render that string.

No `@@` header and no line numbers. old_string is a fragment of the file, so every number difflib
produces counts from the fragment and would not match the editor the reader is about to open; a
jump between hunks becomes a bare `...` instead. The two header lines difflib always emits are
skipped by position, not by prefix, because a removed line whose own text starts with `--` renders
as `---...` and a prefix test would silently eat it.

Ceilings come off the corpus: across the 1,840 Edit calls in the 25 largest transcripts on this
machine the diff runs 10 lines / 494 chars at the median, 40 lines / 1.9KB at p90, and 321 lines
/ 14KB at the top, so 40 lines shows nine edits in ten whole. A Write is the other shape -- one
side only, median 90 lines and up to 1,529 -- so it is always the head of the file, and the counts
stay the counts of the whole change so a client can say "+200, showing 40". A diff spends from the
same page budget as the prose, and the budget now knows that; `include_tools: false` still costs
nothing.
N
Nick007 committed
40ce988a6f018cad9caf9a16e09ceb02ddec4c56
Parent: ed9a4fe