在需要判断实现计划、设计或拟议变更能否开始构建时…

当收到计划、设计或拟议变更并需评审其可构建性时，按解析目标、有界取证、穷尽分析、三节报告和可选计划更新的流程执行。

适用场景

解决思路

1. 评审请求只授权分析，不授权编辑文件。
2. 1. 解析评审目标：要求提供计划、设计或拟议变更工件及其治理需求，可通过路径、URL、粘贴文本或附加的 IDE 上下文指向。
3. 若未提供评审目标，报告 `BLOCKED: review target required` 并请求一个指针。
4. 绝不可从对话记忆中重建评审目标。
5. 记录：`target | requirements | evidence read | findings | verdict | edit authority`。
6. 完成条件：评审目标与需求已固定，或已发送阻塞报告。
7. 2. 收集有界证据：阅读评审目标、需求、直接受影响的契约、相关源码和当前测试。
8. 仅当评审目标引用了过去失败，或当前主张需要历史记录时，才阅读历史。
9. 当每个需求和候选风险都有来源指针时，停止收集证据。
10. 不要调查无关架构。
11. 中断后，在使用台账前确认评审目标和需求未变；若任一变化，丢弃台账并从第 1 步重新开始。
12. 完成条件：每条评审主张都能引用需求、目标章节、源码路径、测试或历史工件。
13. 3. 分析（穷尽）：将每条需求映射到提议步骤和验证。
14. 检查边界、失败与回滚路径、顺序、兼容性、安全性、性能和测试覆盖。
15. 按概率乘以影响对每个发现排序。
16. 不要把理论担忧排在已有证据的失败之前。
17. 将评审目标中无支持的安全性、兼容性或性能主张视为发现。
18. 暴露每一个实质性发现。不要停在第一个阻塞项。不要限制列表数量。只省略风格和偏好类小问题。
19. 在对完整列表排序后映射结论：无实质性发现：`Ship it.`
20. 只有独立的可修复阻塞项：`Fix the blockers first, then ship.` 可修复指每个阻塞项最多三步且不改变方案或需求。
21. 方向错误、缺少核心需求或有多个耦合阻塞项：`Needs rework.`
22. 完成条件：每条实质性需求都有发现或明确通过，且结论符合此映射。
23. 4. 报告：准确写出三个章节。
24. `## Findings`：按最差优先排列的每个实质性发现列表，使用 `- <finding> → <impact>` 项目符号并附引用；若无则写 `None found.`。不设数量上限。
25. `## Fix`：按排名顺序覆盖每个可修复阻塞项的有编号步骤；或首个返工决策；或写 `None.`
26. `## Verdict`：准确写出一句映射后的结论，不添加解释。
27. 完成条件：三节契约成立，且每条发现都有引用。
28. 5. 可选计划更新：仅当用户在评审请求中明确要求更新，或阅读评审后确认更新时，才进行编辑。
29. 只应用报告中给出的 Fix；广泛返工需要新的已批准设计。
30. 重新阅读 diff 并报告变更路径。
31. 终态值：`BLOCKED`（缺少目标）、`REVIEWED`（仅分析）、`AWAITING_CONFIRMATION`（需要确认）、`UPDATED`（已验证计划编辑）。

适用边界 · 注意事项

• 没有计划、设计或拟议变更工件及其治理需求时，不要评审；应返回 `BLOCKED` 并索要指针。
• 只做风格、偏好或小问题检查时，不适用；本流程只省略这类 nit。
• 用户未明确要求更新计划或未在阅读后确认时，不要编辑文件。