ttttstc 规格与设计合规审查
每个功能质量门禁通过后运行。无例外。验证实现匹配审批通过的规格、设计、计划和 UCD。
启动宣告： "正在使用 vibeflow-spec-review 审查此功能。"
运行时机
- 每个功能通过质量门禁后
- 在持久化阶段（git commit）前
- 无例外 — 即使"简单"功能也需审查
阶段 1：规格与设计合规
核心问题：
- 实现是否做了功能规格所说的事？（SRS 可追溯性）
- 实现是否遵循设计文档？（架构、类结构、交互流、依赖版本）
- 实现是否遵循计划文档？（任务分解、约定方案）
- 对
"ui": true功能：实现是否遵循 UCD 风格指南？（风格 Token、组件视觉规格、页面布局）
规格合规检查清单（S1-S5）
| # | 检查 |
|---|---|
| S1 | 所有 verification_steps 被测试覆盖 |
| S2 | 测试验证行为，不是实现细节 |
| S3 | 无未记录的副作用 |
| S4 | 规格中的边界情况已处理 |
| S5 | 功能 description 与实际行为匹配 |
设计合规检查清单（D1-D5）
| # | 检查 |
|---|---|
| D1 | 类/模块结构匹配设计文档的类图 |
| D2 | 交互流匹配设计文档的序列图 |
| D3 | 第三方依赖版本匹配设计文档的依赖表 |
| D4 | 架构层/边界按逻辑视图定义被尊重 |
| D5 | 无未授权的设计偏离（或偏离已记录并获用户批准） |
计划合规检查清单（P1-P3）
| # | 检查 |
|---|---|
| P1 | 实现任务匹配计划的任务分解 |
| P2 | 创建/修改的文件匹配计划的文件列表 |
| P3 | 计划中的设计对齐章节被遵守 |
UCD 合规检查清单（U1-U4）— 仅 "ui": true 功能且有 UCD 文档
| # | 检查 |
|---|---|
| U1 | CSS/样式中的颜色值匹配 UCD 颜色调色板 Token |
| U2 | 排版（字体族、大小、字重、行高）匹配 UCD 排版比例 |
| U3 | 间距和布局（内/外边距、圆角、阴影）遵循 UCD 间距 Token |
| U4 | 组件结构和视觉层次匹配 UCD 组件提示词 |
测试用例完整性检查清单（T1-T3）
| # | 检查 |
|---|---|
| T1 | 每个 verification_step 在 docs/test-cases/feature-{id}-{slug}.md 中有对应 ST 测试用例 |
| T2 | 每个 ST 测试用例有至少一个自动化测试实现它 |
| T3 | UI 测试用例（如有）包含 EXPECT/REJECT 子句、控制台错误门禁和无障碍检查点 |
S1-S5 或 D1-D5 中任何 NO -> 失败。 修复缺口，重新运行测试，重新审查。 U1-U4 中任何 NO -> 失败（ui:true 功能）。视觉不一致必须在继续前修复。 T1-T3 中任何 NO -> 失败。 测试用例覆盖缺口必须填补。 P1-P3 中 NO -> 重要（必须在功能完成前修复）。
问题严重度
| 严重度 | 响应 | 阻塞？ |
|---|---|---|
| 严重 | 立即修复 | 是 |
| 重要 | 在下一功能前修复 | 是 |
| 次要 | 在重构或下一会话中修复 | 否 |
审查循环
质量门禁通过 -> 规格与设计合规审查
|
S1-S5, D1-D5, T1-T3 全部通过（且 U1-U4 如 ui:true）？
| 是 | 否
功能完成 修复 -> 重测 -> 重新审查
|
最多 3 轮 -> 升级到用户
3 轮失败后，通过 AskUserQuestion 升级：
- 各轮发现的所有问题
- 已尝试和修复的内容
- 仍未解决的问题
反模式
| 反模式 | 正确做法 |
|---|---|
| "简单"功能跳过审查 | 始终运行审查 |
| 多个问题打包为一个发现 | 一个关注点一个问题 |
| 表演性认同（"代码写得好！"） | PASS 或具体问题，无废话 |
集成
调用者： vibeflow-build-work（步骤 10） 依赖： 质量门禁通过（vibeflow-quality） 输入： 功能规格、SRS 章节、设计章节、计划文档、ST 测试用例文档、UCD（如 ui:true）、Git diff、测试结果 产出： 审查裁定（PASS/FAIL 及发现） 返回： vibeflow-build-work 的添加示例 + 持久化步骤