ttttstc 质量门禁与验证
三道顺序门禁，全部必须通过后功能才能被标记为 "passing"。没有捷径，没有例外。
启动宣告： "正在使用 vibeflow-quality 运行质量门禁。"
铁律
没有新鲜验证证据就不能声称完成
如果你在这条消息中没有运行验证命令，你不能声称它通过了。
门禁阈值来源
从 .vibeflow/work-config.json 读取质量门禁阈值：
line_coverage_minbranch_coverage_minmutation_score_min
如 work-config.json 不存在，从 feature-list.json 的 quality_gates 读取。
门禁 1：覆盖率
TDD Green（所有测试通过）后，运行覆盖率工具。
- 运行覆盖率命令（先激活环境）
- 阅读完整输出（不仅是摘要行）
- 验证：行覆盖率 >= 阈值，分支覆盖率 >= 阈值
- 如失败：识别未覆盖行/分支 -> 添加测试 -> 重新运行 TDD 循环
- 如通过：进入变异测试门禁
必需证据：
- 覆盖率工具输出，显示行 % 和分支 %
- 行覆盖率 >= 阈值
- 分支覆盖率 >= 阈值
- 未覆盖行列表（如有，附理由）
- 实际运行的命令
门禁 2：变异测试
TDD Refactor 后，对变更文件运行变异测试。
- 运行变异测试命令（替换
{changed_files}为实际路径） - 阅读完整输出
- 验证：变异得分 >= 阈值
- 如有存活突变体，逐一分析：
- 等价突变（代码变更无可观测效果）-> 记录并跳过
- 真实缺口（测试未捕获突变）-> 添加/加强测试，重新运行
- 不可达代码 -> 移除死代码
- 如通过：进入验证与标记
增量 vs 全量：
| 场景 | 范围 |
|---|---|
| 每个功能（常规） | 增量 — 仅变更文件 |
| 项目里程碑（每 5-10 个功能） | 全量 — 整个代码库 |
门禁 3：验证与标记
标记功能为 "passing" 前的最终门禁。
1. 识别 -> 获取测试/覆盖率/变异测试命令
2. 运行 -> 执行每个命令（新鲜的，在此消息中 — 不是之前缓存的）
3. 阅读 -> 每个的完整输出：
- 检查退出码
- 计数测试 通过/失败/跳过
- 读取覆盖率百分比
- 读取变异得分
4. 验证 -> 所有输出都确认声称？
- 所有测试通过（0 失败）？
- 覆盖率 >= 阈值？
- 变异得分 >= 阈值？
5. 然后声称 -> 仅现在：
- 标记功能 "status": "passing"
- 报告结果及证据
如任何步骤失败 -> 停止。不标记为 passing。先修复问题。
项目规则检查
如果当前 feature 合同的 custom_rules.files 非空，质量门禁阶段必须补跑项目规则的可执行检查，而不是只看代码“感觉上像是符合规范”。
对当前功能的变更文件运行：
python scripts/vibeflow_rules.py --project-root . --stage build --language <language> --file-scope <changed-file> --file-scope <changed-file> --design-path docs/changes/<change-id>/design.md --evaluate-checks --format markdown
要求：
- 命令退出码必须为 0，才能继续标记功能为
passing - 如果输出里有
Issues:，先修复，再重新执行 Warnings:需要在功能报告中说明为什么可以接受，或转成后续改进项- 这些检查是覆盖率/变异测试之外的项目规范门禁
红线词
如果你发现自己使用以下任何词语，停止并重新验证：
| 红线 | 必需行动 |
|---|---|
| "应该通过" | 立即运行测试 |
| "可能可以" | 立即执行并验证 |
| "看起来在工作" | 获取具体测试输出 |
| "我相信这是正确的" | 运行验证命令 |
| "看起来不错" | 运行自动化测试 |
| "基于实现来看" | 测试验证行为，不是代码 |
| "测试应该是绿的" | 运行测试并读取输出 |
| "我已验证"（无输出） | 展示实际输出 |
| "覆盖率可能够了" | 立即运行覆盖率工具 |
| "变异得分应该够高" | 立即运行变异测试 |
验证时机总结
| 事件 | 验证什么 |
|---|---|
| TDD Green 后 | 完整测试套件输出 |
| 覆盖率门禁后 | 覆盖率报告（行% + 分支%） |
| TDD Refactor 后 | 完整测试套件（仍然通过） |
| 变异门禁后 | 变异报告（得分%） |
| 标记 "passing" 前 | 以上全部 + verification_steps |
| Git 提交前 | 完整测试套件（不提交破损代码） |
反模式
| 反模式 | 正确做法 |
|---|---|
| 写代码后不运行测试就标记 "passing" | 运行测试，读取输出，然后标记 |
| 相信重构没有破坏任何东西 | 每次重构后重新运行完整套件 |
| 只读测试输出的摘要行 | 读取完整输出 |
| 对未覆盖代码运行变异测试 | 先通过覆盖率门禁 |
| 会话开始时跳过重新验证 | 始终冒烟测试已通过功能 |
集成
调用者： vibeflow-build-work（步骤 8） 依赖： TDD 循环完成（vibeflow-tdd 通过 — 测试存在且通过） 产出： 新鲜验证证据（测试输出、覆盖率 %、变异得分） 链接到： vibeflow-feature-st（通过 Work 步骤 9）