Menu
STDD Phase 5: 质量验证 — 运行测试、覆盖率、lint 等质量检查
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
STDD Phase 4: TDD 实现 — 逐切片实现并通过测试
STDD Phase 2: 规格设计 — 将 proposal 转化为可测试的 spec Scenario
STDD Phase 6: 交付 — 归档 change、合并 specs、更新文档
STDD Phase 3: 切片规划 — 将 spec 拆分为可实现的开发切片
STDD Phase 1: 需求理解与确认 — 将模糊需求转化为清晰、可验证的变更提案（proposal.md）
| name | stdd-verify |
| description | STDD Phase 5: 质量验证 — 运行测试、覆盖率、lint 等质量检查 |
Verify 阶段的以下 7 个 Step 全部是强制步骤，不可跳过任何一步。 进入 Gate 3 前必须确认所有步骤已完成：
| Step | 名称 | 完成标志 |
|---|---|---|
| Step 0 | 多路并行技术评审（3 代理） | 3 个代理均返回审查结果 |
| Step 1 | 全量质量检查 | pytest + coverage + lint 全部执行 |
| Step 2 | Diff 审查 | 逐文件检查所有变更 |
| Step 3 | 十一类失败模式检查 (a-k) | 11 项全部检查完成 |
| Step 3.5 | 经验库自动记录/更新 | 失败模式已记录到 .stdd/experiences/ |
| Step 4 | 汇总设计调整 | design-adjustments.md 已生成（或确认无需调整） |
| Step 5 | 生成测试报告 | test-report.md 已写入 |
Gate 3 前置条件：上述 6 步全部完成后，才能进入 Gate 3 用户确认。
全量质量检查，生成测试报告，追溯设计调整，等待用户最终确认。
.stdd.yaml 中 phases.build.status == "completed"迭代检查循环，行为取决于所选模式：
进入本阶段时，先读取 .stdd.yaml 中的 long_range.mode 确定当前模式。
从 .stdd/config.d/long_range.yaml 的 long_range.pre_auth.iteration.max_rounds 读取长程模式迭代上限。
所有 CLI 操作前必须执行：
python bin/stdd --help，检查返回码 = 0
long_range.mode == "full_auto" 时适用）长程模式 ≠ 可以跳过流程步骤。以下规则不可违反。
| # | 中文 | English |
|---|---|---|
| 1 | Steps 0-5 全部执行 — 长程模式跳过的是授权交互，不是流程步骤。6 个 Step 一个不能少 | ALL Steps 0-5 MUST execute — long-range skips authorization, NOT steps. All 6 steps mandatory |
| 2 | 失败模式检查全量执行 — 12 类检查（含 (l) 锚定缺失）必须全部执行，不得用占位符代替 | ALL 12 failure modes MUST be checked — no placeholder "pass" for unexecuted checks |
| 3 | Gate 3 报告必须如实 — 不得美化、不得省略缺口、不得用 PASS 代替 SKIPPED | Gate 3 report MUST be truthful — no glossing over gaps, no PASS for SKIPPED checks |
| 4 | TC 覆盖率必须报告 — Gate 3 必须展示 test-plan TC 与实际测试的对比 | TC coverage MUST be reported — Gate 3 must show planned vs actual TC comparison |
| 5 | 切片完成度必须逐项展示 — 每个切片的验证状态必须在 Gate 3 中可见 | Slice completion MUST be shown per-slice — verification status visible for each slice |
| 6 | 稻草人检查必须标注 — 任何未实际执行逻辑的检查必须标注为 SKIPPED，不得标注为 PASS | Straw-man checks MUST be labeled — unexecuted checks = SKIPPED, never PASS |
| 7 | 未完成项必须逐项说明 — 当存在未完成项时，必须逐项列出名称、原因、影响、补完计划。不得仅给出数量（如"7 项未完成"）就不加说明。用户需要完整信息才能做出知情决策 | Incomplete items MUST be itemized — list each item's name, reason, impact, and remediation plan. NEVER just report a count (e.g., "7 remaining") without detail. Users need full information for informed decisions |
在开始本阶段之前，检查当前会话的上下文状态。本步骤不可跳过。
stdd state --resume 结果软建议，不阻断。
每轮执行以下步骤，有失败则修复后重新开始：
长程模式下，Steps 0-5 全部按协议自动执行，不做交互暂停。仅在触发降级条件时暂停。
在运行自动化质量检查之前，必须先执行多路并行技术评审。此步骤确保代码、测试、文档的全面审查，发现测试和 lint 无法检测的问题（设计不一致、死代码、文档过时等）。
读取 .stdd/config.d/quality.yaml 中的 review 配置。
同时启动 3 个审查代理，每个代理审查不同维度：
代码质量审查（code 代理）：
测试/配置审查（test_config 代理）：
文档/Skills 审查（docs_skills 代理）：
审查原则：
将发现与 review.severity_thresholds 对比：
判断规则：
review.max_rounds 上限 → 在 test-report 中记录剩余问题并继续对 C 和 H 级问题自动修复：
pending-adjustments.mdM 级问题：记录到 test-report，不强制修复。 L 级问题：仅在 test-report 的附录中列出，不阻塞。
降级条件（长程模式）：
读取 .stdd/config.d/quality.yaml 中的 quality 配置，按以下顺序执行：
1a. 全量测试：pytest tests/ -v
1b. 覆盖率诊断（配置 quality.coverage.enabled: true，默认开启）：
quality.coverage.tool 配置，执行对应的覆盖率命令
pytest-cov：pytest tests/ --cov=<source> --cov-report=term-missing --cov-fail-under=0coverage.py：coverage run -m pytest tests/ && coverage report -mquality.coverage.scope 决定统计范围
changed_files_only（默认）：仅统计 git diff 涉及的变更文件full：全量统计fail_under 固定为 0，覆盖率仅作为诊断信号，不作为阻断条件。覆盖率结果记录到 test-report 的 1.1 节1c. Lint 检查：ruff check app/ tests/
1d. 类型检查（如配置了 mypy/pyright）
1e. 多 Python 版本测试（配置 quality.python_versions 非空时执行）：
quality.python_versions 中列出的每个 Python 版本，运行 pytest tests/ -v1f. E2E 测试（配置 quality.e2e.enabled: true 时执行）：
scope: critical_only（默认）：只执行 critical_paths 中定义的测试用例scope: full：执行全量 E2E 套件quality.e2e.command 读取。常见示例：
npx playwright test — Playwright 浏览器测试npx cypress run — Cypress E2Epytest tests/e2e/ -v — Python-based E2E→ Step 1a-1d 有失败：修复 → 重新运行直到全部通过 → 全部通过（1e 多版本和 1f E2E 结果单独评估，不参与自动修复循环）：进入 Step 2
检查 git diff 的每个变更文件，逐项检查：
→ 发现问题：修复 → 回到 Step 1 → 无问题：进入 Step 2.1
执行条件：自动检测。如果 diff 中不包含代码文件（无 .py / .go / .java / .rs / .ts 文件变更），自动切换检查维度：
git diff --name-only 检查变更文件扩展名检测到非代码 Change（<N> 个文档/配置文件），已切换检查维度CODE_EXTENSIONS = {'.py', '.go', '.java', '.rs', '.ts', '.tsx', '.js', '.jsx', '.c', '.cpp', '.h'}
对 diff 进行以下专项检查：
(a) 幻觉行为 — 编造的文件路径、环境变量、函数名、库 API
(b) 范围蔓延 — 超出计划文件的改动、打包进来的重构
(c) 级联错误 — 静默吞掉的异常、空数组 fallback 掩盖问题
return [] 掩盖了真错误？(d) 上下文丢失 — 与 proposal/design/spec 决策矛盾
(e) 工具误用 — 错误的工具选择或参数
以下 (f)-(i) 为 V1.1 新增项，基于 FPPT 项目实测中发现的 TDD 系统性盲区。(j)-(k) 为 V1.2 新增项，基于 FPPT 验收测试回溯。
(f) 运行时行为偏差 — 静态结构正确但动态行为异常
(g) 管线断链 — 多步骤转换/构建链路不完整
(h) 内容质量偏差 — 技术规范满足但内容可用性不足
(i) 指令衰减 — Prompt 中明确写了但 AI 未充分执行
以下 (j)-(k) 为 V1.2 新增项，基于 FPPT 项目验收测试回溯中发现的 STDD 流程盲区。
(j) 覆盖真空 — 某 capability 零自动化测试覆盖
(k) 契约断层 — 跨 capability 的接口字段名/格式不一致
data.token_balance，前端读取 data.balanceX-Device-Id header，前端 fetch 调用中未发送该 header{result: {...}}，前端读取 data.result（多层或少层包装）data.xxx、response.data.xxx、解构赋值），提取消费字段名清单request.headers.get('X-...')），对比前端是否发送了对应 header触发条件：执行 Step 3 前，先检查 change 目录的文件类型。IF change 目录不包含 *.py, *.go, *.java, *.rs, *.ts 文件，THEN 使用以下 5 项替代检查，ELSE 使用上述 11 类失败模式检查。
替代检查 (a) 链接有效性：
替代检查 (b) 文件范围一致性：
git diff --stat 的实际变更替代检查 (c) 内部引用可达性：
<a href> / <link href> / <script src> 引用是否指向存在的文件替代检查 (d) 内容完整性：
替代检查 (e) TC 目视验证覆盖：
在完成十一类失败模式检查后，将本次发现的失败模式记录到项目经验库，供后续 BUILD 阶段复用：
对 Step 3 中每个命中的失败模式，构造经验条目：
category：对应 11 类失败模式的 snake_case 别名（如 cascading_errors, contract_gap）pattern：具体错误模式描述（≤80 字，清晰陈述而非冗长叙述）root_cause：AI 产生此错误的根本原因推测detection_trigger：什么信号可以检测到此模式（如 "async 超时测试不稳定"）fix_template：修复此模式的标准步骤severity：high / medium / low，基于是否为阻塞性问题source_change：当前 change 名称language：项目语言（从 project.yaml 读取）对每个命中的模式执行 CLI 记录：
python bin/stdd experience add \
--category <category> \
--pattern "<pattern>" \
--root-cause "<root_cause>" \
--detection-trigger "<detection_trigger>" \
--fix-template "<fix_template>" \
--severity <severity> \
--language <language> \
--source-change <change_name> \
--tags "<comma-separated-tags>"
对已存在的经验条目（相同 category + 相似 pattern），更新而非新建：
python bin/stdd experience list --category <category> --format json 查询现有条目记录完成后执行 python bin/stdd experience stats 获取概要，输出格式：
经验库更新: 新增 N 条, 命中 M 条已有记录, 总计 T 条
将经验更新结果写入 test-report.md 的"经验库更新"章节
pending-adjustments.md（Phase 3-4 期间记录的偏离）如果有任何调整，读取模板 .stdd/templates/design-adjustments.md 并生成 design-adjustments.md
读取模板：.stdd/templates/test-report.md
生成 test-report.md，包含：
正常停止（全部满足）：
硬上限停止：
普通模式：
长程模式：
test-report.md 中汇总所有剩余问题长程模式下，以下情况自动降级为暂停等待用户：
向用户展示测试结果和设计调整后，必须等待用户明确确认。Gate 3 在普通模式和长程模式下均为强制确认门，不可自动跳过。
长程模式下，Phase 3-5 内部交互点已被预授权覆盖，但 Gate 3 确认仍然需要用户介入。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STDD Phase 5: VERIFY — 等待确认
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 产出物：
✅ test-report.md — 测试报告
📊 测试结果：
- 单元/集成: 总数 N / 通过 N / 失败 N / 跳过 N (通过率 N%)
- E2E: 总数 N / 通过 N / 失败 N (通过率 N%) [如配置]
- Lint: ✅ / ❌
- 覆盖率: <变更文件数>文件, <低覆盖文件数>文件需关注
🔍 多路并行技术评审结果（Step 0）：
代码质量审查：C:N H:N M:N L:N
测试/配置审查：C:N H:N M:N L:N
文档/Skills审查：C:N H:N M:N L:N
自动修复：N 项 C/H 问题已修复
审查结论：✅ 通过 / ⚠️ 有 N 项 M 级问题记录在 test-report
🧠 经验库更新（Step 3.5）：
新增经验: N 条 | 复用已有: N 条 | 总计: N 条
📋 步骤完成确认：
✅ Step 0: 多路并行技术评审 — 已完成
✅ Step 1: 全量质量检查 — 已完成
✅ Step 2: Diff 审查 — 已完成
✅ Step 3: 十一类失败模式检查 (a-k) — 已完成
✅ Step 3.5: 经验库更新 — 已完成
✅ Step 4: 汇总设计调整 — 已完成 / N/A（无需调整）
✅ Step 5: 生成测试报告 — 已完成
📝 设计调整（如有）：
<design-adjustments.md 摘要>
⚠️ 请确认：
- 测试结果是否满意？
- E2E 失败项（如有）是否可以接受？
- 覆盖率低覆盖文件是否需要补测？
- 设计调整是否合理？
- 是否可以进入交付阶段？
👉 确认继续，或提出需要调整的地方。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
确认门模板参见:
.stdd/skills/_shared/confirm-gate.md
test-report.md — 测试执行报告design-adjustments.md — 设计调整说明（如有）.stdd.yaml（phase: verify → completed）完成前确认：
Phase 5 用户确认 → 进入 Phase 6: DELIVER（交付） Phase 5 用户有异议 → 回到 Phase 2: SPEC（修订规格）