# CFC 需求 ↔ 用户场景 ↔ 测试用例 双向追踪矩阵

> **生成**：2026-11-10（测试负责人闭环，用户授权「补写缺用例 + 重建双向矩阵」）
> **单一事实源**：场景基线 `docs/tdd/orchestration/sc-key-map.md`（244 个 SC）· 用例 `tests/test-cases/*.md` · 需求 `docs/需求分析/*.md` 与 `docs/superpowers/specs/*.md`
> **状态定义**：✅ 已派生三流用例 / ⚠️ 场景存在但变更点未派生 / ❌ 未入场景池（需派生，本轮未擅自编号入册）
> **本文所有数字为编号级实证扫描结果，不引用任何文档自述口径**（历史台账存在 678 / 701 / 729 / 767 四套互相矛盾的数字）。

> **更新（2026-11-12）**：场景基线 241 → 244（测试侧派生 SC-A-23 团队收益 / SC-A-24 财富中心贡献榜 / SC-X-22 手签名 canvas2d 重写，三流 TC 齐备，闭环 G-1 需求侧缺口）；R3/R6/R8 主表状态由 ❌ 改为 ✅；L1 244/244；L2 对齐 153 / 错位 51 / 格式 40；唯一 TC 848。本更新仅改文档与台账，未动生产源码、未提交、未推送（待 Task #7 单独授权后入册）。

---

## 0. 口径与层级

「场景是否有用例」必须分三层回答，**只报第一层会得出错误结论**：

| 层 | 判据 | 数据来源 |
|---|---|---|
| L1 编号层 | 每个 SC 是否存在 `TC-xxx` / `-E` / `-P` 三个编号 | `tests/test-cases/*.md` 表首列 |
| L2 语义层 | 该 TC 的「所属场景」列与步骤/预期是否真在描述这个 SC | TC 行正文 vs `应用场景总览.md` 场景标题 |
| L3 执行层 | 三类流是否有**实际通过证据**且已推远端、工作区干净 | `sc-key-map.md` 跑通状态列 + `automation-status.md` |

### 0.1 每小时自动化必须维护的 L1/L2/L3 纪律（2026-11-12 补全，单一事实源）

每小时自动化「测试负责人闭环」（task `0f6cf699-7aa0-4315-b7ed-414efa7e06dd`）在每轮执行时**必须同步维护以下三层**，否则矩阵会随 SC 派生 / TC 重排而漂移（2026-11-12 曾因派生 3 个 SC 未及时回写导致 241/244 口径不一致）：

- **L1 编号层纪律**：每轮重跑 §7 校验脚本，确认「三类流齐全 SC 数 / 总 SC 数」一致；新增 SC（如 2026-11-12 派生 A-23/A-24/X-22）须在 `sc-key-map.md` 与本文 §2/§4 同步登记，基线计数随之 +N，且 `sc-key-map.md` 计数行、`## 全量登记` 标题、本文 §1 三处数字一致。
- **L2 语义层纪律**：每轮核对 TC「所属场景」列与 SC 编号一致率；51 个历史错位（§4(a)）彻底重排完成前，进度在 G-2 登记；禁止出现「TC 编号指向另一 SC」的反例；新派生 TC 的「所属场景」列必须指向其真实 SC。
- **L3 执行层纪律**：跑通状态严格按 `sc-key-map.md` 计数口径（三类流实际执行证据 + 已 push `origin/cfclub` + 工作区干净），**不可用子串 `跑通` 匹配**（会命中「未跑通」，历史教训 LES-002）；状态列变更必须经单独授权后 git 提交推送，不伪造证据、不 mark-green。
- **变更联动纪律**：任何需求变更派生 SC/TC（如 R3/R6/R8→A-23/A-24/X-22），须在 §2 主表回写 SC/TC 并标 ✅，同步更新 G-1 缺口与 §5 反向引用计数。
- **锚点对账纪律**：每轮刷新 §10 双向对账（台账 ↔ 可执行锚点），孤儿锚点按 §10.3 动作收敛，覆盖率数字不得虚高（排除 `tests/e2e/api/generated`）。

> ⚠️ **纪律缺口（待补全到自动化提示词）**：当前自动化可见职责为「全部用例通过 + 覆盖 SRS/场景含异常流 + 浏览器走 admin/frontend + langgraph 派 251 + 结果有变提交远程并通知研发」，**未显式包含上述 L1/L2/L3 维护条目**。本 §0.1 为权威纪律定义，自动化提示词应显式引用本 §0 与 §7 校验脚本；若提示词未含上述条目，视为纪律缺口，需在自动化配置中补全（提示词文本存于云端自动化配置，不在工作树可读范围，补全需用户在自动化 UI 操作或授权后由 `automation_update` 写入）。

---

## 1. 实测总览（2026-11-10）

| 项 | 补写前 | 补写后 | 判定 |
|---|---|---|---|
| 权威 SC 基线 | 241 | **244**（+3，2026-11-12 测试侧派生） | 不变 |
| 唯一 TC 编号 | 827 | **848**（+21：+15 本轮补写 / +6 2026-11-12 派生 SC-A-23·A-24 三流） | 正常流 284 / 异常流 251 / 权限流 245 / 非功能 58 / 深挖 10 |
| L1 三流齐全 | 237/241 | **244/244（100%）** | ✅ 4 个纯缺口已补 + 2026-11-12 派生 3 SC 三流齐备；另发现 1 个编号占用冲突已补新编号 |
| L2 编号对齐 | 150 对齐 / 51 错位 / 40 格式差异 | **153 对齐 / 51 错位 / 40 格式差异**（+3 派生 SC 对齐） | ⚠️ 硬缺口，见 §4（51 错位待彻底重排，用户已裁决） |
| L3 已跑通（DEV_GOAL 严格口径） | 15/241（6.2%） | 15/244（**未变**） | ❌ 229 个仍无远端证据；详见 §9 与 G-4 |
| 本轮真实执行用例 | — | 42 个：30 passed / 3 failed / 9 skipped | 见 `docs/tdd/test/execution-evidence-2026-11-10.md` |
| 需求侧 SC 回链 | 11/214（5.1%） | **16/214（7.5%）** | 8 份 11 月变更已补回链附录 |
| 需求侧 TC 回链 | 1/214（0.5%） | **6/214（2.8%）** | 同上 |

---

## 2. 主表：需求变更 → 能力键 → SC → TC

> 需求侧反向锚点已写入每份需求文档末尾的「附录 · 场景与用例回链」，可双向跳转。

| # | 需求变更文档（`docs/需求分析/`） | 能力键 | 关联 SC | 关联 TC（正常 / 异常 / 权限） | 状态 |
|---|---|---|---|---|---|
| R1 | `2026-11-06-成就成长打卡需求变更.md` | `task.history.view` | SC-P-94 | TC-P-94 / -E / -P | ✅ 本次补写 |
| R1 | 同上 | `growth.history.view` | SC-P-95 | TC-P-95 / -E / -P | ✅ 本次补写 |
| R1 | 同上 | `sleep.config.tags` | SC-C-26 | TC-C-26 / -E / -P | ✅ 本次补写 |
| R1 | 同上 | `sleep.config.tags` | SC-A-27 | **TC-A-27-S / -S-E / -S-P** | ✅ 本次补写（编号占用冲突，见 G-2） |
| R1 | 同上 | `achievement.grid.fiveCol` | SC-P-96 | TC-P-96 / -E / -P | ✅ 本次补写 |
| R2 | `2026-11-06-优惠券已领取券按钮修复需求变更.md` | `coupon.claimed.actions` / `coupon.checkout.autoselect` | SC-P-57 · SC-P-75 · SC-A-17 | TC-P-57* / TC-P-75* / TC-A-17* | ⚠️ 双按钮、按券类型跳转、checkout 自动选券三处变更点均无断言 |
| R3 | `2026-11-06-我的团队收益口径与邀请分享需求变更.md` | `team.referral.earnings.cf` / `team.invite.share` | **SC-A-23** | TC-A-23 / TC-A-23-E / TC-A-23-P | ✅ 2026-11-12 测试侧派生三流用例（admin.md SC-A-23 专项） |
| R4 | `2026-11-06-报告上传页关联商品卡片需求变更.md` | `report.upload.linked-products` / `report.upload.member-4col` | SC-T-11（同页面主题） | TC-T-11* 实为「成长计划」，语义错位 | ⚠️ 需先裁决编号重排再派生 |
| R5 | `2026-11-07-商城价格排序需求变更.md` | `shop.price.sort` | SC-G-05 · SC-C-22 · SC-X-07 | TC-G-05* / C-22* / X-07* | ⚠️ 排序栏、价格列白名单、body 数组契约均无断言 |
| R6 | `2026-11-07-财富中心贡献榜管理员口径需求变更.md` | `family.earnings.admin.role` / `family.earnings.pool.toggle` | **SC-A-24** | TC-A-24 / TC-A-24-E / TC-A-24-P | ✅ 2026-11-12 测试侧派生三流用例（admin.md SC-A-24 专项） |
| R7 | `2026-11-08-手签名横屏适配需求变更.md` | `signature.landscape.layout` | ❌ 无（SC-G-11 为隐私政策，假阳性） | 无 | ❌ 未入场景池；**v1.0 已被 R8 取代，不单独派生** |
| R8 | `2026-11-09-手签名实现方式重写需求变更.md` | `signature.canvas2d.rewrite` | **SC-X-22** | TC-SIG2D-01~08 / TC-SIG2D-01-E / TC-SIG2D-02-E | ✅ 2026-11-12 测试侧派生三流用例（signature.md） |

**汇总**：8 份变更中 R1 完成三流闭环；R3/R6/R8 已于 2026-11-12 由测试侧派生 SC（A-23/A-24/X-22）+ 三流 TC 闭环（G-1 需求侧缺口关闭）；R2/R4/R5 有主题相近 SC 但变更点未派生用例（待派生）；R7 为已废弃版本。**实际待闭环为 3 份（R2/R4/R5）**。

> ⚠️ 纠偏：上一轮「6 份需求变更在场景库中无对应主题」是窄关键词误判。实测 7 份中 5 份能找到主题相近 SC，但其中大部分为**语义假阳性**（家庭邀请 ≠ 推广收益、隐私政策 ≠ 手签名）；真实「未入场景池」为 4 份。结论方向不变，依据更准确。

---

## 3. 本次补写的 15 条用例

| 场景 | 正常流 | 异常流（具体故障注入） | 权限流（具体越权对象） | 落点 |
|---|---|---|---|---|
| SC-P-94 历史完成任务 | TC-P-94 | TC-P-94-E | TC-P-94-P | `tests/test-cases/parent.md`「成就与成长历史专项」 |
| SC-P-95 成长历史记录 | TC-P-95 | TC-P-95-E | TC-P-95-P | 同上 |
| SC-P-96 我的成就五列 | TC-P-96 | TC-P-96-E | TC-P-96-P | 同上 |
| SC-C-26 睡眠打卡配置驱动 | TC-C-26 | TC-C-26-E | TC-C-26-P | `tests/test-cases/child.md`「睡眠打卡配置驱动专项」 |
| SC-A-27 后台维护睡眠选项 | TC-A-27-S | TC-A-27-S-E | TC-A-27-S-P | `tests/test-cases/admin.md`「睡眠情况选项后台维护专项」 |

编写原则：异常流为**具体故障注入 + 可判定断言**（非法分页、单源超时、两源重复 ID、非法 JSON、并发重复提交、配置空列表等），不使用「系统给出明确错误提示而非 500」模板文案；权限流**针对具体越权对象**（F9 家庭成员 `memberId`、孩子直调后台 `save`、非 admin 改配置），不复用「统一 403/401」模板。未在需求或接口参考中明确的接口路径一律标「需核实」，未臆造 API。

---

## 4. SC → TC 三层覆盖明细

### L1 编号层：244/244 三流齐全 ✅

### L2 语义层：150 对齐 / 51 编号错位 / 40 格式差异 ⚠️

**（a）51 个编号错位**（TC 的「所属场景」列指向另一编号，呈整体偏移，系历史用例编号未随场景重排同步）：

| 角色 | 数量 | 明细（SC → 所属场景列） |
|---|---|---|
| A 运营 | 21 | SC-A-02→A-1, A-03→A-2, A-04→A-2, A-05→A-2, A-06→A-2, A-07→A-2, A-08→A-3, A-09→A-3, A-10→A-4, A-11→A-4, A-12→A-4, A-13→A-5, A-14→A-6, A-15→A-6, A-16→A-7, A-17→A-16, A-18→A-17, A-19→A-18, A-20→A-19, A-21→A-20, A-22→A-21 |
| P 家长 | 16 | SC-P-03→P-2, P-04→P-2, P-05→P-4, P-06→P-4, P-07→P-5, P-08→P-6, P-09→P-7, P-10→P-8, P-11→P-8, P-12→P-9, P-13→P-10, P-14→P-10, P-15→P-3, P-16→P-10, P-17→P-12, P-18→P-11 |
| C 孩子 | 5 | SC-C-05→C-4, C-06→C-5, C-07→C-6, C-08→C-7, C-09→C-8 |
| T 规划师 | 9 | SC-T-04→T-3, T-05→T-4, T-06→T-4, T-07→T-5, T-08→T-5, T-09→T-6, T-10→T-7, T-11→T-8, T-12→T-8 |

典型实证：`TC-A-17*` 三流内容为「团队分润/提现审核（S-cfc-68）」而 SC-A-17 是「优惠券/活动配置管理」；`TC-T-11*` 为「成长计划列表」而 SC-T-11 是「DAN 报告上传与解析」；`TC-X-07*` 为「全局统计」而 SC-X-07 是「商城履约闭环」。

**（b）40 个「所属场景」列非编号**（格式差异，语义对齐需人工核实，不判定为错误）：SC-B-01/02/04~07/09~12（10 个，9 列格式）、SC-H-01~07（7 个，9 列格式）、SC-X-01~22（22 个，9 列格式）、SC-A-27（1 个，写的是能力键 `S-cfc-68`）。

**（c）主题词粗筛**：143/241 个 SC 的标题核心词未出现在对应三流 TC 正文中。**该指标为粗筛线索，不作结论**（标题词与用例用词常不同，如「管理端登录」vs 用例写「登录」），需逐份人工核实。

### L3 执行层：15/241（6.2%）❌

`sc-key-map.md` 跑通状态列精确取值：已跑通 15（10 个「2026-11-07 收口」+ 5 个「2026-11-06 O-3 收口」）、**未跑通 226**。按 `DEV_GOAL_user_scenarios.md` 判据，「跑通」需三类流实际执行证据 + 推 `origin/cfclub` + 工作区干净；`automation-status.md` 亦显示结构化用例仅 14 条通过、638 条待自动化。

> **2026-11-10 execute 档补充**：本轮真实执行 42 个用例（30 passed / 3 failed / 9 skipped），其中 **SC-P-94 / SC-P-95 共 6 条三类流断言全部通过**，本地执行证据已产生。但因未推远端、工作区不干净，**不更新 `sc-key-map.md` 状态列**，L3 仍为 15/241。完整记录见 §9 与 `docs/tdd/test/execution-evidence-2026-11-10.md`。

---

## 5. 需求侧反向引用（双向的另一半）

| 文档集 | 份数 | SC 回链 | TC 回链 |
|---|---|---|---|
| `docs/需求分析/` | 14 | 9（64.3%） | 8（57.1%） |
| `docs/superpowers/specs/` | 200 | 10（5.0%） | 1（0.5%） |
| **合计** | **214** | **19（8.9%）** | **9（4.2%）** |
| 其中 11 月需求变更 | 8 | 9 | 8 |

8 份 11 月变更均已追加「附录 · 场景与用例回链」，**状态声明覆盖 8/8**；其中 6 份能锚定具体 SC 编号、5 份能锚定具体 TC 编号，其余因「未入场景池」如实标为待派生——**不硬塞编号制造 100% 回链假象**。200 份 specs 未动，仍是最大反向追溯空洞。

---

## 6. 缺口清单与闭环标准

| ID | 缺口 | 证据 | 建议动作 | 通过标准 |
|---|---|---|---|---|
| G-1 | 需求侧缺口，现余 3 份（R2/R4/R5）变更点未派生用例 | §2 | R3/R6/R8 已于 2026-11-12 由测试侧派生 SC（A-23/A-24/X-22）+ 三流 TC 闭环；R2/R4/R5 待在既有 SC 派生变更分支用例 | 每份变更均有 SC 回链 + 三流 TC，且断言覆盖变更点 |
| G-2 | 51 个编号语义错位 + 1 个编号占用（SC-A-27） | §4（a） | 用户已裁决**彻底重排 51 个历史 TC 编号**（按内容归组 + 子编号防重，进行中）；本轮初曾用 `TC-A-27-S*` 绕过 SC-A-27 占用 | 244 个 SC 的 TC「所属场景」列与 SC 编号一致率 100% |
| G-3 | 200 份 specs 几乎无反向追溯 | §5 | 设计文档模板加「关联 SC / TC」必填字段 | specs SC 回链率 ≥95% |
| G-4 | 226 个 SC 无三类流执行证据 | §4 L3 | execute 档逐场景补实际通过证据并推远端、接入 CI | 241/241 三类流实测通过 + `git merge-base --is-ancestor` 核验 + 工作区 clean |
| G-5 | 权限流模板化（约 21%） | 上轮实测：238 条权限流仅 208 种唯一正文 | 按场景改写为具体越权对象/接口/数据断言（本次新增 5 条已按此规范编写） | 权限流唯一正文 ≥95% |
| G-6 | 四套台账数字矛盾 | `SRS.md` / `README.md` / `inventory.md` / 总览 | 以本矩阵编号级扫描为单一事实源重生成台账 | 各台账数值一致且与扫描误差为 0 |
| G-7 | 睡眠配置与成长档案契约未落地 | 证据台账 §1 / §4：`/api/health/sleep/tags` 404、`/api/admin/sleep/tags` 404、`/api/config/public/value` 500、`/api/growth/record/list` 500 | 确认实现真实路径（疑为 `/api/admin/config/*`）并补齐读取/维护接口；造跨家庭数据夹具后复核权限口径 | 4 个 `fixme` 全部转正常用例并通过；权限契约与 TC-P-94-P / TC-P-95-P 文档断言一致 |
| G-8 | 回归基线 3 个失败 | `nonfunc-perf-compat.spec.js:92`（并发串数据）、`nonfunc-security.spec.js:77 / :131` | 按证据台账 §4 第 4~6 项修实现或对齐契约 | 3 条用例通过 |
| G-9 | 本地执行证据未入册 | 证据台账 §5：未推 `origin/cfclub`、未 clean-check | 单独授权后执行 git 提交/推送与 mark-green 流程 | `git merge-base --is-ancestor` 核验 + clean-check 0 + SC-P-94/95 状态列更新 |

---

## 7. 校验方法（可复跑）

在 `d:/cfc` 下执行以下只读脚本，重算 L1 / L2 / 需求回链：

```python
import re, glob, collections
rd = lambda p: open(p, encoding='utf-8', errors='replace').read()
km = set(re.findall(r'\|\s*(SC-[A-Z]+-\d+)\s*\|', rd('docs/tdd/orchestration/sc-key-map.md')))
tc = set()
for f in glob.glob('tests/test-cases/*.md'):
    tc |= set(re.findall(r'^\|\s*(TC-[^\s|]+)\s*\|', rd(f), re.M))
full = sum(1 for s in km if all(k in tc for k in
           (s.replace('SC-','TC-'), s.replace('SC-','TC-')+'-E', s.replace('SC-','TC-')+'-P')))
print(f'L1 三流齐全 {full}/{len(km)} | 唯一 TC {len(tc)}')
req = glob.glob('docs/需求分析/*.md') + glob.glob('docs/superpowers/specs/*.md')
print('SC回链', sum(1 for f in req if re.search(r'\bSC-[A-Z]+-\d+', rd(f))), '/', len(req))
print('TC回链', sum(1 for f in req if re.search(r'\bTC-[A-Z]+-', rd(f))), '/', len(req))
```

L2 语义层需比对 TC「所属场景」列（归一 `SC-?([A-Z]+)-0*(\d+)`）与 SC 编号；L3 执行层需读 `sc-key-map.md` 跑通状态列**按列索引精确取值**——⚠️ 不可用子串 `跑通` 匹配（会命中「未跑通」，历史教训 LES-002）。

---

## 8. 边界声明

- 本轮**只写测试资产与文档**（`tests/`、`docs/需求分析/` 附录、`docs/tdd/test/` 证据台账），未修改任何生产源码、**未提交、未推送、未执行任何 git 写操作**。
- execute 档仅访问内网 `192.168.16.251`，**未访问外部公网**；未安装依赖（Playwright 1.63.0 与 chromium 本已就绪）；凭据由既有 `direct-register` 自注册取得，未硬编码、未打印 token/口令/手机号；未重置远程数据库、未写业务数据。
- **未实测项一律标注，绝不伪造执行证据或远端 sha**；`fixme` / `skip` 不计为通过。
- 未在需求/接口参考中明确的接口路径、聚合口径、登录态均标「需核实」，未臆造。
- 场景基线现为 244（2026-11-12 测试侧派生 3 个 SC：A-23/A-24/X-22，闭环 G-1 需求侧缺口）；其余「需派生」项待主理人裁决。

---

## 9. execute 档执行证据（2026-11-10）

> 完整记录：`docs/tdd/test/execution-evidence-2026-11-10.md` · 新增规格：`tests/e2e/api/traceability-p94-p95-c26.spec.js`

| 命令（`cd d:/cfc/tests`） | 结果 |
|---|---|
| `npx playwright test e2e/api/api-smoke.spec.js -c playwright.config.api.js --project=desktop` | 4 passed（链路自检） |
| `npx playwright test e2e/api/traceability-p94-p95-c26.spec.js -c playwright.config.api.js --project=desktop` | **6 passed / 4 skipped** |
| `npx playwright test e2e/api/{api-smoke,nonfunc-security,nonfunc-perf-compat,butler-fallback,human-butler-workorder}.spec.js -c playwright.config.api.js --project=desktop` | 24 passed / 3 failed / 5 skipped |

去重合计 **42 个用例：30 passed / 3 failed / 9 skipped**。SC-P-94 / SC-P-95 三类流 6 条全部真实通过；SC-C-26 / SC-A-27 / SC-P-96 因配置接口 404/500 与远程无前端 SPA 未实测，登记为 4 个 `fixme`。因缺「推 `origin/cfclub` + 工作区干净」两项判据，**本轮不更新 `sc-key-map.md` 跑通状态列**（仍 15/241），需单独授权 git 流程后入册（G-9）。

---

## 10. R170 锚点双向核对（2026-11-12，实测口径）

> **目的**：回答「用例台账 ↔ 可执行测试资产」是否**双向**一致。历轮只报单向（台账 TC 有多少被执行锚点覆盖），
> 导致「**执行了但台账没登记**」的孤儿锚点长期不可见。本轮首次做双向差集。

> 扫描范围：`cfc-backend/src/test/**/*.java`、`cfc-frontend/__tests__`、`cfc-web/src/__tests__`、
> `tests/e2e-live`、`tests/e2e`（排除 `tests/e2e/api/generated`）、`cfc-langgraph/tests`；台账 `tests/test-cases/*.md`。

| 指标 | 数值 | 说明 |
|---|---|---|
| 台账唯一 TC 编号 | **367** | `tests/test-cases/*.md` 表首列 |
| 可执行锚点唯一编号 | **161** | 测试源码中出现的 `TC-xxx` 字面 |
| 双向命中 | **76** | 台账 ∩ 锚点 |
| **孤儿锚点（执行有、台账无）** | **85** | 锚点 − 台账 → 追溯断链，见 §10.1 |
| 台账无锚点（有编号、无执行） | **291** | 台账 − 锚点，见 §10.2 分组 |
| 严格锚点覆盖率 | **76/367 = 20.7%** | G9 口径（排除 generated 虚高） |
| 锚点可追溯率 | **76/161 = 47.2%** | 新增反向指标 G9-b |

### 10.1 孤儿锚点清单（85 个，按前缀分组）

| 前缀组 | 数量 | 编号 | 归属 |
|---|---|---|---|
| `TC-A-U*` | 6 | `TC-A-U01` `TC-A-U02` `TC-A-U03` `TC-A-U04` `TC-A-U05` `TC-A-U06` | `tests/e2e-live/admin-live.spec.js`（管理端 UI 5+1 例） |
| `TC-A5*` | 5 | `TC-A5-01` `TC-A5-02` `TC-A5-03` `TC-A5-04` `TC-A5-05` | 后端/前端 UI 五维相关用例 |
| `TC-C10*` | 6 | `TC-C10-01` `TC-C10-02` `TC-C10-03` `TC-C10-04` `TC-C10-05` `TC-C10-06` | 历史编号段（未回填台账） |
| `TC-C16*` | 5 | `TC-C16-01` `TC-C16-02` `TC-C16-03` `TC-C16-04` `TC-C16-05` | 历史编号段（未回填台账） |
| `TC-DX-U*` | 2 | `TC-DX-U01` `TC-DX-U02` | `tests/e2e-live/dx-health-bridge-auth.spec.js`（D/X 桥接 2 例，404 跳过） |
| `TC-F-G*` | 1 | `TC-F-G01` | `tests/e2e-live/frontend-live.spec.js`（游客态 1 例） |
| `TC-F-U*` | 6 | `TC-F-U01` `TC-F-U02` `TC-F-U03` `TC-F-U04` `TC-F-U05` `TC-F-U06` | `tests/e2e-live/frontend-live.spec.js`（小程序 H5 6 例） |
| `TC-FA*` | 7 | `TC-FA-18` `TC-FA-19` `TC-FA-20` `TC-FA-21` `TC-FA-22` `TC-FA-23` `TC-FA-24` | 前端签到/家庭相关 Jest |
| `TC-GA-M*` | 5 | `TC-GA-M01` `TC-GA-M02` `TC-GA-M03` `TC-GA-M04` `TC-GA-M05` | 成长档案 M 类 |
| `TC-GA-P*` | 5 | `TC-GA-P01` `TC-GA-P02` `TC-GA-P03` `TC-GA-P04` `TC-GA-P05` | 成长档案 P 类 |
| `TC-GRID*` | 4 | `TC-GRID-01` `TC-GRID-02` `TC-GRID-03` `TC-GRID-04` | 五维沙盘 grid 用例 |
| `TC-H-U*` | 9 | `TC-H-U02` `TC-H-U03` `TC-H-U04` `TC-H-U05` `TC-H-U06` `TC-H-U07` `TC-H-U08` `TC-H-U09` `TC-H-U10` | `tests/e2e-live/health-contract.spec.js`（健康 9 例） |
| `TC-HP-U*` | 3 | `TC-HP-U01` `TC-HP-U02` `TC-HP-U03` | `tests/e2e-live/health-contract.spec.js`（健康方案 3 例） |
| `TC-LANDSCAPE*` | 8 | `TC-LANDSCAPE-01` `TC-LANDSCAPE-02` `TC-LANDSCAPE-03` `TC-LANDSCAPE-04` `TC-LANDSCAPE-05` `TC-LANDSCAPE-06` `TC-LANDSCAPE-07` `TC-LANDSCAPE-08` | 横屏/布局兼容用例 |
| `TC-MG-U*` | 6 | `TC-MG-U02` `TC-MG-U03` `TC-MG-U04` `TC-MG-U05` `TC-MG-U06` `TC-MG-U07` | `cfc-frontend/__tests__/utils/membershipGate.test.js`（会员门控 6 例） |
| `TC-S-U*` | 4 | `TC-S-U01` `TC-S-U02` `TC-S-U03` `TC-S-U04` | `tests/e2e-live/shop-sort-api.spec.js`（商城排序 4 例） |
| `TC-SIG*` | 3 | `TC-SIG-02` `TC-SIG-03` `TC-SIG-04` | 电子签名相关用例 |

**根因（P1 治理）**：可执行资产使用 **`TC-<域>-U<NN>`（UI/用户态）** 与 **`TC-<域>-<语义标签>-<NN>`** 两套命名，
台账只登记 `TC-<域>-<NN>` 单套 → 凡走 UI/契约命名的用例全部落不到台账。这不是 85 个孤立缺漏，而是**命名规范未双向对齐**。

### 10.2 台账无锚点（291 个）前缀分布

| 前缀 | 无锚点数 | 风险等级 |
|---|---|---|
| `TC-P-*` | 93 | 中（平台/后台流程，多为 Web 管理端未自动化） |
| `TC-T-*` | 39 | 高（团队/分销域，无执行证据） |
| `TC-X-*` | 35 | 中 |
| `TC-A-*` | 33 | 低（同域 U 系列已在执行，编号体系不同） |
| `TC-C-*` | 27 | 中 |
| `TC-S-*` | 17 | 低（U 系列已覆盖排序契约） |
| `TC-HB-*` | 16 | 低（桥接 16 例由契约测试覆盖，编号不同） |
| `TC-B-*` | 11 | 中 |
| `TC-H-*` | 6 | 低 |
| `TC-PA-*` | 6 | 中 |
| `TC-DV-*` | 4 | 中 |
| `TC-G-*` | 2 | 中 |
| `TC-SIG2D-*` | 2 | 中（二维签名相关，无执行锚点） |

### 10.3 建议动作

1. **（测试侧，本轮可执行）** 在台账新增「锚点别名列」，把 §10.1 的 85 个孤儿按语义挂到既有 TC 编号，或为其补 `TC-<域>-<NN>` 正式编号 → 把锚点覆盖率从 20.7% 抬到 47.2% 量级。
2. **（测试侧）** 对 §10.2 的 `TC-T-*`（39）、`TC-X-*`（35）补执行锚点，属最高风险空转区。
3. **（研发侧）** 新写测试必须带台账编号，CI 增一条「新增 `TC-` 字面必须能在台账命中」的静态断言（与 B-152 双向差集同源）。