easy-codex-review

name	easy-codex-review
description	当用户要求审查计划、本地改动、执行计划后的代码最终审查、拉取请求风格审查、回归风险检查或验证缺口分析时使用。

Easy Codex 审查

审查计划或已实现改动。代码最终审查写审查产物，不改代码。

用户选择

• “选择功能”指：可点击选择可用时必须用控件；工具不可用时用文本降级，给每个选项编号，列 2-3 个互斥选项，推荐项第一，要求用户回复编号数字、完整选项名或 其他: <自定义>；开放答案用“其他”，并允许用户直接输入自定义内容；禁止要求用户输入关键词或技能名。

强制门禁

• Easy Codex 流程内审查必须在规格/计划字段 绝对 worktree 路径 内进行；字段缺失、相对路径、未通过 <主项目根>/<显示路径> realpath 校验、或指向 main worktree 时阻塞。
• 基准 缺失、git rev-parse --verify <基准>^{commit} 失败、或不是 HEAD 祖先时阻塞，回 $easy-codex-writing-plans 补齐。
• 独立只读 review 可在当前 worktree 进行，但禁止任何写入。
• 审查阶段禁止改源文件、测试、配置或规格。
• 计划审查只能更新被审计划的 流程状态 和 对抗性审核 / 用户处理决定 字段；不改阶段内容、范围、文件结构、验证命令或实现步骤。
• 代码最终审查必须写 docs/reviews/YYYY-MM-DD-<slug>.md，记录基准、HEAD、结论、接受风险和用户选择。
• 修复问题必须先经选择功能批准，再回 $easy-codex-writing-plans、$easy-codex-executing-plans 或对应流程。

工作流

1. Easy Codex 流程内读取字段 绝对 worktree 路径、主项目根、显示路径 和 基准；先用 realpath 与 git worktree list --porcelain 验证后切入；独立只读 review 用当前目录。
2. 代码最终审查读取提交范围：git log <基准>..HEAD、git diff --stat <基准>..HEAD、git diff <基准>..HEAD；git diff HEAD、git diff --cached、git ls-files --others --exclude-standard 只用于检查未提交/未跟踪遗漏。
3. 若有相关 docs/specs/ 或 docs/plans/，先读作审查基准。
4. 若用户要求审查计划，执行“计划审查”；只有提交范围、未提交 diff、暂存 diff、未跟踪文件都为空，才视为没有实现 diff。
5. 否则阅读提交范围 diff、附近代码、测试和运行时契约，执行“代码审查”。
6. 只报告可执行问题； findings 优先，摘要靠后。
7. 若有问题，按审查模式用选择功能请求下一步。
8. 若无问题，按审查模式写审查产物并用选择功能请求下一步。

计划审查

• 对照已批准规格，检查计划是否覆盖目标、验收标准和非目标。
• 检查阶段顺序、依赖、文件路径、命令、预期失败测试、验证和回滚是否可执行。
• 计划审查优先判断计划能否执行并让规格落地；不要把计划审成完整实现设计。
• 标出范围漂移、缺失测试、含糊步骤、跨阶段冲突和高风险迁移点；只有会阻止执行、无法验收、违反门禁，或存在具体不可逆风险且无处理边界的问题才要求回到计划。
• 轻微范围漂移、可自然补齐的技术细节、测试补强建议、后续代码审查可兜底的问题，只记录为非阻塞建议。
• 未发现明确阻塞问题时，计划审查必须通过；非阻塞建议不得阻止进入实现。
• 有明确阻塞问题时提供：回到实现计划、接受风险、停止。计划审查的“接受风险”必须先写入计划的 对抗性审核 / 用户处理决定，并把 计划批准记录、审核状态、下一阶段许可 更新为允许执行；只允许进入 $easy-codex-executing-plans，不允许进入 $easy-codex-ship。
• 无明确阻塞时先把通过结论写入计划的 对抗性审核，并把 计划批准记录、审核状态、下一阶段许可 更新为允许执行，再提供：开始实现、停止。

代码审查

• 对照规格和计划检查 <基准>..HEAD 范围内的阶段提交和最终 diff。
• 检查整体集成：跨阶段冲突、契约不一致、计划外改动、回归风险、验证缺口。
• 写 docs/reviews/YYYY-MM-DD-<slug>.md，包含 基准、HEAD、结论、接受风险、用户选择、验证缺口。
• 代码最终审查无论通过、有 findings、还是用户接受风险，都必须先写入或更新匹配当前 基准 和当前 HEAD 的 docs/reviews/YYYY-MM-DD-<slug>.md，再允许进入 $easy-codex-ship。
• 有问题时提供：回到执行计划、接受风险、停止。代码审查的“接受风险”允许进入 $easy-codex-ship。
• 无问题时提供：准备交付、停止。

检查内容

• 是否满足规格和计划，是否多做或少做。
• 多阶段合并后是否破坏接口、数据契约、状态流或错误处理。
• 是否有回归、竞态、鉴权/安全、数据丢失、迁移或兼容风险。
• 测试是否覆盖用户行为和关键边界。
• 验证是否足以证明完成；失败或未跑项是否有解释。
• diff 是否包含无关改动、调试残留或计划外重构。

问题格式

每条问题必须包含：

• 严重级别：Critical / Important / Minor
• 文件和行号
• 具体坏结果
• 当前差异为什么会导致它
• 最小修复方向

输出

顺序：

1. 按严重级别排序的问题
2. 开放问题或假设
3. 验证缺口
4. 简短改动摘要
5. 下一步选择

没有发现问题时，直接说明，并列剩余风险和未验证项。