## 功能概述 **目标**: 让审阅引擎能够核验 plan 作者的事实性辩护,而不必把整个仓库交给引擎提供商。 **动机**: 在 v1.5.0 确立的「Critical 必须卡到 20 轮死」契约下,存在一类结构性死锁——引擎提了一个错误的 Critical,作者用一个**正确但引擎无法核实**的事实主张辩护("代码里其实已经有 X")。按 v1.5.0 新增的举证责任对称规则,这条 finding 会保持原严重度不被撤销,于是必然卡到全局阀墓碑 deny。让引擎能核验事实是解开这个死锁的手段。 ## 当前状态 - v1.5.0 的 delta 审阅规则要求「无法核实的事实性辩护不清除 finding」,但没有给引擎任何核实手段 - 引擎只能看到:全局 CLAUDE.md(8KB)、项目 CLAUDE.md(24KB)、最近 3 条用户消息、plan 全文、历轮审阅 thread - 引擎看不到任何真实源码 ## 期望效果 引擎能读到 plan 里明确引用的那些文件的相关片段,从而判断「代码里其实已经有 X」这类辩护是否成立。 ## 设计方案 ### 方案概述 **编排器从 plan 文本中抽取被引用的文件路径,读取片段一并注入 prompt。** 对比 PR #153 提出的 `REVIEW_REPO_ACCESS=1`(codex 的 `-C` 指向项目 cwd)方案,本方案的优势: | 维度 | `REVIEW_REPO_ACCESS` | 本方案 | |------|---------------------|--------| | 隐私暴露面 | 整个仓库可读 | 只有 plan 自己提到的文件 | | 引擎覆盖 | 仅 codex | 全引擎(走 PROMPT_FILE 通道) | | claude 引擎 | 不可用(`--tools ""` 禁了工具) | 可用 | | 新增配置项 | 1 个 env | 0 | | 耗时 | 引擎自主探索,不可控 | 编排器一次性读取,可预算 | ### 实现步骤 1. [ ] 从 plan 文本抽取候选文件路径(反引号包裹的路径、`file:line` 形式、常见扩展名) 2. [ ] 路径安全校验:必须落在 `$CWD` 内、拒绝符号链接越界、拒绝路径遍历(可复用 `lib/plan-source.sh` 的三重安全门思路) 3. [ ] 读取片段并做字节预算(复用 v1.5.0 的 `clamp_head_bytes`),总量封顶 4. [ ] 注入为 `## Referenced Source` 段,位置在 plan 之后、Prior Review Thread 之前 5. [ ] 提示词侧补一句:引用源码可作为核实辩护的依据 6. [ ] README 隐私披露段同步 ### 涉及文件 | 文件 | 变更类型 | 说明 | |------|----------|------| | `plugins/plan-review/scripts/plan-review.sh` | 修改 | 路径抽取 + 注入 | | `plugins/plan-review/scripts/lib/plan-source.sh` | 参考/复用 | 已有的路径安全门 | | `plugins/plan-review/scripts/lib/common.sh` | 复用 | `clamp_head_bytes` | | `plugins/plan-review/README.md` | 修改 | 隐私披露 | | `plugins/plan-review/tests/plan-review.bats` | 修改 | 新增用例 | ## 兼容性考虑 - 向后兼容:无 plan 引用文件时行为与现状完全一致 - 隐私:会把源码片段发给引擎提供商,README 必须明示;需评估是否要给一个关闭开关(与「净新增 env = 0」原则权衡) - 预算:注入内容会挤占引擎上下文,需与 CLAUDE.md 限额一起做总量规划 ## 验证方法 - [ ] plan 中引用的文件片段确实出现在 prompt 中 - [ ] 路径遍历 / 符号链接越界 / 仓库外绝对路径均被拒绝 - [ ] 无引用文件的 plan 其 prompt 与现状字节一致(无回归) - [ ] 总量超预算时按 clamp 规则截断且保持合法 UTF-8 ## 背景 由 PR #153 的审阅意见吸收过程分流而来(见该 PR 的处置对照表)。#153 的原始实现方式被驳回,问题本身有效,故单独记录。
功能概述
目标: 让审阅引擎能够核验 plan 作者的事实性辩护,而不必把整个仓库交给引擎提供商。
动机: 在 v1.5.0 确立的「Critical 必须卡到 20 轮死」契约下,存在一类结构性死锁——引擎提了一个错误的 Critical,作者用一个正确但引擎无法核实的事实主张辩护("代码里其实已经有 X")。按 v1.5.0 新增的举证责任对称规则,这条 finding 会保持原严重度不被撤销,于是必然卡到全局阀墓碑 deny。让引擎能核验事实是解开这个死锁的手段。
当前状态
期望效果
引擎能读到 plan 里明确引用的那些文件的相关片段,从而判断「代码里其实已经有 X」这类辩护是否成立。
设计方案
方案概述
编排器从 plan 文本中抽取被引用的文件路径,读取片段一并注入 prompt。
对比 PR #153 提出的
REVIEW_REPO_ACCESS=1(codex 的-C指向项目 cwd)方案,本方案的优势:REVIEW_REPO_ACCESS--tools ""禁了工具)实现步骤
file:line形式、常见扩展名)$CWD内、拒绝符号链接越界、拒绝路径遍历(可复用lib/plan-source.sh的三重安全门思路)clamp_head_bytes),总量封顶## Referenced Source段,位置在 plan 之后、Prior Review Thread 之前涉及文件
plugins/plan-review/scripts/plan-review.shplugins/plan-review/scripts/lib/plan-source.shplugins/plan-review/scripts/lib/common.shclamp_head_bytesplugins/plan-review/README.mdplugins/plan-review/tests/plan-review.bats兼容性考虑
验证方法
背景
由 PR #153 的审阅意见吸收过程分流而来(见该 PR 的处置对照表)。#153 的原始实现方式被驳回,问题本身有效,故单独记录。