メニュー
STDD Phase 5: 质量验证 — 运行测试、覆盖率、lint 等质量检查
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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（修订规格）