test-coverage-guard

测试覆盖完整性守门规则（test-coverage-guard）

核心问题：测试智能体把「执行了可执行脚本」等价于「完成了测试规格文档要求的所有测试」。 这两者不等价——脚本是文档的子集，而不是全集。

---

触发条件

以下任一条件出现，立即触发此规则（在输出之前检查）：

• 输出内容含「测试完成」「测试通过」「测试结束」
• 输出内容含「等待你的决策」「等待上线」「可以上线」
• 输出内容含「进入 DevOps」「触发 DevOps」
• 输出内容含「关卡C 通过」「通过」（在测试语境中）

---

触发后立即执行（输出之前）

Step 1: 查找覆盖状态文件
  Glob: 项目群/[项目]/测试工程师/test-coverage-state.md
  
  IF 文件不存在：
    → 这意味着 Step 0.4 没有执行（覆盖基线未建立）
    → 输出：「⛔ [test-coverage-guard] 覆盖状态文件不存在。
              测试在未建立覆盖基线的情况下运行，无法验证完整性。
              请先执行 Step 0.4（测试覆盖基线建立），重新开始测试。」
    → 停止当前声明，等待处理
  
  IF 文件存在：继续 Step 2

Step 2: 统计待执行项目
  Read: test-coverage-state.md
  提取所有状态为「🔲待执行」的行
  pending_count = 🔲状态行数
  
  IF pending_count > 0：
    → 禁止当前「测试完成」声明
    → 输出：「⛔ [test-coverage-guard] 测试未全量完成
    
              ⚠️ 仍有 {pending_count} 个测试项目未执行：
              {列出所有🔲待执行的测试ID和描述}
              
              选择：
              A. 立即执行这 {pending_count} 条测试（推荐）
              B. 明确标记为「跳过」并说明理由（需逐条说明）
              C. 请求用户决策（暂停循环）
              
              在此解决之前，不允许进入 DevOps。」
    → 等待处理，不继续当前声明
  
  IF pending_count == 0：
    → 所有测试有明确状态，允许继续
    → 在继续的声明开头附加：
      「✅ [test-coverage-guard] 覆盖验证通过（全部 N 条有明确状态）」

---

「脚本子集」问题的专项检测

如果检测到以下模式，额外输出警告：

模式：测试智能体执行了 run_tests.py 或 pytest
且：没有对照「测试规格文档」做差集检查

检测到此模式时，输出：
「⚠️ [test-coverage-guard] 检测到「脚本执行」模式：
   run_tests.py/pytest 只是测试规格文档的可执行子集。
   请确认：主测试文档中的所有测试ID是否都已在覆盖状态文件中？
   
   如未验证 → 请先运行 Step 0.4 建立基线并对照差集。」

---

与现有规则的关系

规则	关系
session-bootstrap.mdc B3.5	本规则是测试版的专项守门，解决测试特有的「脚本≠文档」问题
role-测试工程师 Step 6.4	本规则是 Step 6.4 的前置守门，在 Skill 层的门禁之前提供 Rule 层保障
role-测试工程师 Step 0.4	本规则依赖 Step 0.4 生成的 test-coverage-state.md

---

变更记录

v1.0 — 2026-03-25 — 初始创建

根因： 对话 53b74d66（项目架构文档编写，753条消息）事后分析发现： 测试智能体在 Message 745 宣布「测试完成，等待你的决策」，但实际上有 26 个测试用例未执行（Layer 3 AI质量、E2E完整链路、幂等性等）。根本原因是：

1. 没有「执行了多少 = 文档要求了多少」的校验机制
2. 长对话导致记忆压缩，AI 忘记了文档要求的全量测试项目
3. Skill 层的 Step 6.5 DevOps门禁已有，但缺少「测试完整性」专项门禁

本规则作为 Rule 层（比 Skill 层更早触发）的守门，从根本上阻断「未全量测试→声称完成」的行为链。