PR 审查中依据 spec_context.md…

在 PR 审查期间已有 spec_context.md 时，用规范上下文比对实现，找出实质性偏差并写入 review.json。

适用场景

解决思路

1. 将本检查作为正常代码审查的补充，而不是独立输出。
2. 读取 `spec_context.md`，提取其中做出的具体承诺。
3. 提取产品规范要求的必需行为。
4. 提取技术规范要求的必需变更文件或子系统。
5. 提取规范中声明的约束。
6. 提取规范中要求的后续步骤、验证或迁移。
7. 读取 `pr_description.md`（如有），获取额外范围或理由。
8. 将上述承诺与 `pr_diff.txt` 及已检出的工作树文件中的实际实现进行比对。
9. 当小型实现层调整保持规范意图时，将其视为可接受。
10. 不要标记命名、结构或低层技术上的无害差异。
11. 只在偏差具有实质性时标记。
12. 产品规范要求的必需行为缺失时标记。
13. 实现与规范决策矛盾时标记。
14. 变更引入显著未计划范围时标记。
15. 技术规范要求的验证、迁移或兼容性步骤缺失时标记。
16. 不要创建单独报告文件。
17. 将规范一致性发现合入 `review.json`。
18. 将宽泛的规范漂移担忧放入 review summary。
19. 仅当偏差能关联到 diff 中变更行时，才添加行内评论。
20. 将实质性规范漂移至少视为重要关注点。
21. 如果实现与规范足够接近，不要仅为说明一致性而添加评论。
22. 当 PR 以安全方式达成相同结果时，不要求逐字一对一实现规范。
23. 不要推测 `spec_context.md` 中实际不存在的规范细节。
24. 不要直接发布到 GitHub。

适用边界 · 注意事项

• `spec_context.md` 不存在时。
• 不是 PR 审查场景，或没有已批准/仓库规范上下文、没有可用的 `pr_diff.txt`/已检出 PR 分支等实现材料时。
• 需要直接向 GitHub 发布评论时。