36 lines
2.2 KiB
Markdown
36 lines
2.2 KiB
Markdown
# Phase 6：SPEC 独立质量审查规程
|
||
|
||
**问题意识**：Phase 4 检查"需求是否明确到足以形成规格"；Phase 6 检查**"规格是否准确到足以指导开发和测试"**。审查对象是 OpenSpec artifacts（proposal/specs/design/tasks），不是重新审需求——需求问题应已在 Phase 4 清零。
|
||
|
||
## 审查组成（三路并行）
|
||
|
||
1. **四视角子代理审查**（首选 fresh-context 子代理；降级规则同 acceptance.md，须声明独立性等级）。输入：change 目录全部 artifact 路径 + state.md 路径 + （已有项目时）相关既有 specs 路径。四视角各答各的：
|
||
|
||
| 视角 | 追问 |
|
||
|---|---|
|
||
| 产品 | 完整表达真实需求了吗？有无遗漏功能？有无混入用户未确认的新要求（对照 state.md 逐条溯源）？ |
|
||
| 架构 | 与现有系统/既有 specs 冲突？重大技术风险？不必要的复杂度（对照 design.md 的 Decisions 与 think 结论）？ |
|
||
| 开发 | 还要猜什么？缺数据/流程/状态定义？互相矛盾的要求（specs 内部 + specs↔design↔tasks）？ |
|
||
| 测试 | 每条 Requirement 的 Scenario 可执行可判定的吗？正常/异常/边界覆盖？有没有判不了 pass/fail 的模糊表述？ |
|
||
|
||
2. **CLI 校验**：`openspec validate "<change>"`（严格模式可用则用）+ `openspec status --change "<name>"` 确认 artifact 齐全。
|
||
3. **账本核对**：`ledger.py check` 确认 grilling/think/openspec 均有真实调用记录；缺失 → 回补（真实调用）或如实声明。
|
||
|
||
## 产出格式（每问题一行，不许无依据打分）
|
||
|
||
```markdown
|
||
| # | 视角 | 严重度 | 问题（引 artifact 行文） | 影响 | 修正建议 | 阻塞? |
|
||
```
|
||
|
||
严重度：blocker（规格错误/矛盾/无法实现或测试）｜major（会导致误解或返工）｜minor（措辞与边缘）。
|
||
|
||
## 修正循环
|
||
|
||
blocker/major 逐条修正 artifact → 只复验受影响项（重跑 validate + 相关视角复查）→ 清零或全部降为 minor 后出结论：
|
||
|
||
```markdown
|
||
审查结论：blocker 0 / major 0 / minor N（列表，随 SPEC 一并呈交）
|
||
```
|
||
|
||
修正时保持铁律 2：修正只动规格文本与事实呈现，不重启需求讨论；发现规格确实承载不了的需求歧义 → 回 Phase 4 流程处理。
|