sync: 强化覆盖度门控为100%强制+自动补旅程，新增步骤3.6组件级覆盖校验和R8规则

2026-04-14 05:07:54 +00:00
parent 03480936d2
commit c1ba4012fa
2 changed files with 135 additions and 2 deletions
--- a/.claude/skills/d8d-dev/journey-authenticity-rules.md
+++ b/.claude/skills/d8d-dev/journey-authenticity-rules.md
@@ -356,10 +356,91 @@ A 和 B 均不满足 → 普通 FAIL #12 (ENV-ADAPT) → 按提示补填继续

 ---

+## 规则 R8：页面/视图覆盖深度（⛔ 强制）
+
+### 核心原则
+
+应用的每个独立视图/页面必须有足够的旅程覆盖深度。
+"路过式"覆盖（仅 1 步提及）不等于真正的功能验证。
+
+**为什么需要 R8**: FR 级覆盖检查是二值判断（"提到就算覆盖"），无法发现：
+- 一个组件有 10 个交互元素，但旅程只提及了 1 个
+- 一个主视图被其他旅程的 1 步"路过"覆盖，但筛选器联动、分页、导出等核心交互完全未验证
+
+### 最低覆盖标准（⛔ 100% 强制）
+
+| 组件交互元素数 | 最低覆盖要求 | 未满足时 |
+|--------------|-------------|---------|
+| 1-2 个 | 至少 1 步涉及 | 自动补旅程步骤 |
+| 3-5 个 | 至少 1 条旅程含 ≥2 步专门操作该视图 | 自动补旅程步骤 |
+| ≥6 个 | 必须有 1 条专门旅程 | 自动补专门旅程 |
+| **任何** | **每个交互元素必须被 ≥1 步覆盖** | **未覆盖 → 自动补** |
+
+### 交互元素识别方法
+
+```
+1. 从 app-client.tsx 或路由配置提取所有独立视图:
+   grep -n "currentView\|view ===\|render.*View\|component" src/components/features/app-client.tsx
+
+2. 对每个视图组件，统计用户交互元素:
+   grep -c "onClick\|handleClick\|onChange\|handleSelect\|onSubmit" src/components/features/{view-component}.tsx
+
+3. 具体分类:
+   - 按钮: onClick / handleClick / button
+   - 输入框: input / textarea / type="text"
+   - 选择器: select / dropdown / combobox / Select
+   - 分页: page / pagination / nextPage / setPage
+   - 导出: export / download / csv / excel
+   - 弹窗: dialog / modal / open / close
+```
+
+### 检测方法
+
+```
+1. 提取视图列表: 读取 app-client.tsx，识别 currentView 的所有可能值
+2. 对每个视图组件:
+   a. 读取源码，统计交互元素数量
+   b. 读取所有旅程文件，统计该组件被覆盖的步骤数和覆盖深度
+   c. 逐元素判定（⛔ 每个交互元素单独判定）:
+      - 该元素被 ≥1 条旅程步骤覆盖 → ✅ PASS
+      - 该元素未被任何旅程步骤覆盖 → ❌ FAIL → 自动补旅程
+3. 输出组件覆盖矩阵
+```
+
+### 修复策略（⛔ 强制自动补 — 不允许仅 WARN）
+
+```
+检测到任何交互元素未被覆盖:
+  ↓
+1. 分析组件的所有交互元素 → 列出未覆盖清单
+2. 对每个未覆盖元素:
+   a. 确定最佳补充策略:
+      - 已有同视图专门旅程 → 在该旅程中追加步骤
+      - 无专门旅程 → 新建一条旅程（以该视图为主场景）
+   b. 生成旅程步骤:
+      - 用户视角: 自然导航到该元素 + 操作 + 预期结果
+      - 技术验证: browser 操作 + API 断言
+      - 验收标准: 元素可交互 + 效果正确
+   c. 遵循 R1-R8 规则校验
+   d. 写入对应 Epic 旅程文件
+3. 更新覆盖度报告
+4. 重新校验（max 3 次）
+5. 仍失败 → 输出详细未覆盖报告
+```
+
+### 通过标准
+
+- 每个独立视图/页面的**每个交互元素**都被至少 1 条旅程的步骤覆盖（⛔ 100%）
+- 交互元素 ≥ 6 的视图必须有 1 条专门旅程
+- 不允许"仅路过 1 步"覆盖有 ≥ 3 个交互元素的组件
+- ⛔ 不允许任何交互元素仅被标记 WARN 而不补充 — 必须自动补旅程
+
+---
+
 ## 自动校验执行流程（定义和验证通用）

 ```
-步骤 1：逐规则校验（R1 → R2 → R3 → R4 → R5 → R7）
+步骤 1：逐规则校验（R1 → R2 → R3 → R4 → R5 → R7 → R8）
  ↓
 步骤 2：汇总结果
  ├── 全部 PASS → 返回校验通过
--- a/.claude/skills/d8d-dev/journey-mode.md
+++ b/.claude/skills/d8d-dev/journey-mode.md
@@ -55,7 +55,59 @@ Story 验证全部通过 ≠ 用户能正常使用系统。旅程模式弥补这
      - <80% → ❌ FAIL（必须补充旅程后才能进入验证子模式）
   f. 输出覆盖度报告到 `_bmad-output/implementation-artifacts/journey-coverage-report.md`
    ↓
-4. 输出: "已生成/重写 N 个 Epic 旅程文件 + FR 覆盖率 X%"
+3.6 组件级覆盖校验（⛔ 强制 — FR 检查通过后必须执行）:
+   ⛔ 目的：FR 级检查是二值判断（"提到就算覆盖"），无法发现"1 步路过式覆盖"的问题。
+   此步骤深入到组件交互元素粒度，确保每个用户可操作的元素都被旅程验证。
+
+   a. 识别应用的所有主要视图/页面:
+      - 从 app-client.tsx 或路由配置提取视图列表（如 batch-list / batch-dashboard / batch-results）
+      - 从 src/app/ 目录结构提取独立页面路由
+
+   b. 对每个主要视图，读取对应组件源码，提取所有用户交互元素:
+      - 按钮: onClick / handleClick / button 元素
+      - 输入框: input / textarea / type="text"
+      - 下拉选择: select / dropdown / combobox / Select 组件
+      - 筛选器/过滤器: filter / 筛选
+      - 分页控件: page / pagination / nextPage / setPage
+      - 导出/下载: export / download / csv / excel
+      - 对话框/弹窗: dialog / modal / open / close
+
+   c. 比对交互元素 vs 所有旅程的技术验证步骤:
+      - 每个交互元素必须被至少 1 条旅程的某个步骤覆盖
+      - 计算每个组件的覆盖深度 = 被旅程步骤覆盖的交互元素数 / 总交互元素数
+
+   d. 覆盖深度门控（⛔ 100% 覆盖强制 — 任何缺口必须自动补旅程）:
+      | 组件交互元素数 | 最低覆盖要求 | 不满足时 |
+      |--------------|-------------|---------|
+      | 1-2 个 | 至少 1 步涉及 | ❌ FAIL → 自动补旅程 |
+      | 3-5 个 | 至少 1 条旅程含 ≥2 步专门操作该视图 | ❌ FAIL → 自动补旅程 |
+      | ≥6 个 | 必须有 1 条专门旅程（以该视图为主场景） | ❌ FAIL → 自动补旅程 |
+      | 任何数量 | 每个交互元素必须被覆盖 | 未覆盖元素 → 自动补到已有旅程或新建旅程步骤 |
+
+   e. 输出组件覆盖矩阵到覆盖度报告:
+      | 组件 | 交互元素数 | 被覆盖数 | 覆盖深度 | 旅程来源 | 状态 |
+      |------|-----------|---------|---------|---------|------|
+
+   f. 门控汇总（⛔ 100% 强制 — 无 WARN，只有 PASS 或自动补）:
+      - 所有组件所有交互元素 100% 覆盖 → ✅ PASS
+      - 有任何交互元素未被覆盖 → ❌ FAIL → 自动补充旅程步骤（见下方 g）
+
+   g. 自动补旅程流程（⛔ 强制 — FAIL 后必须执行）:
+      1. 列出所有未覆盖的交互元素（组件名 + 元素名 + 元素类型）
+      2. 判断补充策略:
+         a. 已有同视图的专门旅程 → 在该旅程中追加步骤覆盖缺失元素
+         b. 无同视图专门旅程 → 新建一条旅程，以该视图为主场景
+      3. 生成旅程步骤内容:
+         - 用户视角步骤: 从自然导航入口到操作该元素的完整路径
+         - 技术验证步骤: browser_click/type/select + 验证 API 调用
+         - 验收标准: 元素可交互且产生预期效果
+      4. 遵循旅程真实性规则 R1-R8（⛔ 必须通过校验）
+      5. 写入对应 Epic 的旅程文件
+      6. 更新覆盖度报告的组件覆盖矩阵
+      7. 重新执行步骤 3.6.a-f 校验（max 3 次）
+      8. 3 次后仍有未覆盖元素 → ❌ FAIL + 输出详细报告
+    ↓
+4. 输出: "已生成/重写 N 个 Epic 旅程文件 + FR 覆盖率 X% + 组件覆盖率 Y%"
 ```

 ### ⛔ 用户旅程真实性原则