关于 Commit/Range Review 输入一致性与 Resume 重复 Diff 计算的两个疑惑问题，衷心希望能解答我的困惑

[Redeemz473]

您好，我最近在阅读 OpenCodeReview 的 Review / Session / Resume 相关源码，有两个设计问题想向您询问一下，不确定我的理解是否正确，很希望您能够帮我解答

1. 普通 Commit / Range Review 模式并没有没有像 Resume 一样固定 Git 输入，这样做是否会出现一致性问题呢？

我看到当前 SealedInput 只在 Resume 路径中使用。Resume 会在正式 Review 前把 HEAD、main、feature 等可移动 Git Ref 解析成固定 Commit SHA，后面的 Diff、NewFileContent 和 file_read 都基于固定 SHA。但是普通非 Resume Review 中，Commit / Range Provider 好像还是保存并使用用户传入的原始 Ref。这样是否会导致出现下面这种情况：
例如：ocr review --from main --to feature
假设最开始：main → A feature → B
首先生成 Review Diff：git merge-base main feature→ 得到 Base，例如 A
git diff A feature→ 此时 feature = B，此时 d.Diff = A → B 的代码变化
解析 Diff 后，还调用了ParseDiffText()，从而会为了构造每个 model.Diff 的：NewFileContent
再次执行类似：git show feature:，这里仍然使用的是字符串 feature，而不是生成 Diff 时对应的固定 Commit B。
如果此时用户又提交了一次：feature:B → C
那么第二次读取就会变成：git show feature:a.go
同一个 model.Diff 中可能出现：d.Diff→ 来自 A → B d.NewFileContent→ 来自 Commit C 这样的一致性问题
并且在这个过程中，如果模型调用：file_read("a.go")，普通Review 的 fileReadRef() 在没有 SealedInput 时似乎仍然返回原始 Ref：feature，如果Agent运行期间调用file_read，feature仍然指向C，甚至可能已经进一步移动，file_read可能是 C或更后版本的文件
这样是否会导致出现下面的不一致情况：
Main Prompt告诉模型：“正在Review A → B”
NewFileContent的内容来自C，file_read("a.go")也可能来自C
也就是导致模型可能在审查 B 引入的代码变化，却拿 C 版本的完整代码作为上下文进行推理。
LLM 根据旧 Diff + 新文件上下文进行跨文件推理时，结论可能不一致。

另外，当前 loadDiffs() 中似乎是先 GetDiff()，随后再 ResolveInput()
如果 Ref 恰好在这两个阶段之间移动，还可能产生另一种不一致：真正产生Review Diff时：feature = B，实际Diff = A → B
后面ResolveInput时：feature = C 这就导致Manifest里面ResolvedHead = C
于是可能出现：真正Review的代码：A → B Manifest记录：A → C
但是如果用户直接传完整 Commit SHA，就不存在这个问题了

我看到了 fileReadRef() 附近的源码注释本身也提到了类似风险：如果 reader 继续使用 moving ref，可能出现模型“review one version of the diff, but read another version of the file”的情况；不过目前这层保护似乎主要在 Resume 的 SealedInput 路径生效。
所以想确认：普通 Commit / Range Review 不在运行开始阶段统一把用户 Ref 固定成 SHA，是有意保留 Ref 动态性的设计吗？还是后续也考虑把 Resume 中的 input sealing 泛化到普通 Commit / Range Review，使 Diff、NewFileContent、file_read 和 Manifest 始终基于同一组 Commit SHA？

2. Resume 的 loadDiffs() 和 selectFiles() 执行了两次，如果有大量文件的情况下是否可能会导致过大的消耗

我看到 Resume 预检阶段的 ResolveIdentity() 为了计算 RunIdentity，已经执行：loadDiffs()和selectFiles()

我理解当前这样设计的主要原因是：Resume 校验必须发生在 agent.New() 前，因为 agent.New() 会立即调用 session.New()；而项目又要求 rejected resume 不留下新的 Session。我在想从实现上看，是否可以考虑把预检得到的 Diff / Selection 作为一种 PreparedReviewInput 传给正式 Agent，在一次loadDiffs()和selectFiles()之后计算并校验 RunIdentity，不通过则直接退出，不创建 Session，通过则调用agent.New()，从而能够复用之前已经准备好的 Diff / Selection，不用再进行两次的Diff 和 Selection
这样似乎仍然可以保证：Rejected Resume 不创建 Session，同时避免 Resume 对同一组固定 Commit 重复执行 Diff 解析、完整文件读取和文件筛选。

所以想请教：这里重复执行 loadDiffs + selectFiles 是有意用额外计算换取 preflight 与正式 Agent 解耦吗？后续是否有考虑让两阶段共享已经准备好的 Review Input？

[kova1max]

我不是维护者，但对照当前 main（182898c）的源码核对过，两个判断都成立。

1. 普通 Commit / Range Review 没有固定输入

• agent.Args.SealedInput 的注释明确写着："Nil means resolve normally, which is every non-resume run"。普通运行中 newDiffProvider() 直接使用用户传入的 --from/--to/--commit 字符串。
• GetDiffSet() 先执行 git diff <merge-base> <to>，之后 ParseDiffText() 对每个文件执行 git show <to>:<path> 填充 NewFileContent，用的仍是字符串 ref。to 在两步之间移动，就会得到 Diff = A→B、NewFileContent = C。
• merge-base 缓存在 Provider.mergeBase 中，所以 base 一致，漂移的只有 head。
• loadDiffs() 在 GetDiff() 之后调用 ResolveInput()，会重新 rev-parse to，所以 Manifest 的 ResolvedHead 也可能与实际审查的 commit 不同。
• 窗口最大的是 file_read：fileReadRef() 在 sealed == nil 时返回原始 ref，而模型在整个 LLM 阶段都可能调用它。--commit HEAD 同样受影响。

从代码看，sealing 是为 Resume 准入引入的，还没有推广到普通路径，不像是刻意保留 ref 的动态性。resolveInputBeforeDiff() 已是独立函数：普通 Commit / Range 运行在开始时调用它并设置 SealedInput，newDiffProvider() 和 fileReadRef() 中已有的替换逻辑就会生效。Workspace 模式没有固定 head，不受影响。

修复前可以直接传 SHA 规避（merge-base 结果不变）：

ocr review --from "$(git rev-parse main)" --to "$(git rev-parse feature)"
ocr review --commit "$(git rev-parse HEAD)"

2. Resume 时 loadDiffs() + selectFiles() 执行两次

ResolveIdentity() 在 agent.New() 之前执行一次，Run() 再执行一次。第二次带着 SealedInput，结果必然与第一次相同，所以是纯重复计算。

成本：selectFiles() 是纯函数，不访问 git 或 LLM（仅在配置了 max_tokens 时做 token 计数）。重复的主要是一次 git diff 加每个变更文件一次 git show，即 O(文件数) 个子进程。相比 LLM 调用通常很小，但在大变更集上会翻倍。

PreparedReviewInput 方案可行，但需注意 ResolveIdentity() 会把 a.diffs 覆盖为筛选后的结果，而 Run() 还需要：

• 筛选之前的全部 diff（injectDiffMap() 用它让模型查看被过滤文件的 diff）；
• inputResolution、repoRemoteIdentity 和增删行统计。

另外，Run() 中 loadDiffs 失败时会写入失败的 manifest；复用后这类失败会提前到 session 创建之前，行为有变化，需要确认是否符合预期。

两点都适合开 issue 或直接提 PR，附上你的复现步骤。