plan-deep-review

深度计划审查

评估计划的范围、战略选择和执行风险。加载详细审查材料前，先确定模式。

范围与节奏

阅读提供的计划和相关现有实现。对于仅审查计划的请求，不要求提供分支。对于混合请求，也要固定所请求的差异。保留已确定的约束、受保护路径和先前决策。

遵循用户指定的交互模式。否则，将独立发现合并处理，只针对确实尚未解决且会影响范围或设计的选择提问。每个问题提示最多合并四个独立问题，而不是逐个提问；将 TODO 或延期裁定纳入最终检查点，这样批处理也不会漏掉任何问题。若问题需要交由委员会裁定，除非用户要求使用子 Agent，否则在线以快速模式运行；同时运行相互独立的委员会裁定，仅暂缓依赖先前裁定的事项。用户要求改进时，直接应用明显的计划修正；仅报告意味着不做修改。用户要求“跳过提问”时，立即照办，说明假设并继续有用的工作。假设不代表获准扩大范围。不要重复询问已作出的决定。

审查计划，而非实现：不要修改源代码、提交、推送或创建远程任务。满足相关验收标准后即停止，否则报告剩余阻碍。评分只是可选的摘要，不应成为反复润色至 10/10 的目标。

模式

模式	范围约定
SCOPE EXPANSION	提出更广泛的机会；新增内容需经批准。
SELECTIVE EXPANSION	保留基线方案，并提出少数值得考虑的补充。
HOLD SCOPE	提高严谨性，不增加或删减功能。
SCOPE REDUCTION	提出更精简的完整方案；保留必需项。

遵循用户提供的模式。否则，默认采用 HOLD SCOPE；只有在无法推断请求预期范围时才提问。只阅读 strategy.md 中相关的部分。

审查路由

• 架构、数据、安全、故障、测试、性能或部署：参考 engineering checks 中的相关部分。
• UI 范围：参考 design checks 中的相关部分，并以现有产品为依据。
• 面向开发者的契约：参考 DX checks 中的相关部分。

完整模式会审查所有适用领域；快速／批处理模式优先审查计划所改变的决策和故障路径。记录重要的覆盖范围限制。提出替代方案前，先检查当前代码、计划和证据；对于范围狭窄的改动，无需强制进行广泛的系统审计或竞品搜索。

交付内容

记录已接受的范围、可复用的现有组件、重要替代方案、故障／验证要求和未决事项。使用一张故障表；仅在能阐明复杂关系时使用图示。范围扩展／缩减的决策必须说明已接受与提议的工作。获得授权后更新所请求的计划；除非纳入范围，否则待办事项变更应单独处理。

最后以 READY、NEEDS DECISIONS 或 INCOMPLETE 结尾，并说明具体的剩余要求。不要将计划就绪与已实现或已测试的行为混为一谈。