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