# Phase 4：需求反向验收规程

**问题意识**：Phase 4 检查的不是"文档漂不漂亮"，而是**需求是否明确到足以形成规格**。核心一问：

> "一个完全没有参与讨论的资深工程师现在接手开发，哪些重要产品行为仍然需要他自己猜测？哪些必须回头找需求负责人确认？"

## 执行方式（按优先级）

1. **子代理独立审查（首选）**：用 Agent 工具派 fresh-context 子代理（general-purpose 或 Explore）。提示词要点：
   - 角色：资深开发工程师，第一次见到这个项目；
   - 输入：只给 state.md 路径（+ 已有 openspec specs 路径，如有）——**不给会话历史、不给 Le SPEC 的阶段叙事**，确保视角独立；
   - 任务：逐条检查下列清单，输出"我会被迫猜测/必须确认"的清单，每条注明影响哪个功能点与后果严重度；
   - 产出格式：问题列表（问题/影响/严重度建议/建议澄清方式）。
2. **无子代理能力时的降级**：自审前显式重置角色（"放下前文立场，作为首次接手的工程师仅凭 state.md 判断"），只允许引用 state.md 与项目文件内容。**必须在产出中声明"本轮为同上下文自审，独立性弱于子代理审查"**——不装作独立。

## 检查清单

- [ ] 用户流程有断点（走不到下一步/回不去）
- [ ] 功能之间缺关联规则（A 发生时 B 如何）
- [ ] 数据关系歧义（谁拥有谁、一对多还是多对多、删除级联）
- [ ] 状态机不完整（缺状态、缺转换、缺终态）
- [ ] 权限与业务边界不明（谁能做什么、越界怎样）
- [ ] 异常场景缺处理原则（失败/超时/并发/空数据）
- [ ] 需求间冲突（同一对象两种定义）
- [ ] 未经确认的重要默认假设（state.md 里的 [默认] 项逐条复核用户知情度）
- [ ] 验收判据缺失（做完了怎么算"对"）

## 分级与处置

| 级别 | 判定 | 处置 |
|---|---|---|
| blocking | 不澄清就无法实现核心行为 / 两种理解导致完全不同的产品 | 终止回合向用户澄清（用 grilling 单轮格式，记账本） |
| major | 影响正确性但可从已确认决策推导 | 推导入 state.md 并标注依据；推导不了升 blocking |
| minor | 边缘场景、可延后 | 记开放问题，进 SPEC 的"非阻塞事项" |

更新后**只复核受影响项**，不重跑全清单。清零 blocking → 进 Phase 5。