@chenguangyao/devflow-kit 0.1.43

package/skills/test-spec/SKILL.md

@@ -0,0 +1,219 @@
+---
+name: devflow-test-spec
+description: |
+  devflow-kit test-spec 阶段基于 `requirement.md`(F-ID + AC)和 `design.md`(改动点 / 契约 / 异常路径)产出
+  `tests.md` —— 独立于代码的测试用例清单。下游 `plan.md` 把这些用例映射到 TDD 任务
+  (写失败测试 → 实现通过)。触发时机:`devflow design --with-tests` 或 `/df:test-spec`。
+  L1/L2 可把测试写进 plan.md,不强制单独出 tests.md;L3 或复杂跨系统验收建议单独生成。
+when_to_use: |
+  tech-spec 完成后、plan 之前，且用户/方案明确需要独立测试用例文档时。test-spec 不写具体测试代码,只写"要测什么 + 前置 / 步骤 /
+  期望 + 对应 F-ID"。
+---
+
+# test-spec
+
+test-spec 的目的是**把测试的意图从代码实现中分离出来**。意图稳定,实现可以换(框架 / 语言 / 断言风格),只要用例还在就不会漏测。
+
+## 前置检查
+
+| 输入 | 必需 | 缺失时 |
+| --- | --- | --- |
+| `requirement.md`(有 F-ID + AC) | 是 | 回退到 requirement-analysis |
+| `design.md`(§5 契约、§7 关键流程、§8 异常处理) | 是 | 回退到 tech-spec |
+| `state.level` | 是 | 用于决定最小覆盖要求 |
+
+## 产物
+
+`devflow/changes/<slug>/tests.md`,含:
+
+| # | Section | 必选 |
+| --- | --- | --- |
+| 1 | 测试策略(金字塔比例、工具) | 是 |
+| 2 | 数据准备(fixtures、种子) | 是 |
+| 3 | 环境依赖(mock 哪些、stub 哪些) | 是 |
+| 4 | 测试用例索引表(TC-001..) | 是 |
+| 5 | 逐用例详表(type / pre / steps / expected / F-ID) | 是 |
+| 6 | 非功能测试(perf / security 若适用) | L2/L3 |
+| 7 | 回归清单(本次变更可能影响的已有用例) | L2/L3 |
+
+完整模板 + 用例详表字段、正反例见 [`references/test-case-template.md`](references/test-case-template.md)。
+
+## 产物格式规范（对齐 arb 测试用例.md）
+
+```markdown
+# 测试用例：<标题>
+
+> JIRA/URL: <引用>
+
+---
+
+## TC-F1：<F1 功能名>
+
+| 编号 | 场景 | 前置条件 | 操作 | 预期结果 |
+|------|------|---------|------|---------|
+| TC-F1-01 | 正向：<场景描述> | <系统状态 + 数据> | <HTTP 方法 + 路径 + 参数> | <状态码 + body 断言> |
+| TC-F1-02 | 边界：<场景描述> | ... | ... | ... |
+| TC-F1-03 | 异常：<场景描述> | ... | ... | ... |
+
+---
+
+## TC-F2：<F2 功能名>
+
+| 编号 | 场景 | 前置条件 | 操作 | 预期结果 |
+|------|------|---------|------|---------|
+| TC-F2-01 | ... | ... | ... | ... |
+
+---
+
+## TC-C1：<C1 技术变更（如无对应 F-ID 的底层变更）>
+
+| 编号 | 场景 | 前置条件 | 操作 | 预期结果 |
+|------|------|---------|------|---------|
+| TC-C1-01 | ... | ... | ... | ... |
+```
+
+**格式说明：**
+- 按 **F-ID 分节**（每个功能点一个 `## TC-F{n}` 节），而不是全局顺序编号
+- 编号格式：`TC-F{功能号}-{序号}`（如 `TC-F2-01`）；纯技术变更用 `TC-C{号}-{序号}`
+- 表格列：**编号 | 场景 | 前置条件 | 操作 | 预期结果** — 每行一个用例，紧凑可读
+- 每个 F-ID 节至少 3 行：正向 / 边界 / 异常（L2/L3 要求）
+
+## 用例编号与映射
+
+- 编号按功能分节：`TC-F{n}-{seq}`（如 `TC-F2-01`，F 对应 requirement 的 F-ID）
+- 每个 TC 必须能对应到 design.md 的一条流程（happy 或 failure path）
+- 若测非功能需求，用 `TC-NFR-{domain}-{seq}`（如 `TC-NFR-perf-01`）
+
+**硬闸**：F-ID 未覆盖的 → test-spec 回退 requirement / design 看是不是少写了 AC
+
+## 测试金字塔(强制分层)
+
+```
+        /\
+       /  \       e2e        5%   (少量,纯粹端到端)
+      /----\
+     /      \     integration  20-30%   (服务与 DB / 外部系统)
+    /--------\
+   /          \   unit       65-75%   (纯函数 / 单类,快、确定、无 IO)
+  /------------\
+```
+
+**原则**:
+
+- **Unit** 是主战场,覆盖业务逻辑分支
+- **Integration** 覆盖"代码 + 依赖"一层(DB / MQ / 外部 API mock)
+- **e2e** 保留最关键的用户场景,不求 coverage;慢、脆、贵
+
+按层的覆盖策略见 [`references/coverage-strategy.md`](references/coverage-strategy.md)。
+
+## F-ID → TC 的映射规则
+
+| 每个 F-ID 至少覆盖 | L1 | L2 | L3 |
+| --- | --- | --- | --- |
+| 1 个正向 TC | ✓ | ✓ | ✓ |
+| 1 个边界 TC(引用 requirement.md §8 的一行) | — | ✓ | ✓ |
+| 1 个异常 TC(引用 design.md §8 一个错误路径) | — | ✓ | ✓ |
+| 1 个性能 / 可观测性 TC(NFR) | — | — | ✓ |
+
+若一个 F-ID 无法满足 ≥ 2 个 TC(L2/L3),说明 AC 写得太粗,回退 requirement 拆。
+
+F-ID → TC 映射完整决策树与例子库见 [`references/edge-case-to-test.md`](references/edge-case-to-test.md)。
+
+## 每个用例要包含什么
+
+```
+TC-001
+  type:          unit | integration | e2e
+  linkedF:       F-01 (+ 可多个)
+  priority:      P0 | P1 | P2        (P0 = 必过;P1 = 应过;P2 = 最好过)
+  preconditions: <fixture / 系统状态>
+  steps:         1. ... 2. ... 3. ...
+  expected:      <可自动化断言的期望>
+  dataSource:    <fixture 文件或数据生成规则>
+  notes:         <如 flaky / skip 原因>
+```
+
+**关键**:每个字段都要能**机器解析**。step 和 expected 用编号列表 + 断言级别描述,不要用散文。
+
+## 不写具体代码
+
+test-spec 是**意图文档**,不是"单测代码草稿"。不要出现:
+
+- `assertEquals(...)` / `expect(...).toBe(...)` 这种具体框架语法
+- `new UserMapper()` 这种具体类名(除非用例要求验证该类)
+- 具体参数结构(参数结构由 design.md §5 契约规定)
+
+正确:`expected: 响应 200, body.grantedCount === 990, body.failedUsers.length === 10`。
+
+## 测试数据(§2)
+
+统一安排 fixture,而不是散在各用例里。常见来源:
+
+| 来源 | 适用 |
+| --- | --- |
+| 固定 json/yaml fixture 文件 | 多 case 共享、schema 稳定 |
+| Factory 工厂 | 需要少量差异、可组合 |
+| 随机 / 属性测试 | 幂等 / 纯函数 / 边界扫描 |
+| 生产导出样本(脱敏) | 真实 workload 回归 |
+
+数据准备原则:**不能依赖执行顺序、不能污染别的 case**(每 case 要能独立跑、可重复)。
+
+## 非功能测试(§6,L3 必有)
+
+| 域 | 测什么 | 工具 |
+| --- | --- | --- |
+| Performance | 接口延迟 / 吞吐;对照基线 | JMeter / k6 / Gatling / wrk |
+| Security | 鉴权 / 越权 / 敏感数据泄漏 | 漏扫 / 手工 / OWASP ZAP |
+| Reliability | 故障注入 / 降级 | Chaos / toxy-proxy |
+| Observability | 指标 / 日志 / traceId 透传 | 观测断言 |
+
+非功能 TC 也要有编号,如 `NFR-PERF-001`。
+
+## 硬闸(Done Criteria)
+
+进入 `devflow plan` 前:
+
+- [ ] 每个 F-ID 至少有对应的 TC(数量达到 level 要求)
+- [ ] 每个"对外契约变更"有 contract / integration TC
+- [ ] 每个"契约消费者影响矩阵"条目都有 consumer / frontend / e2e 或 integration TC，覆盖无参数回跳、老链接兼容、轮询 key 来源、页面刷新 / 直达等场景
+- [ ] 每条 design.md §8 的 failure path 有对应 negative TC
+- [ ] §2 数据准备 / §3 环境依赖写了(不能"apply 时再说")
+- [ ] L3:有至少 1 个 perf TC
+
+未达标 → 继续写;都达标 → DONE → `devflow plan`。
+
+## 反模式
+
+- **只测 happy path**:边界和异常的 bug 占 bug 池的 60%+。少写 = 交付后补 bug。
+- **"断言不抛异常"**:assertDoesNotThrow 是零信息断言。改写具体期望(业务字段 / 响应状态 / 副作用)。
+- **一个用例断言一大堆**:一个 TC 断言 ≤ 5 条;超过拆。
+- **TC 没有 F-ID**:无法验证覆盖率,下游 review 时无法追溯。
+- **测试数据用生产环境真实数据**(含 PII):合规违规;用脱敏或 factory。
+- **依赖执行顺序**:TC-002 必须在 TC-001 后跑 → case 间无关性丧失。
+- **把具体实现类名写进 tests.md**:实现改了测试意图文档也要改,耦合。
+- **把测试框架语法塞进 tests.md**:tests.md 应是语言无关的,切框架不要动它。
+- **不考虑并发 / 重复调用**:特别是幂等接口。
+- **忽略 L3 的 perf TC**:L3 没 perf 等于裸奔。
+
+## 完成状态协议
+
+```
+---STATUS---
+result: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_INPUT
+outputs:
+  - devflow/changes/<slug>/tests.md
+testCaseCount:
+  unit: N1
+  integration: N2
+  e2e: N3
+  nfr: N4
+fIdCoverage: K/K        # K 个 F-ID 中全部覆盖
+nextAction: devflow plan
+---END_STATUS---
+```
+
+## 参考
+
+- [`references/test-case-template.md`](references/test-case-template.md) — tests.md 完整模板 + 用例详表字段 + 正反例 + L2 完整示例
+- [`references/coverage-strategy.md`](references/coverage-strategy.md) — 金字塔分层的具体分配、分层时机、覆盖率目标、什么不值得测
+- [`references/edge-case-to-test.md`](references/edge-case-to-test.md) — requirement §8 边界场景 → TC 的映射决策树 + 例子库

package/skills/test-spec/references/coverage-strategy.md

@@ -0,0 +1,218 @@
+# test-spec / coverage-strategy
+
+测试金字塔的分层原则、每层覆盖什么、覆盖率目标、什么不值得测。
+
+---
+
+## 金字塔原则(再一次强调)
+
+```
+ /\         e2e            5%        昂贵、脆弱、慢。覆盖最关键用户路径
+/  \  
+----  
+    \       integration   20-30%    代码 + 依赖(DB/MQ/mock 外部 API)
+------  
+        \   unit          65-75%    纯逻辑、分支覆盖主战场
+----------
+```
+
+**错误分布**(工业经验):
+
+- 60-70% 的 bug 可以用 unit 覆盖
+- 20-25% 需要 integration
+- 5-10% 需要 e2e
+
+**预算分布**:
+
+- 80% 测试时间应花在 unit(写得快、跑得快、修得快)
+- 15% 在 integration
+- 5% 在 e2e
+
+---
+
+## 每层测什么
+
+### Unit 层
+
+**测**:
+
+- 纯函数(输入 → 输出),所有分支
+- 单类(controller / service / mapper 单独实例化,依赖全 mock)
+- 边界 / 异常 / 极值 / 幂等
+- 工具类、helper、validator
+
+**不测**:
+
+- 实际 DB 访问(那是 integration)
+- 外部 HTTP 调用(那是 integration)
+- UI 交互 / e2e 流程
+
+**对象 / 依赖处理**:
+
+- 依赖全部 mock / stub(显式声明行为)
+- 不用真实 Spring context;用构造注入 + mock
+- 单个 test < 100ms
+
+---
+
+### Integration 层
+
+**测**:
+
+- 服务 + DB:SQL 正确、约束生效、事务边界、索引起作用
+- 服务 + MQ:消息生产 / 消费、重试、死信
+- 服务 + 外部 API:mock 服务器模拟成功 / 失败 / 超时
+- 整条 Controller → Service → Repository 链路
+
+**工具**:
+
+| 语言 | 工具 |
+| --- | --- |
+| Java | Spring Boot Test、@SpringBootTest + Testcontainers MySQL |
+| Go | testify + dockertest / testcontainers-go |
+| Python | pytest + pytest-docker |
+| Node | supertest + testcontainers-node |
+
+**不测**:
+
+- 跨服务(那是 e2e)
+- UI(那是 e2e)
+
+---
+
+### E2E 层
+
+**测**(少量,慎选):
+
+- 核心用户路径("下单 → 支付 → 到货")
+- 关键冒烟场景("启动服务能访问首页")
+- 跨服务关键交互("下单扣库存扣余额" 端到端)
+
+**不测**:
+
+- 所有 F-ID(那是 unit/integration 的工作)
+- 大多数边界 / 异常(太慢太脆)
+- 性能(那是 perf 独立层)
+
+**设计原则**:
+
+- 每个 e2e < 30 秒;超过要审视
+- 尽量少 mock,尽量真实环境
+- 有**稳定的 teardown**(清数据、关连接)
+- 失败时有**清晰的错误截图 / 日志**(方便 debug,e2e 失败往往比 unit 难 debug)
+
+---
+
+## 覆盖率目标
+
+| 指标 | 底线 | 目标 | 说明 |
+| --- | --- | --- | --- |
+| line coverage | 70% | 80% | 整体;业务核心类 ≥ 90% |
+| branch coverage | 60% | 75% | 更重要;分支没覆盖比行没覆盖更危险 |
+| 核心业务 service | 85% | 95% | 钱 / 券 / 订单 / 库存 等 |
+| controller | 70% | 85% | 主要校验参数和返回 |
+| DAO / Mapper | 30% | 50% | 主要 SQL 正确性,低覆盖容忍(integration 补) |
+| 工具 / helper | 90% | 100% | 纯函数易测 |
+| config / DTO | 忽略 | 忽略 | 无逻辑 |
+
+**警告**:追求 100% coverage 会产出"无断言 test"(`@Test public void test() { new Foo().bar(); }`),危害大于收益。目标是**分支充分**,不是行充分。
+
+---
+
+## 什么不值得测
+
+| 内容 | 为什么不值得 |
+| --- | --- |
+| Getter / Setter | 没逻辑,测等于没测 |
+| 纯转发(Controller 只调 Service 无参) | integration 覆盖即可 |
+| Spring / ORM 框架本身 | 第三方职责 |
+| 本地日志格式 | 过度约束,日志格式变动常见 |
+| Config loading(读 yaml) | 框架职责 |
+| 显而易见的 null 安全("传 null 不 NPE" 类用例堆砌) | 一两个代表即可 |
+| 每个 exception 类的构造 | 1 条冒烟即可 |
+
+**优先级**:先测**业务逻辑 + 边界 + 异常**,再测架构粘合,最后考虑 utility。
+
+---
+
+## 测试的独立性(必须)
+
+- **TC-002 必须能在 TC-001 失败时仍然跑通**(不依赖顺序)
+- **每个 case 自清理**(teardown / @AfterEach)
+- **共享数据用 @BeforeAll + immutable fixture**,不要让 case 修改它
+- **避免全局状态**(static 变量 / 线程局部 / 环境变量),非测必要不用
+
+---
+
+## 测试的快速与稳定
+
+### 慢测试的识别与治理
+
+- 单元测试 > 500ms 基本都是**写得不对**(有 sleep / 有 real IO)
+- integration 如果单个 > 5s,考虑分拆 + 并行
+- flaky 测试 **必须 quarantine 后立即修**,不能留在主干反复绿红
+
+### 并行化
+
+- unit 天然并行:框架自动支持
+- integration 按 test class 并行,注意 DB schema 隔离(每并行组不同 schema)
+- e2e 通常不并行(资源竞争太重)
+
+---
+
+## 回归测试
+
+每次 change 除了本次 new TC,还要**显式列出**受影响的已有 TC(tests.md §7 回归清单):
+
+- 改了 `GrantService` 的核心方法 → 列出所有 `GrantServiceTest.*` + `CouponControllerTest.*`
+- 加了索引 → 列出使用旧索引的查询 TC(性能可能变化)
+- 改了 DTO 字段 → 列出所有引用该 DTO 的序列化 TC
+
+**关键**:code-review 阶段会扫 §7 是否执行。没跑等于没做。
+
+---
+
+## 性能测试(L3 必有)
+
+### 基线
+
+每个需要 perf TC 的接口都应有一个**基线(baseline)**:
+
+- 当前版本的 P50 / P99 / QPS(上线前测过)
+- 新版本测试结果对照基线:**允许 ±5%**,超过要解释
+
+### 场景
+
+至少 3 种:
+
+- **典型负载**(日常平均 QPS)
+- **峰值负载**(预计最高 QPS)
+- **稳定性**(峰值 QPS 持续 ≥ 10 分钟 / 1 小时)
+
+### 断言
+
+- 吞吐量(QPS)≥ 目标
+- P99 ≤ SLA
+- Error rate < 0.1%
+- 无 Full GC > 200ms(JVM)
+- CPU / memory / DB 连接池无饱和
+
+---
+
+## 框架选型(按语言)
+
+| 语言 | unit | integration |
+| --- | --- | --- |
+| Java | JUnit 5 + Mockito + AssertJ | @SpringBootTest + Testcontainers |
+| Go | testing + testify | testify + dockertest / httptest |
+| Python | pytest + pytest-mock | pytest + pytest-docker / testcontainers-python |
+| Node | Jest / Vitest / Mocha | supertest + testcontainers-node |
+| Vue / Frontend | Vitest + @testing-library/vue | Playwright / Cypress(e2e) |
+
+更多语言习语见 `../code-review/references/language-cheatsheets/`。
+
+---
+
+## 本文与 SKILL.md 的关系
+
+SKILL.md 只提了金字塔分层和比例。本文给各层测什么 / 不测什么、覆盖率目标、什么不值得测、独立性、快速稳定、回归、性能、框架。test-spec 写 §1 测试策略时应对本文决策。

package/skills/test-spec/references/edge-case-to-test.md

@@ -0,0 +1,143 @@
+# test-spec / edge-case-to-test
+
+把 `requirement.md §8 边界与异常` 的每一行映射到具体 TC。这是 test-spec 最容易漏的动作。
+
+---
+
+## 映射规则
+
+`requirement.md §8` 的每一行 = 至少一个 TC。
+
+**映射决策树**:
+
+```
+§8 的一条边界场景
+    ↓
+Q: 是否可以在 unit 层验证?
+├─ 是(纯参数 / 内部逻辑) → unit TC
+└─ 否
+    ↓
+    Q: 是否需要真 DB / MQ / HTTP 才能验?
+    ├─ 是 → integration TC
+    └─ 否(需要跨服务 / UI) → e2e TC
+```
+
+---
+
+## 边界维度 → TC 骨架的例子库
+
+### 维度 1:空 / 零 / null
+
+| §8 场景 | TC 骨架 |
+| --- | --- |
+| 空 userIds → 400 EMPTY_BATCH | TC: unit, preconditions: userIds=[], expected: status=400,code=EMPTY_BATCH |
+| 必填字段 null → 400 | TC: unit, preconditions: {templateId: null}, expected: status=400, code=FIELD_REQUIRED:templateId |
+| 可选字段 null → 200(使用默认) | TC: unit, preconditions: {nickname: null}, expected: status=200,stored 值是默认值 |
+
+### 维度 2:极值
+
+| §8 场景 | TC 骨架 |
+| --- | --- |
+| 上限 +1 → 400 | TC: unit, preconditions: 1001 个 userIds, expected: 400 + details.limit/actual |
+| 下限 0 → 400 | 合并到空输入 |
+| 负数 | TC: unit, preconditions: {qty: -1}, expected: 400 FIELD_INVALID |
+| 超大 payload | TC: integration, preconditions: body > 1MB, expected: 413 |
+
+### 维度 3:重复 / 幂等
+
+| §8 场景 | TC 骨架 |
+| --- | --- |
+| 同 batchId 重复调 | TC: integration, steps: 1.调一次 2.同 batchId 再调, expected: 两次返回一致,DB 无重复 |
+| batch 内 userId 重复 | TC: unit, preconditions: userIds=[u1,u2,u1], expected: grantedCount=2(去重) |
+| 不同 requestId 但业务重复 | 看业务:是否幂等 → 若是则同上;若否 → 允许产生重复,TC 断言产生 2 条 log |
+
+### 维度 4:并发 / 竞态
+
+| §8 场景 | TC 骨架 |
+| --- | --- |
+| 库存扣减并发 | TC: integration, steps: 起 10 个并发线程各减 1, expected: 最终 qty 精确 = 初始 - 10 |
+| 乐观锁冲突 | TC: integration, preconditions: 读取 v=3, steps: 两个 session 同时更新, expected: 一个成功,另一个 409 VERSION_CONFLICT |
+| 分布式锁 | TC: integration, steps: 并发请求同 key, expected: 只一个进入临界区 |
+
+### 维度 5:部分失败
+
+| §8 场景 | TC 骨架 |
+| --- | --- |
+| 10/1000 命中风控 | TC: unit, mock RiskService 前 10 人 hit, expected: grantedCount=990, failedUsers.length=10 |
+| 下游 timeout | TC: integration, stub RiskService sleep 5s, expected: 相关用户 reason=TIMEOUT, 整体仍 200 |
+| 事务中途失败 | TC: integration, mock step3 抛异常, expected: step1/2 副作用已回滚 |
+
+### 维度 6:权限 / 越权
+
+| §8 场景 | TC 骨架 |
+| --- | --- |
+| 无 token | TC: integration, preconditions: no Authorization header, expected: 401 |
+| token 无此角色 | TC: integration, token 有角色 X 但无 Y, expected: 403 INSUFFICIENT_ROLE |
+| 越权访问 | TC: integration, user A token 访问 user B 资源, expected: 403(不 404,避免泄漏) |
+
+### 维度 7:时区 / 本地化
+
+| §8 场景 | TC 骨架 |
+| --- | --- |
+| 过期时间 UTC | TC: unit, set fixed time UTC, expected: 到期判定正确 |
+| emoji 存储 | TC: integration, 传 "👍 中文 en", expected: DB 读回一致 |
+| DST 跨越 | TC: unit, parameterized test on DST 前后的时间段, expected: 时长计算正确 |
+
+### 维度 8:依赖不可用
+
+| §8 场景 | TC 骨架 |
+| --- | --- |
+| DB 不可用 | TC: integration, stub DB 抛 connection error, expected: 503 + 指标 db.errors 上报 |
+| 缓存失效 | TC: integration, Redis down, expected: 降级直读 DB(性能指标标记 degraded) |
+| 下游 5xx | TC: integration, stub 返回 500, expected: 本接口 503(不透传) 或 200(降级,具体看设计) |
+
+---
+
+## 映射检查清单(完成后自检)
+
+- [ ] §8 的**每一行**是否都找到了对应的 TC?
+- [ ] 对应关系是否**双向可查**?(§8 某行对应 TC-N;TC-N 的 linkedF 里有对应 F-ID 和边界标注)
+- [ ] 每条 TC 的 expected 是否**具体到字段或状态**(不是"应该报错")?
+- [ ] §8 没提到但**想到的边界**,是否反向反馈到 requirement.md §8 补充?
+
+---
+
+## 反向检查:TC 多过 §8?
+
+有时候写 TC 会发现自己在测一个**§8 没列的场景**。这说明:
+
+- 要么 requirement 漏写了边界(回退 requirement 补)
+- 要么你在过度测试不重要的东西(删 TC 或标 P2)
+
+---
+
+## AC → TC 的对应(正向路径)
+
+不仅边界,每条 AC 都要有 TC。映射方式:
+
+| AC 类型 | TC 数量 |
+| --- | --- |
+| Given-When-Then 单条 AC | 1 个 TC(unit) |
+| AC 含"所有输入"("任何合法 userId") | 1 TC 正向 + 边界各场景的 TC |
+| AC 是性能要求 | 1 个 NFR-PERF-N TC |
+| AC 是可观测性要求 | 嵌入现有 TC 的 expected(断言指标上报) |
+
+---
+
+## F-ID 的 TC 完整度检查
+
+每个 F-ID 扫一遍,对照 `SKILL.md` 的最小映射规则:
+
+| Level | F-ID 对应 TC 最少要覆盖 |
+| --- | --- |
+| L1 | 1 正向 |
+| L2 | 1 正向 + 1 边界 + 1 异常 |
+| L3 | 1 正向 + 2 边界 + 1 异常 + 1 NFR |
+
+不达标 → 补 TC 或 F-ID 拆细。
+
+---
+
+## 本文与 SKILL.md 的关系
+
+SKILL.md 给了 F-ID → TC 的映射规则表。本文给 `requirement.md §8` 每个边界维度到 TC 骨架的具体映射 + 完整例子库 + 检查清单。test-spec 在写用例前,先按本文把 §8 每一行"翻译"成 TC。