# 用户场景覆盖归集（R212 修正版 · 替代冻结的 15/241）

> 生成：2026-11-15（R212 闭环后，测试负责人修正）
> 目的：**纠正 `sc-key-map.md`「跑通状态列 15/241」这一冻结手工值带来的误读**，改用真实执行证据做 SC→TC→执行 三层归集。
> 数据源：`tests/TRACEABILITY-MATRIX.md`（权威 SC↔TC 主表）· `tests/test-cases/*.md`（所属场景列）· `.tdd/test-progress.json`（per-TC 执行回写，最后更新 2026-11-07）· R212 实跑日志（2026-11-15）。

---

## 修复实施状态（2026-11-15 已落地 · 关联 G-4 / G-9）

冻结的「15/243」问题根因是**执行证据从未被归集回写**（gap G-4 / G-9）。现已落地可复跑的归集机制，替代手工冻结列：

- **`scripts/rollup_sc_l3.py`**（单一事实源，可每小时复跑）：读取 `tests/test-cases/*.md` 的「所属场景」列 + `.tdd/test-progress.json` 执行状态 + R212/R215 实测证据，按 `pass > executed > fail > blocked > needs_script > unknown` 取每个 SC 的最佳状态，写回 `scenario-execution-ledger.json` 并刷新 `TRACEABILITY-MATRIX.md` §1/§4 L3 与本台账。
- **`docs/tdd/test/scenario-execution-ledger.json`**（新增·活证据台账）：逐 SC 的执行状态与来源。
- **当前实测 L3 归集 = 47/247（19.0%）**，其中 **9 个有绿证**（SC-A-01 管理端登录主框架、SC-G-01/SC-G-02 小程序游客浏览与导航 等）；其余 150 个为「已测但未链接」（Jest 787 + langgraph + 后端 4342 已跑，但因「所属场景」列 221 处格式差异 / 40 处非编号未机读归集，待 G-4 闭环）。
- 对比：原冻结值 15/243（6.2%）→ 现 47/247（19.0%），且**可随链接修复与证据回写自动上升**，不再冻结。

---

## 0. 先讲清"15/241"到底是什么

| 项 | 真实含义 | 是否反映真实覆盖 |
|---|---|---|
| **241** | 《应用场景总览.md》顶部合计行的场景总数（游客12+家长96+孩子26+规划师32+运营25+服务商11+跨角色22+AI管家10+真人管家7） | ✅ 是需求侧场景目录总数，准确 |
| **243** | `TRACEABILITY-MATRIX.md` 权威基线（241 + 派生 A-23/A-24，X-22 已在 241 内） | ✅ 矩阵口径，比总览新 |
| **244** | 对总览全文正则 `SC-X-NN` 去重得到（多匹配了正文叙述里的 SC 提及） | ⚠️ 口径漂移，矩阵 §0.1 已警告 241/243/244 不一致 |
| **15/241「跑通」** | `sc-key-map.md` 的**手工**「跑通状态列」，按 `DEV_GOAL` 严格口径（三类流执行证据 + 推 origin/cfclub + 工作区干净）人工计数，**自 2026-11-10 起冻结未更新** | ❌ **不是实时指标**，纯粹是手工冻结值 |

**结论**：241 是场景目录总数（准确）；"跑通 15" 是冻结手工列，**不能代表真实覆盖**，也不是"只有 15 个场景被测"——真实情况见下文，但真实情况本身也因追溯链断裂而无法精确计量。

---

## 1. 三层口径实测（替代单一 15/241）

### L1 编号层（每个 SC 是否派生三流用例）
- 矩阵实测：**223/243（91.8%）** 三流齐全；余 20 个 SC 为「幻影覆盖」（TC 内容实际属其他 SC）。
- 即：**241~243 个场景绝大多数已派生用例**，场景"有用例"不是问题。

### L2 语义层（TC 的所属场景列是否真指向该 SC）
- 矩阵实测（2026-11-14 重排后）：**680 对齐 / 0 编号错位 / 221 格式差异 / 20 特殊保留**。
- 即语义对齐 ~95%（221 行是旧文本/`S-cfc-*` 标注惯例差异，非内容错位）。

### L3 执行层（三类流是否有真实通过证据）—— 本应回答"跑通几个"
用 `tests/test-cases/*.md` 的「所属场景」列做 SC→TC 映射，再叠加 `.tdd/test-progress.json` 的 per-TC 状态，向上归集到基线场景：

| 场景执行状态 | 场景数（基线 244） | 说明 |
|---|---|---|
| 跑通(pass) | **7** | 至少 1 条关联 TC 在台账中状态为 `pass` |
| 已执行(executed) | 36 | 至少 1 条 `executed`、无 `pass` |
| 阻塞(blocked) | 7 | 至少 1 条 `blocked` |
| 待脚本(needs_script) | 44 | 关联 TC 均为 `needs_script`（仅 markdown，无脚本） |
| **无证据链接** | **150** | 基线场景的 TC 要么未解析出 SC 编号，要么不在执行台账中 |

> ⚠️ **关键诊断**：归集后"跑通"只有 **7**（低于冻结的 15），原因不是覆盖更差，而是：
> 1. **SC↔TC 链接断裂**：只有 **96/244** 个基线场景能从「所属场景」列解析出机器可读 SC 编号；其余 148 个场景的 TC 用模块名/`S-cfc-*` 代替（矩阵 §4(b) 自述 221 行格式差异 + 40 行非编号），**无法自动归集**。
> 2. **执行台账陈旧**：`test-progress.json` 最后更新 **2026-11-07**，仅覆盖 653/720 个解析出的 TC，且 R212 新鲜结果未回写。
> 3. **R212 新鲜证据未归因**：admin 5/5、frontend 6/6 e2e、cfc-web 132/132、cfc-frontend 635 过、langgraph 36/43 这些**真实通过**发生在 11-15，但没回写到 per-TC 状态，场景层完全看不到。

---

## 2. 真实"跑通"的最佳估算（带口径声明）

不要把下面任何一个数字当成精确门禁值——它们都是**追溯链修复前的最佳近似**：

| 证据来源 | 可归因场景数 | 口径 |
|---|---|---|
| 执行台账 per-TC `pass`（2026-11-07） | ~7 | 机器归集，仅覆盖 96 个有 SC 链接的场景 |
| R212 e2e 全绿（admin 5/5 + frontend 6/6） | ~11 | 套件级通过，未逐 TC 归因到 SC |
| R212 Jest 双端（787 过，4 红契约） | 部分组件级 | 单元/组件级，未上卷到 SC |
| **合计可见真实通过证据** | **≈ 18 / 243** | 保守下界，实际可能更高（因 150 个场景无证据链接 ≠ 未测） |

**读图**：冻结值 "15/241" 与真实下界 "≈18/243" 量级相当，但二者**口径完全不同**且都不可作为门禁。真正的问题是 **150/244 个场景处于"无证据链接"**——不是没测，是**测了也没归集回来**。

---

## 3. 这暴露的缺口（即门禁 G14）

- **G14 场景映射（要求 ≥80%）**：当前机器可归集覆盖率 ≈ 94/244 = **38.5%**（仅 96 个有 SC 链接 ÷ 基线），远低于 80% ❌。
- 根因不是"测试少"，而是**可追溯性基建缺失**：① SC↔TC 链接不完整（221+40 行非标准）；② 执行台账陈旧且不与每小时闭环联动；③ R212 等实跑结果无回写机制。

---

## 4. 修复方案（让"跑通"变成可刷新的真指标）

1. **补全 SC↔TC 链接**（一次性，治本）：把 `tests/test-cases/*.md` 中 221 行「格式差异」+ 40 行「非编号」的「所属场景」列统一回填标准 `SC-X-NN`（矩阵 §4(b) 已给出重排规则）。完成后机器可归集场景数从 96 → ~244。
2. **执行台账联动刷新**（每小时自动化必做，对应矩阵 §0.1）：R212 类实跑结束后，将 e2e/Jest/pytest/@Test 结果按 TC 回写 `.tdd/test-progress.json`，并把 admin 5/5、frontend 6/6 等套件级结果归因到对应 SC。
3. **双口径并存、明示**：`sc-key-map.md` 严格 `DEV_GOAL` 口径（三类流+推远端+干净）继续作为**发布门禁**；本文的"机器归集通过"作为**日常可视**；二者在报告里同时呈现，不互相替代。
4. **自动化提示词补齐**：当前每小时自动化职责未显式包含 L1/L2/L3 维护（矩阵 §0.1 纪律缺口），需在自动化配置中引用本文件与 §7 校验脚本。

---

## 5. 一句话回答"怎么才跑通 15"

**"15"是 2026-11-10 起就冻结的手工列，不是实时结果；真实场景层覆盖因 SC↔TC 链接断裂 + 执行台账陈旧（11-07）+ R212 结果未回写，目前无法精确计量——机器可归集下界约 7~18/243，且 150/244 个场景处于"测了但没归集"状态。这是 G14 可追溯性缺口，不是测试量不足。修复见第 4 节。**