# Vibeflow Quality

> TDD 循环后使用 — 强制覆盖率门禁、变异测试门禁和新鲜验证证据，方可标记功能为通过

- Skill: `ttttstc/vibeflow-quality` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ttttstc/vibeflow-quality`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ttttstc/vibeflow-quality/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ttttstc (https://skillmd.com/u/ttttstc)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ttttstc/vibeflow-quality

---


# 质量门禁与验证

三道顺序门禁，**全部**必须通过后功能才能被标记为 "passing"。没有捷径，没有例外。

**启动宣告：** "正在使用 vibeflow-quality 运行质量门禁。"

## 铁律

```
没有新鲜验证证据就不能声称完成
```

如果你在这条消息中没有运行验证命令，你不能声称它通过了。

## 门禁阈值来源

从 `.vibeflow/work-config.json` 读取质量门禁阈值：
- `line_coverage_min`
- `branch_coverage_min`
- `mutation_score_min`

如 work-config.json 不存在，从 `feature-list.json` 的 `quality_gates` 读取。

## 门禁 1：覆盖率

TDD Green（所有测试通过）后，运行覆盖率工具。

1. **运行**覆盖率命令（先激活环境）
2. **阅读**完整输出（不仅是摘要行）
3. **验证**：行覆盖率 >= 阈值，分支覆盖率 >= 阈值
4. **如失败**：识别未覆盖行/分支 -> 添加测试 -> 重新运行 TDD 循环
5. **如通过**：进入变异测试门禁

**必需证据：**
```
- 覆盖率工具输出，显示行 % 和分支 %
- 行覆盖率 >= 阈值
- 分支覆盖率 >= 阈值
- 未覆盖行列表（如有，附理由）
- 实际运行的命令
```

## 门禁 2：变异测试

TDD Refactor 后，对变更文件运行变异测试。

1. **运行**变异测试命令（替换 `{changed_files}` 为实际路径）
2. **阅读**完整输出
3. **验证**：变异得分 >= 阈值
4. **如有存活突变体**，逐一分析：
   - **等价突变**（代码变更无可观测效果）-> 记录并跳过
   - **真实缺口**（测试未捕获突变）-> 添加/加强测试，重新运行
   - **不可达代码** -> 移除死代码
5. **如通过**：进入验证与标记

**增量 vs 全量：**
| 场景 | 范围 |
|------|------|
| 每个功能（常规） | 增量 — 仅变更文件 |
| 项目里程碑（每 5-10 个功能） | 全量 — 整个代码库 |

## 门禁 3：验证与标记

标记功能为 "passing" 前的最终门禁。

```
1. 识别 -> 获取测试/覆盖率/变异测试命令
2. 运行 -> 执行每个命令（新鲜的，在此消息中 — 不是之前缓存的）
3. 阅读 -> 每个的完整输出：
   - 检查退出码
   - 计数测试 通过/失败/跳过
   - 读取覆盖率百分比
   - 读取变异得分
4. 验证 -> 所有输出都确认声称？
   - 所有测试通过（0 失败）？
   - 覆盖率 >= 阈值？
   - 变异得分 >= 阈值？
5. 然后声称 -> 仅现在：
   - 标记功能 "status": "passing"
   - 报告结果及证据

如任何步骤失败 -> 停止。不标记为 passing。先修复问题。
```

## 项目规则检查

如果当前 feature 合同的 `custom_rules.files` 非空，质量门禁阶段必须补跑项目规则的可执行检查，而不是只看代码“感觉上像是符合规范”。

对当前功能的变更文件运行：

```bash
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）