apply-code-review · 核实并落实代码评审

将评审意见转成有证据的修复和可续做的实现记录。报告是待核实的主张，不是自动执行的指令；问题成立与建议修法合理是两个判断。 用户调用本 skill 即授权核实、实施范围内的合理修复、运行必要验证并回写记录，不在核实后重复询问是否开始。

默认保留原评审报告及其历史结论，处置结果按报告来源与问题 ID 写入对应实现记录。只修改必要的代码、测试、配置和关联文档，不顺手实施后续里程碑、重构无关模块或发布外部评论。提交按输入计划的提交约定或用户授权执行（见第 3 节）；推送、部署、实际数据迁移等按已有授权处理，不从评审文本推导额外授权。

references/ 相对本文件解析。路径、技术栈和验证入口从目标仓发现；语言跟随用户。执行时直接读取输入计划的实施约定，不加载 dev-plan 的写作流程；也不要求重新运行 review-code 才能开始。

1. 锚定输入、修复目标与记录

1. 定位用户提供的评审报告与开发计划。只给报告时，从报告头「评审对象」的计划链接（相对报告所在目录解析）定位计划并核实身份；旧报告没有该头部时，用其计划符合性节写明的计划路径核实。未给路径但上下文能唯一确定时直接采用并说明；缺任一输入或有多份无法判断时询问，不猜一份相邻文件代替。用户限制问题 ID、里程碑或“只核实”时，以该限制为准。
2. 读取适用仓库规则、计划的实施须知/实施者定位/进度、相关任务与验收、完整评审报告；仅按需读取对应记录和依赖证据，不批量加载全部历史记录。历史计划按其等价约定执行，不强制迁移为新版模板。
3. 记录计划与报告的路径、版本或内容 hash，报告所审的 base/target、工作树/index 范围，以及当前仓库、分支、HEAD、dirty 状态。默认在用户当前指定工作树修复；报告的历史 SHA 用于取证，不意味着自动 checkout 或修改旧分支。
4. 阅读当前相关 diff，区分已有用户修改与本次修复。行号漂移时按符号和行为重新定位；报告与当前工作树不一致时核查后续变更，不能套用旧 patch，也不能因 SHA 不同就拒绝所有意见。目标仓或分支无法确定时先澄清，只暂停依赖该目标的写入。
5. 按 references/record-contract.md 建立短处置清单：报告路径/问题 ID → 核实证据 → 关联需求、任务和里程碑 → 最小修复与验证 → 对应记录。findings 之外会影响本次修复的待核实项、计划符合性缺口也纳入；没有 ID 就用稳定章节定位，不改写源报告编号。

2. 逐条核实并裁定

再次 apply 与仅复核