vibeflow-spec-review

name	vibeflow-spec-review
description	每个功能质量门禁通过后使用 — 运行规格与设计合规审查，确保实现匹配审批通过的规格、设计、计划和 UCD

规格与设计合规审查

每个功能质量门禁通过后运行。无例外。验证实现匹配审批通过的规格、设计、计划和 UCD。

启动宣告： "正在使用 vibeflow-spec-review 审查此功能。"

运行时机

• 每个功能通过质量门禁后
• 在持久化阶段（git commit）前
• 无例外 — 即使"简单"功能也需审查

阶段 1：规格与设计合规

核心问题：

1. 实现是否做了功能规格所说的事？（SRS 可追溯性）
2. 实现是否遵循设计文档？（架构、类结构、交互流、依赖版本）
3. 实现是否遵循计划文档？（任务分解、约定方案）
4. 对 "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 的添加示例 + 持久化步骤