kld-sdd 2.6.1 → 2.6.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kld-sdd",
-  "version": "2.6.1",
+  "version": "2.6.2",
   "description": "KLD SDD OpenSpec 项目初始化工具 - 一键部署 SDD skills",
   "main": "index.js",
   "bin": {

package/templates/skills/kld-sdd/opsx-apply/SKILL.md

@@ -191,35 +191,40 @@ e. **⛔ 测试执行门禁** — 按 `proposal.md` 的 `test-strategy` 决定
 f. **⛔ 立即更新任务状态** — tasks.md `- [ ]`→`- [x]` 与 `**状态**: [ ]`→`[x]` 两种格式同步；显示 `✅ [TASK-ID] 已完成 [N/M]`；记录任务级 Telemetry（`task_update`，命令模板见 `./reference.md`）。
 g. **继续下一个层级** — 重新检查 DAG，找出依赖已满足的下一层级任务。
 
-**【S2 逐任务红绿节奏】**：每个任务完成后，在编译检查（d）和测试门禁（e）之外，如果 `test-strategy` 为 `tdd`，要求：
-1. **测试-RED 任务**：编写带真实断言的测试 → 运行测试 → 确认失败（失败原因必须是功能未实现）→ 记录失败原因
-2. **实现-GREEN 任务**：读取对应 RED 的失败原因 → 写最少代码让测试通过 → 运行测试确认通过
-3. **重构-REFACTOR 任务**：在测试全绿状态下重构 → 运行全部测试确认仍绿
-4. 再进入下一个任务
+**【S2 逐任务红绿节奏】**（test-strategy=tdd 时）：
 
-这确保每个行为点都有对应的测试保护，测试真实驱动实现，而非最后统一跑测试。
+⛔ TDD 铁律：NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+先写了生产代码？删除它，从测试开始。
 
-**【S2.1 RED 测试质量标准】**（test-strategy=tdd 时强制）：
+⛔ **TDD RED→GREEN 对严格串行，不适用同层并行派发**。即使 DAG 显示同层有多个 RED→GREEN 对，也必须逐对完成：RED-N → GREEN-N → RED-(N+1) → GREEN-(N+1)。禁止一次性编写多个 RED 测试再一次性实现多个 GREEN。
 
-> ⛔ 核心原则：**Mock 边界，不 Mock 行为**
->
-> 测试应验证**真实行为链路**（输入→输出），而非验证"能否 catch mock 抛的异常"。
+1. **RED**：编写带真实断言的测试 → 运行 → 确认失败（失败原因必须是功能未实现）→ 记录失败原因
+   - ⛔ 只写当前 RED 对应的测试方法，不提前编写后续 RED 的测试
+2. **🔴 中断声明**：RED 确认失败后，显式声明 `🔴 RED-N 确认失败，原因：XXX。现在进入 GREEN-N`
+3. **GREEN**：读取 RED 失败原因 → 执行 GREEN Scope 声明 → 逐条确认 YAGNI 围栏 → 写最少代码让测试通过 → 禁止捆绑未测试代码
+4. **GREEN Scope 门禁**：Verify GREEN 之后，检查生产代码无越界逻辑分支（属于后续 RED 的行为 → 删除）
+5. **REFACTOR**：在测试全绿状态下重构 → 运行全部测试确认仍绿
+6. 再进入下一个任务
 
-1. **禁止 mock 被测行为本身**：测试的 Given 应准备**真实的前置条件**（如真实的 invalid token 字符串），让被测代码自然走完链路；而非直接 mock 出**期望的中间结果**（如 mock parseToken 抛异常）
-   - ❌ `when(jwtUtil.parseToken("invalid")).thenThrow(...)` — mock 了被测行为（token 解析失败），GREEN 只需加 try-catch
-   - ✅ 使用真实 JwtUtil + 真实 invalid token 字符串，让解析自然失败，测试验证完整链路
+> 完整执行步骤见 opsx-tdd-core/reference.md §1-§3
+> 合理化预防表见 opsx-tdd-core/SKILL.md §7
+> REFACTOR 检查点见 opsx-tdd-rules/rules/refactor-checklist.md
+> 异常路径覆盖门禁见 opsx-tdd-rules/rules/exception-path-coverage.md
 
-2. **Mock 仅用于系统边界依赖**：数据库 Mapper、HTTP 客户端、消息队列等外部依赖可 mock；但被测类自身的业务逻辑、实现被测行为的工具类不可 mock
-   - ✅ Mock `BookMapper.countByPublisher()` — 数据库边界，需要真实 DB 环境才能验证
-   - ❌ Mock `JwtUtil.parseToken()` — 这是被测行为的实现，mock 它等于跳过了被测逻辑
+**【S2.1 RED 测试质量标准】**（test-strategy=tdd 时强制）：
 
-3. **RED 测试的 Given 必须是真实输入**：传入真实的数据（如 `"invalid"` 字符串、`null`、空对象），让被测代码自行处理；不能 mock 出"这个输入会导致什么结果"
-   - ❌ `when(parseToken("invalid")).thenThrow()` — 预定了"invalid 会导致抛异常"这个结论
-   - ✅ 传入 `"invalid"` 字符串，让真实的 parseToken 自行决定是否失败
+⛔ RED 测试质量门禁见 `./checklist.md`「§5e.2 RED 测试质量门禁」，核心包括：
+- Mock 边界（引用 opsx-tdd-quality/SKILL.md §2）
+- 测试命名与结构（引用 opsx-tdd-quality/SKILL.md §3-§4）
+- 断言深度（引用 opsx-tdd-anti-patterns/SKILL.md §4 反模式 14）
+- RED 阶段反模式检查（引用 opsx-tdd-anti-patterns/SKILL.md §3）
 
-4. **GREEN 实现后测试不应需要修改**：测试描述行为契约（输入→期望输出），GREEN 只写让契约满足的最少代码。如果 GREEN 后需要改测试才能通过，说明 RED 测试有问题
+⛔ BEFORE 编写 RED 测试，必须读取：
+- opsx-tdd-anti-patterns/SKILL.md §3（RED 阶段 3 种反模式 + 门禁函数）
+读取后在报告中确认："已读取 RED 阶段反模式检查表"。
 
-5. **判断标准**：如果删掉被测类的实现（方法体清空），测试是否仍然因为 mock 而通过？如果是，说明测试是假的——真实测试应该在实现缺失时失败
+> 完整 Mock 边界矩阵见 opsx-tdd-quality/SKILL.md §2
+> 完整 15 种反模式见 opsx-tdd-anti-patterns/SKILL.md §3-§4
 
 ### 5f. 【S3 apply 结束前 checkbox 全量自检】
 
@@ -276,6 +281,8 @@ g. **继续下一个层级** — 重新检查 DAG，找出依赖已满足的下
 - **⛔ 编译检查门禁**：每完成一个任务后必须运行编译检查，编译失败禁止标记已完成。
 - **⛔ 测试执行门禁**：根据 `test-strategy` 决定（tdd=强制, impl-first=强制补跑, none=跳过）；须真实执行并留 telemetry。${HOOK_GATE_DESCRIPTION}
 - **⛔ 必须实时更新任务状态**：每完成一个任务立即改 tasks.md，两种格式同步。
+- **⛔ task_update 后必须验证 checkbox 已更新**：执行 `check-task` 确认 tasks.md 对应行已变更；未更新则手动修改。
+- **⛔ TDD RED→GREEN 严格串行**：不适用同层并行派发；RED-N 确认失败后必须执行中断声明再进入 GREEN-N；GREEN 完成后必须通过 Scope 门禁再进入下一个 RED。
 - **Git 只读策略**：禁止为了度量自动初始化 Git、创建分支或提交 commit；非 Git 项目用 `vcs_mode=no-git` 继续执行。
 - **⛔ Step 0.1 隔离校验必做**：建 worktree / 建议分支名前必须完成 proposal + 跨 cap spec 依赖校验并输出报告。
 - **Worktree 为加速手段，非必选项**：校验通过且解耦方可多 worktree；有依赖或共享修改面则串行。

package/templates/skills/kld-sdd/opsx-apply/checklist.md

@@ -34,36 +34,41 @@ description: opsx-apply 的阶段强制检查点与自检清单。仅在执行 a
 
 ### §5e 测试执行门禁（按 `proposal.md` 的 `test-strategy`）
 
-- [ ] `tdd` → **⛔ 强制执行**：
-  - 测试-RED 任务：运行测试确认**失败**，失败原因必须是功能未实现（非编译错误）
-  - 实现-GREEN 任务：运行测试确认**通过**
-  - 重构-REFACTOR 任务：运行**全部测试**确认仍绿
-  - 测试失败禁止继续，必须修复
-- [ ] `impl-first` → **⚠️ 警告模式**：运行测试，失败时显示警告但允许继续
-- [ ] `none` → **跳过**：不执行测试门禁
+> 测试执行门禁策略见 opsx-tdd-rules/rules/test-execution-gate.md
+
+- [ ] `tdd` → ⛔ 强制执行（RED 确认失败、GREEN 确认通过、REFACTOR 全部测试仍绿）
+- [ ] `impl-first` → ⚠️ 警告模式
+- [ ] `none` → 跳过
 
 ### §5e.1 TDD 执行合规自检（仅 test-strategy=tdd 时）
 
-- [ ] RED 任务执行后已运行测试并确认失败
-- [ ] RED 任务失败原因是"功能未实现"而非编译错误
-- [ ] GREEN 任务执行后已运行测试确认通过
-- [ ] GREEN 任务未提前实现没有测试要求的功能
-- [ ] REFACTOR 任务执行后已运行全部测试确认仍绿
-- [ ] 未出现"先写生产代码再补测试"的情况
+⛔ 每完成一个 RED/GREEN/REFACTOR 任务后，必须执行 `opsx-tdd-core/checklist.md` §A（7 项）逐项勾选。
+
+> 不在此内联复制，以 opsx-tdd-core/checklist.md §A 为唯一真相源。
+> 额外补充：REFACTOR 任务还需执行 `opsx-tdd-rules/rules/refactor-checklist.md`（7 项重构检查点）。
 
 ### §5e.2 RED 测试质量门禁（仅 test-strategy=tdd 时，RED 任务完成后强制检查）
 
-> ⛔ 核心原则：**Mock 边界，不 Mock 行为**
+⛔ 核心原则（引用 opsx-tdd-quality/SKILL.md §2）：Mock 边界，不 Mock 行为
+- [ ] 未 mock 被测行为本身
+- [ ] Mock 仅用于系统边界依赖（Mapper/HTTP）
+- [ ] RED 测试 Given 是真实输入
+
+⛔ 测试命名与结构（引用 opsx-tdd-quality/SKILL.md §3-§4）：
+- [ ] 测试方法名符合 `{method}_{given}_{expected}` 格式
+- [ ] 测试包含 `// Given` / `// When` / `// Then` 注释结构
+- [ ] 一测一场景（测试方法名不含 "and"）
 
-- [ ] **未 mock 被测行为本身**：测试的 Given 准备的是真实前置条件（如真实 invalid token 字符串），让被测代码自然走完链路；而非直接 mock 出期望的中间结果
-  - ❌ `when(jwtUtil.parseToken("invalid")).thenThrow(...)` — mock 了被测行为（解析失败），GREEN 只需加 try-catch
-  - ✅ 使用真实 JwtUtil + 真实 invalid token，让解析自然失败
-- [ ] **Mock 仅用于系统边界依赖**：数据库 Mapper、HTTP 客户端等外部依赖可 mock；被测类自身的业务逻辑、实现被测行为的工具类不可 mock
-  - ✅ Mock `BookMapper.countByPublisher()` — 数据库边界
-  - ❌ Mock `JwtUtil.parseToken()` — 被测行为的实现
-- [ ] **RED 测试的 Given 是真实输入**：传入真实数据让被测代码自行处理，不 mock 出"这个输入会导致什么结果"
-- [ ] **删掉实现后测试仍因 mock 而通过？** 如果是 → 测试是假的，必须重写
-- [ ] **GREEN 后测试不需要修改**：如果 GREEN 后需要改测试才能通过 → RED 测试有问题
+⛔ 断言深度（引用 opsx-tdd-anti-patterns/SKILL.md §4 反模式 14）：
+- [ ] 每个测试至少有一个具体值断言（assertEquals），而非仅 assertNotNull
+- [ ] 异常测试使用 `assertThrows(BusinessException.class, ...)` 并验证错误码（而非 RuntimeException.class）
+
+⛔ BEFORE 标记 RED 任务完成，必须读取：
+- opsx-tdd-anti-patterns/SKILL.md §3（RED 阶段反模式检查）
+读取后确认："已检查 RED 阶段反模式"。
+
+> 完整质量门禁见 opsx-tdd-quality/SKILL.md §2-§6
+> 完整 15 种反模式见 opsx-tdd-anti-patterns/SKILL.md §3-§4
 
 ### 任务状态实时更新
 
@@ -72,19 +77,18 @@ description: opsx-apply 的阶段强制检查点与自检清单。仅在执行 a
 - [ ] 两种格式同步更新，不可遗漏
 - [ ] 显示进度：`✅ [TASK-ID] 已完成 [N/M]`
 - [ ] 记录任务级 Telemetry（`task_update`，`--task-id=<TASK-ID>` 必填，否则 E4 指标无法计算）；TDD 测试骨架任务须在 `--details-json` 带 `"task_kind":"test-skeleton"`（P3，避免红灯误判拉低 E4）
+- [ ] ⛔ **task_update 后必须验证 checkbox 已更新**：执行 `node skywalk-sdd/index.cjs check-task --project=. --change=<变更名称> --task-id=<TASK-ID>` 确认 tasks.md 中对应行已从 `- [ ]` 变为 `- [x]`；若未更新，手动修改 tasks.md 并报告
 
 ---
 
 ## §6.0 单元测试真实执行自检（`test-strategy` 非 `none`）
 
-- [ ] 在结束 apply 或 §6.1 收尾之前，在项目根或 worktree 内**真实运行**单元测试命令（`npm test` / `pytest` / `go test` 等）
-- [ ] 留下可核验 telemetry 证据（任选其一）：
-  - `node skywalk-sdd/log.cjs record --type=test_result ...`（`test_results.command` 非空，且 `passed`/`failed`/`duration_ms` 有实际值）
-  - `task_update` 的 `details-json` 中 `test_results` 含真实执行数据
-  - 或单独运行 `/opsx-test` 并完成 `command=test` 的 `stage_end`
+> 单元测试真实执行自检见 opsx-tdd-core/reference.md §9
+
+- [ ] 真实运行单元测试命令并留 telemetry 证据
 - [ ] `tdd`：无测试证据不得结束 apply / 不得 finish worktree
 - [ ] `impl-first`：实现后必须补跑并记录
-- [ ] `none`：跳过本节与 test gate
+- [ ] `none`：跳过
 
 ---
 
@@ -108,8 +112,10 @@ description: opsx-apply 的阶段强制检查点与自检清单。仅在执行 a
 - [ ] ⛔ **DAG 依赖拦截**：执行任务前必须检查依赖，前置未完成必须拦截
 - [ ] ⛔ **编译检查门禁**：每完成一个任务后必须运行编译检查，编译失败禁止标记已完成
 - [ ] ⛔ **测试执行门禁**：根据 `test-strategy` 决定（tdd=强制, impl-first=强制补跑, none=跳过）；须真实执行并留 telemetry，`sdd-apply-test-gate` 校验非占位数据
-- [ ] ⛔ **RED 测试质量门禁**：Mock 边界不 Mock 行为；未 mock 被测行为本身；Mock 仅用于系统边界依赖；RED 测试 Given 是真实输入
+- [ ] ⛔ **RED 测试质量门禁**：见 §5e.2（引用 opsx-tdd-quality + opsx-tdd-anti-patterns，不在此内联复制）
 - [ ] ⛔ **必须实时更新任务状态**：每完成一个任务立即改 tasks.md，两种格式（`- [ ]`→`- [x]` 与 `**状态**: [ ]`→`[x]`）同步
+- [ ] ⛔ **task_update 后必须验证 checkbox 已更新**：执行 `check-task` 确认 tasks.md 对应行已变更；未更新则手动修改
+- [ ] ⛔ **TDD RED→GREEN 严格串行**：不适用同层并行派发；RED-N 确认失败后必须执行中断声明再进入 GREEN-N；GREEN 完成后必须通过 Scope 门禁再进入下一个 RED
 - [ ] **Git 只读策略**：禁止为了度量自动初始化 Git、创建分支或提交 commit；非 Git 项目用 `vcs_mode=no-git` 继续执行
 - [ ] ⛔ **Step 0.1 隔离校验必做**：建 worktree / 建议分支名前必须完成 proposal + 跨 cap spec 依赖校验并输出报告；未通过不得按 full 并行策略拆 `kld-sdd/<change>/<cap>`
 - [ ] **Worktree 为加速手段，非必选项**：校验通过且解耦方可多 worktree；有依赖或共享修改面则串行

package/templates/skills/kld-sdd/opsx-apply/implementer-prompt.md

@@ -4,44 +4,36 @@
 
 ## TDD 铁律（当 test-strategy=tdd 时生效）
 
-**NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.**
-
-- 如果要写生产代码，必须先有一个失败的测试
-- 如果先写了生产代码再写测试：删掉生产代码，从测试开始
+NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.
+- 先写了生产代码再写测试？删掉生产代码，从测试开始
 - "太简单不用测" → 如果值得写，就值得测
 - "事后补测一样" → 不一样，TDD 的价值在于测试驱动设计
-- "删了浪费" → 删掉重来比带着错误前提实现更省时间
 
 ### 执行 测试-RED 任务
-1. 读取对应 spec.md 场景和 design.md 设计
+1. 读取 spec.md 场景和 design.md 设计
 2. 编写测试代码：Given-When-Then 结构 + 真实断言
-3. 运行测试：`mvn test -Dtest=XxxTest#testMethodName`（或项目对应命令）
-4. 确认测试失败：失败原因必须是"功能未实现"（如 NullPointerException、AssertionError）
-5. 如果测试通过：说明测试无效或功能已存在，重新编写测试
-6. 记录失败原因到任务状态
-
-**⛔ RED 测试质量标准（Mock 边界，不 Mock 行为）：**
-
-- **禁止 mock 被测行为本身**：测试的 Given 应准备**真实的前置条件**（如真实的 invalid token 字符串），让被测代码自然走完链路；而非直接 mock 出期望的中间结果
-  - ❌ `when(jwtUtil.parseToken("invalid")).thenThrow(...)` — mock 了被测行为（解析失败），GREEN 只需加 try-catch 就通过，测试无意义
-  - ✅ 使用真实 JwtUtil + 真实 invalid token 字符串，让解析自然失败，测试验证完整链路
-- **Mock 仅用于系统边界依赖**：数据库 Mapper、HTTP 客户端、消息队列等外部依赖可 mock；但被测类自身的业务逻辑、实现被测行为的工具类不可 mock
-  - ✅ Mock `BookMapper.countByPublisher()` — 数据库边界，需要真实 DB 环境才能验证
-  - ❌ Mock `JwtUtil.parseToken()` — 这是被测行为的实现，mock 它等于跳过了被测逻辑
-- **RED 测试的 Given 必须是真实输入**：传入真实的数据（如 `"invalid"` 字符串、`null`、空对象），让被测代码自行处理；不能 mock 出"这个输入会导致什么结果"
-- **判断标准**：如果删掉被测类的实现（方法体清空），测试是否仍然因为 mock 而通过？如果是，说明测试是假的——真实测试应该在实现缺失时失败
+3. 运行测试，确认失败（失败原因必须是功能未实现）
+4. 如果测试通过：说明测试无效或功能已存在，重新编写
+5. ⛔ 检查异常路径覆盖：每个 orElseThrow/边界检查须有对应测试方法（见 `opsx-tdd-rules/rules/exception-path-coverage.md`）
+
+⛔ BEFORE 编写测试代码，必须读取对应语言的规则文件：
+- Java：opsx-tdd-quality/rules/java/java-test-template.md + argument-matching.md + domain-service-rules.md
+- TypeScript：opsx-tdd-quality/rules/typescript/ts-test-template.md
+- Python：opsx-tdd-quality/rules/python/py-test-template.md
+- 通用：opsx-tdd-quality/rules/general/naming-conventions.md + given-when-then.md + no-logic-in-tests.md
+读取后在报告中列出已读取的规则文件路径。
 
 ### 执行 实现-GREEN 任务
 1. 读取对应 RED 任务的失败原因
-2. 编写**最少代码**让该测试通过
-3. 不提前实现没有测试要求的功能（YAGNI）
-4. **⛔ 禁止捆绑未测试的代码**：
-   - 如果 RED 测试只测了 Service 方法，GREEN 不得同时实现 Controller 接口
-   - 如果 RED 测试只测了一个行为点，GREEN 不得同时实现其他行为点的逻辑
-   - 如果需要修改多个文件才能让测试通过，检查是否测试范围过大
-5. 运行测试：确认通过
-6. 如果引入了新功能但无对应测试：删除多余代码
-7. 自检：本次修改的文件列表是否与 RED 测试覆盖的范围一致？如果超出，报告 DONE_WITH_CONCERNS
+2. 【Scope 声明】按 `opsx-tdd-rules/rules/green-scope-declaration.md` 执行 Scope 声明步骤
+3. 编写最少代码——仅实现 Scope 声明中标记为"属于当前 RED"的步骤
+4. 【Scope 自检】检查生产代码中是否有未被任何当前 RED 断言覆盖的逻辑路径？有则删除
+5. 不提前实现没有测试要求的功能（YAGNI）
+6. 禁止捆绑未测试的代码（Controller/Filter/Config）
+
+> 完整执行步骤见 opsx-tdd-core/reference.md §1-§3
+> 完整质量标准见 opsx-tdd-quality/SKILL.md §2
+> Scope 声明规则见 opsx-tdd-rules/rules/green-scope-declaration.md
 
 ### 执行 重构-REFACTOR 任务
 1. 在所有测试通过的状态下开始
@@ -49,6 +41,9 @@
 3. 运行**全部测试**：`mvn test`（或项目对应命令）
 4. 确认所有测试仍通过
 5. 如果任何测试失败：回退重构，重新尝试
+6. ⛔ 执行 `opsx-tdd-rules/rules/refactor-checklist.md`（7 项重构检查点）
+
+> 完整 REFACTOR 检查点见 opsx-tdd-rules/rules/refactor-checklist.md
 
 ## 派发格式
 
@@ -99,7 +94,7 @@ Agent (general-purpose):
     3. 遵循 overview.md 的全局规范
     4. 保持变更最小化，不超出任务范围
     5. **当任务类型为 测试-RED 时**：编写带真实断言的测试，运行并确认失败，记录失败原因
-    6. **当任务类型为 实现-GREEN 时**：读取对应 RED 的失败原因，写最少代码让测试通过，不提前实现未要求的功能
+    6. **当任务类型为 实现-GREEN 时**：读取对应 RED 的失败原因，按 `opsx-tdd-rules/rules/green-scope-declaration.md` 执行 Scope 声明，仅实现标记为"属于"的步骤，写最少代码让测试通过，不提前实现未要求的功能
     7. **当任务类型为 重构-REFACTOR 时**：在测试全绿状态下优化代码，运行全部测试确认仍绿
     8. 自我审查（见下方）
     9. 报告结果
@@ -144,6 +139,7 @@ Agent (general-purpose):
     - 是否避免了过度工程（YAGNI）？
     - 是否只构建了任务要求的内容？
     - 是否避免了对无关文件的修改？
+    - **GREEN 任务 Scope 检查**：生产代码中是否存在未被当前 RED 断言覆盖的逻辑分支？若存在且属于后续 RED 的行为，是否已删除？
 
     如果在自我审查中发现问题，先修复再报告。
 

package/templates/skills/kld-sdd/opsx-apply/reference.md

@@ -22,13 +22,9 @@ node skywalk-sdd/log.cjs record --type=task_update --command=apply --project=. -
 
 **⚠️ 注意**：`--task-id=<TASK-ID>` 必须替换为实际任务 ID，否则 E4 指标无法计算。
 
-**🧪 TDD 测试骨架任务（`test-strategy: tdd`）**：当任务是"测试骨架"（仅编写测试用例、实现尚未编写，测试预期失败/红灯）时，`task_update` 必须在 `--details-json` 中带 `"task_kind":"test-skeleton"`，`--result=success`（骨架按 TDD 计划完成即成功），`test_results.failed` 如实记录红灯数。这样 E4 一次成码率不会把 TDD 预期红灯误判为成码失败（P3）。实现任务不带 `task_kind`（默认 implementation），按真实测试结果记录。
+**🧪 TDD 测试骨架任务（`test-strategy: tdd`）**：当任务是"测试骨架"时，`task_update` 必须在 `--details-json` 中带 `"task_kind":"test-skeleton"`。
 
-TDD 测试骨架任务示例：
-
-```bash
-node skywalk-sdd/log.cjs record --type=task_update --command=apply --project=. --change=<变更名称> --capability=<capability-name> --task-id=<TASK-ID> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID> --status=completed --result=success --summary="<TASK-ID> 测试骨架完成（TDD 红灯）" --details-json="{\"task_kind\":\"test-skeleton\",\"test_results\":{\"command\":\"<实际测试命令>\",\"passed\":0,\"failed\":<红灯数>,\"skipped\":0,\"duration_ms\":0}}"
-```
+> 完整 test-skeleton telemetry 模板见 opsx-tdd-rules/rules/test-skeleton-telemetry.md
 
 **📄 通过文件传递大 payload**：若 `details-json` 内容过长，可先写入 `skywalk-sdd/state/<变更名称>-task-update.json`，再使用 `--details-file` 指定该文件：
 
@@ -353,44 +349,17 @@ node skywalk-sdd/log.cjs record --type=ai_adoption_review --command=apply --proj
 
 ## §6.0 单元测试真实执行（`test-strategy` 非 `none`）
 
-当 `proposal.md` 的 `test-strategy` 为 **`tdd`** 或 **`impl-first`** 时：
-
-1. **在结束 apply 或执行 §6.1 收尾之前**，必须在项目根或 worktree 内**真实运行**单元测试命令（`npm test` / `pytest` / `go test` 等）。
-2. 须留下可核验的 telemetry 证据（任选其一）：
-   - `node skywalk-sdd/log.cjs record --type=test_result ...`（`test_results.command` 非空，且 `passed`/`failed`/`duration_ms` 有实际值）
-   - `task_update` 的 `details-json` 中 `test_results` 含真实执行数据
-   - 或单独运行 `/opsx-test` 并完成 `command=test` 的 `stage_end`
-3. **Claude Code**：`sdd-apply-test-gate.cjs` 会在 `log.cjs end`、`apply-worktree-finish`、会话 Stop 时自动校验；无证据则**阻断**并提示补跑测试。
+> 单元测试真实执行见 opsx-tdd-core/reference.md §9
 
-| test-strategy | 行为 |
-|---------------|------|
-| `tdd` | 无测试证据不得结束 apply / 不得 finish worktree |
-| `impl-first` | 同上，实现后必须补跑并记录 |
-| `none` | 跳过本节与 test gate |
+当 `test-strategy` 为 `tdd` 或 `impl-first` 时，必须真实运行单元测试并留 telemetry 证据。`sdd-apply-test-gate.cjs` 会在 `log.cjs end`、`apply-worktree-finish`、会话 Stop 时自动校验。
 
 ---
 
-## §6.0a 测试反模式检查（TDD 模式下，RED 阶段 + GREEN 完成后双重检查）
-
-> ⛔ **RED 阶段就必须检查**：不要等到 GREEN 之后才发现测试是假的。RED 写完立即自检，发现反模式立即重写。
-
-### RED 阶段强制检查（写完测试、运行确认失败后）
-
-| 反模式 | 表现 | 修复方案 |
-|--------|------|---------|
-| **Mock 被测行为本身** | `when(jwtUtil.parseToken("invalid")).thenThrow(...)` — mock 了被测行为（解析失败），GREEN 只需加 try-catch | 使用真实 JwtUtil + 真实 invalid token，让解析自然失败 |
-| **Mock 预定结论而非准备条件** | `when(bookMapper.countByPublisher(1L)).thenReturn(3)` 后只测 `if (count > 0) throw` — trivial 逻辑 | Mock 边界依赖（Mapper）是合理的，但测试断言应验证完整行为链路（如 verify 不会执行 delete） |
-| **Given 不是真实输入** | mock 出"这个输入会导致什么结果"，而非传入真实数据让被测代码自行处理 | 传入真实数据（如 `"invalid"` 字符串、`null`），让被测代码自行决定结果 |
+## §6.0a 测试反模式检查（TDD 模式下）
 
-### GREEN 完成后补充检查
+> 完整 9 种反模式检测见 opsx-tdd-anti-patterns/SKILL.md §3-§4 + reference.md
 
-| 反模式 | 表现 | 修复方案 |
-|--------|------|---------|
-| 测试 mock 行为而非真实行为 | 测试验证的是 mock 被调用，而非真实业务逻辑 | 测试应验证输出/状态变化，而非方法调用 |
-| 生产类中加测试专用方法 | 为方便测试在生产类中加了 public/protected 方法 | 通过公共 API 测试，不加测试专用方法 |
-| 不理解依赖就 mock | mock 了不理解的依赖，隐藏了结构假设 | 先理解依赖的职责再决定是否 mock |
-| 不完整的 mock | partial mock 隐藏了对象间的结构关系 | 要么完整 mock，要么用真实对象 |
-| 集成测试作为事后补充 | 单元测试不足，用集成测试弥补 | 每个行为点应有独立的单元测试 |
+⛔ RED 阶段就必须检查，不要等到 GREEN 之后才发现测试是假的。
 
 > 参照来源：`skill-references/superpowers-tdd/testing-anti-patterns.md`
 

package/templates/skills/kld-sdd/opsx-check/SKILL.md

@@ -113,17 +113,14 @@ openspec list
 
 #### 4.4a TDD 合规性检查（仅 test-strategy=tdd 时执行）
 
-检查项：
-1. RED 任务验收标准是否包含"测试运行失败"（而非"断言为空"）
-2. GREEN 任务是否为行为级粒度（一个 GREEN 对应一个 RED，非模块级）
-3. DAG 中是否存在 RED→GREEN 循环对（而非 TEST(全部)→IMPL(全部)批次）
-4. 是否存在 REFACTOR 任务（推荐但不强制）
-5. 非 TDD 模块（前端/配置/SQL）是否正确排除红绿循环
-6. GREEN 任务验收标准是否为"让对应 RED 通过"（而非"实现完整功能"）
-7. **GREEN 任务无捆绑**：每个 GREEN 任务的输出不包含未测试的 Controller/Filter/Config
-8. **Controller 层策略已声明**：tasks.md 中明确声明 Controller 层使用策略 A 或策略 B
-9. **RED 任务有测试方法名**：每个 RED 任务包含 `{method}_{state}_{outcome}` 格式的测试方法名
-10. **REFACTOR 有具体方向**：每个 REFACTOR 任务列出至少 2 个具体重构点
+⛔ 执行 `opsx-tdd-core/checklist.md` §B（10 项）逐项检查。
+
+> 不在此内联复制，以 opsx-tdd-core/checklist.md §B 为唯一真相源。
+> 额外补充：还需检查 `opsx-tdd-rules/rules/exception-path-coverage.md`（异常路径覆盖门禁）。
+
+⛔ BEFORE 完成 TDD 合规性检查，如需深度审查测试质量，必须读取：
+- opsx-tdd-review/SKILL.md（测试质量审查清单 8 项 + 缺失测试检测）
+读取后确认："已读取测试质量审查清单"。
 
 #### 4.5 任务完成状态检查（实现后 / 归档前）
 

package/templates/skills/kld-sdd/opsx-check/checklist.md

@@ -38,16 +38,10 @@ description: "opsx-check 阶段日志自检清单 — 仅在 check 自检时读
 
 ## E. TDD 合规性检查（仅 test-strategy=tdd 时）
 
-- [ ] tasks.md 中 测试-RED 任务的验收标准包含"测试运行失败"
-- [ ] tasks.md 中无"断言为空"或"编译通过但断言为空"的验收标准
-- [ ] tasks.md 中 实现-GREEN 任务为行为级粒度（一对一对应 RED）
-- [ ] tasks.md 中 DAG 存在 RED→GREEN 循环对
-- [ ] tasks.md 中非 TDD 模块未拆红绿循环
-- [ ] tasks.md 中 GREEN 任务的输出不包含未测试的 Controller/Filter/Config
-- [ ] tasks.md 中已声明 Controller 层处理策略（策略 A 或策略 B）
-- [ ] tasks.md 中每个 RED 任务包含测试方法名
-- [ ] tasks.md 中每个 REFACTOR 任务列出至少 2 个具体重构点
-- [ ] check_result 的 categories 中包含 `tdd_compliance`
+⛔ 执行 `opsx-tdd-core/checklist.md` §B（10 项）逐项检查。
+
+> 不在此内联复制，以 opsx-tdd-core/checklist.md §B 为唯一真相源。
+> 额外补充：还需检查 `opsx-tdd-rules/rules/exception-path-coverage.md`（异常路径覆盖门禁）。
 
 ## F. 语义门禁与工作态
 

package/templates/skills/kld-sdd/opsx-design/SKILL.md

@@ -130,6 +130,8 @@ openspec list
 
 **输出路径**：`changes/<name>/specs/<capability>/design.md`
 
+**⛔ DES 步骤级标注（TDD 模式强制）**：当 `test-strategy=tdd` 时，被多个 RED/GREEN 对映射的 DES 元素必须标注步骤级任务归属。规则详见 `opsx-tdd-rules/rules/des-step-annotation.md`
+
 ### 6.5 【version 正则注释】允许前导零
 
 design.md 中若使用 version 正则约束（如格式校验 `^\d+\.\d+\.\d+$`），需在正则旁**标注「允许前导零」**：

package/templates/skills/kld-sdd/opsx-design/checklist.md

@@ -29,6 +29,7 @@ description: opsx-design 的阶段强制检查点与自检清单。仅在执行
 - [ ] 外部依赖已列出
 - [ ] 异常处理策略已定义
 - [ ] 文档末尾包含质量红线检查清单
+- [ ] ⛔ **DES 步骤级标注（TDD 模式）**：当 test-strategy=tdd 时，被多个 RED/GREEN 对映射的 DES 元素已标注步骤级 `[GREEN-N]` 归属（规则见 `opsx-tdd-rules/rules/des-step-annotation.md`）
 
 **如有任意一项未满足，重新生成对应章节，直至全部通过。**
 

package/templates/skills/kld-sdd/opsx-propose/reference.md

@@ -52,25 +52,12 @@ description: opsx-propose 的详细模板：telemetry 命令、文档拆分模
 
 **❗ 必须主动询问用户，不得默认选择**
 
-使用 **AskUserQuestion** 工具向用户询问：
+三种策略：
+- A) TDD（红绿重构循环）：每个行为点先写失败测试再写最少代码，任务量 3-5 倍
+- B) Impl-First（代码先行）：先实现再补测试验证
+- C) None（仅实现）：不生成测试任务
 
-> "🧪 **请选择测试策略：**
->
-> **A) 测试驱动 (TDD)** - 红绿重构循环
->    - 每个行为点先写失败测试（红），再写最少代码让它通过（绿），最后重构
->    - DAG: RED → GREEN → REFACTOR → RED → GREEN → ...（行为级小步循环）
->    - 任务数量较多（每个行为点一对红绿），但每个测试都真实驱动实现
->    - 适合：核心业务逻辑、质量要求高、需要测试驱动设计
->    - ⚠️ 注意：TDD 模式下任务数量会显著增加（约为模块级拆分的 3-5 倍）
->
-> **B) 实现优先 (Impl-First)** - 代码先行
->    - 先生成实现任务，测试作为验证步骤
->    - DAG: 实现代码 → 测试验证
->    - 适合：UI 层、配置类、快速原型
->
-> **C) 无测试 (None)** - 仅实现
->    - 不生成测试任务，仅编译检查
->    - 适合：简单配置、文档更新"
+使用 **AskUserQuestion** 工具向用户询问（A/B/C 三选一）。
 
 根据用户选择：
 - 选择 A：设置 `test-strategy: tdd`
@@ -79,6 +66,9 @@ description: opsx-propose 的详细模板：telemetry 命令、文档拆分模
 
 **将用户选择记录到 proposal.md 的 YAML frontmatter 中。**
 
+> 完整策略定义见 opsx-tdd-core/SKILL.md §5
+> 交互引导文案见 opsx-tdd-rules/rules/tdd-strategy-selection.md
+
 ---
 
 ## §10 质量红线自检清单

package/templates/skills/kld-sdd/opsx-rules/reference.md

@@ -80,7 +80,7 @@ trigger: always_on
 |------|--------|----------|----------|
 | 架构规范 | `architecture` | 目录分层、模块边界、入口 | 分层约定、禁止循环依赖、新代码落位 |
 | 编码规范 | `coding-style` | 语言、lint、缩进 | 命名、缩进、注释语言、CommonJS/ESM |
-| 测试约定 | `testing` | test 目录、框架 | 测试命令、命名、TDD 期望 |
+| 测试约定 | `testing` | test 目录、框架 | 测试命令、命名、TDD 期望（见 opsx-tdd-core/SKILL.md §5） |
 | 数据安全 | `database-safety` | ORM/迁移目录 | 无 DB 时降级为「禁止危险文件操作/敏感数据提交」 |
 | Git 提交 | `git-commit` | git log 风格、CI | 提交前确认、message 风格、禁止 force push |
 

package/templates/skills/kld-sdd/opsx-spec/SKILL.md

@@ -162,6 +162,8 @@ node skywalk-sdd/context-client.cjs --query="<当前 Capability 的自然语言
 - 需求项使用 `####`（4个#）
 - 场景使用 `#####`（5个#）
 
+**⛔ 多校验拆分规则（TDD 关键）**：当单个 STMT 包含多个"必须校验"条件时，每个校验条件必须有对应的独立 AC 场景。规则详见 `opsx-tdd-rules/rules/multi-validation-split.md`
+
 ### 6.5 【Node 版本约束来源校验】
 
 若 spec.md 中声明了 Node 版本约束（如 `>=14`、`>=18` 等），必须在该需求项或 proposal.md 中**声明来源**：

package/templates/skills/kld-sdd/opsx-task/SKILL.md

@@ -132,33 +132,15 @@ Simple 模式或单文件能力域下，**不要拆成多个同文件任务**。
 
 **若已设置**：向用户确认
 > "🧪 **当前测试策略：[test-strategy]**
->
-> - `tdd`: 红绿重构循环 - 每个行为点先写失败测试（红），再写最少代码让它通过（绿），最后重构
-> - `impl-first`: 实现优先 - 先实现后测试
-> - `none`: 无测试 - 不生成测试任务
->
+> - `tdd`: 红绿重构循环
+> - `impl-first`: 实现优先
+> - `none`: 无测试
 > 是否继续使用该策略？"
 
-**若未设置**：使用 **AskUserQuestion** 工具询问
-> "🧪 **未检测到测试策略配置，请选择：**
->
-> **A) 测试驱动 (TDD)** - 红绿重构循环
->    - 每个行为点先写失败测试（红），再写最少代码让它通过（绿），最后重构
->    - DAG 顺序：RED → GREEN → REFACTOR → RED → GREEN → ...（行为级小步循环）
->    - 任务数量较多（每个行为点一对红绿），但每个测试都真实驱动实现
->    - 适合：核心业务逻辑、质量要求高、需要测试驱动设计
->    - ⚠️ 注意：TDD 模式下任务数量会显著增加（约为模块级拆分的 3-5 倍）
->
-> **B) 实现优先 (Impl-First)** - 代码先行
->    - 先生成实现任务，测试作为验证步骤
->    - DAG 顺序：实现代码 → 测试验证
->    - 适合：UI 层、配置类、快速原型
->
-> **C) 无测试 (None)** - 仅实现
->    - 不生成测试任务，仅编译检查
->    - 适合：简单配置、文档更新"
+**若未设置**：使用 **AskUserQuestion** 工具询问（A/B/C 三选一）
 
-根据用户选择设置 `test-strategy`，并更新 proposal.md 的 frontmatter（若未设置）。
+> 完整策略定义见 opsx-tdd-core/SKILL.md §5
+> 交互引导文案见 opsx-tdd-rules/rules/tdd-strategy-selection.md
 
 ### 6. 【交互引导】确认任务拆解策略
 
@@ -183,25 +165,26 @@ Simple 模式或单文件能力域下，**不要拆成多个同文件任务**。
 > **必须包含**：任务执行拓扑图（DAG）+ 原子任务清单。任务结构字段（TASK-ID / 类型 / 依赖 / 状态 / 描述等）见 `./reference.md`「§7 任务结构」。
 
 **当 test-strategy=tdd 时，任务生成规则：**
-1. 将 spec.md 中每个需求项的每个场景拆为一个行为点
-2. 每个行为点生成一对任务：`[TASK-XX-RED-N]` + `[TASK-XX-GREEN-N]`
-3. RED 任务依赖：前置基础设施任务（如脚手架、数据层）
-4. GREEN 任务依赖：对应的 RED 任务
-5. 可选：每 3-5 个行为点后插入一个 `[TASK-XX-REFACTOR]` 任务
-6. 模块末尾可保留一个 `[TASK-XX-VERIFY]` 任务做全量测试验证
-7. 非 TDD 模块（如前端 UI、配置、SQL DDL）不拆红绿，按常规任务处理
-8. RED 任务验收标准必须包含"测试运行失败，且失败原因正确（功能未实现）"
-9. GREEN 任务验收标准必须包含"写最少代码让对应 RED 测试通过"，不包含"实现完整功能"。
-   **⛔ 禁止在 GREEN 任务中捆绑未测试的代码**（如 Controller 接口、Filter、Config 等）。
-   如果 GREEN 需要同时修改多个文件才能让测试通过，检查是否测试范围过大或实现范围超出测试要求。
-10. **GREEN 任务范围限制**：每个 GREEN 任务只能实现让对应 RED 测试通过的代码，禁止捆绑未测试的功能。具体规则：
-    - Service 层 GREEN 只实现当前行为点的 Service 方法逻辑
-    - Controller 层不捆绑在 Service GREEN 中，必须独立处理
-11. **Controller 层处理策略**（二选一，由 AI 根据项目复杂度判断，必须在 tasks.md §2.0 中声明）：
-    - 策略 A（推荐）：为每个 Controller 接口生成 RED 测试（使用 @WebMvcTest），拆为 RED→GREEN 对
-    - 策略 B：将 Controller 层声明为非 TDD 模块，作为独立接口层任务，依赖对应 Service 完成
-    - 无论哪种策略，Controller 不得捆绑在 Service 的 GREEN 任务中
-12. **RED 任务必须包含**：测试方法名（`{method}_{state}_{outcome}` 格式）、Given-When-Then 结构描述、输出文件路径、关联 spec 场景编号
+
+⛔ 核心规则（inline）：
+1. 每个场景拆为一个行为点，每个行为点生成一对 RED+GREEN 任务
+2. RED 验收标准必须包含"测试运行失败且失败原因正确"
+3. GREEN 验收标准必须包含"写最少代码让对应 RED 测试通过"，禁止捆绑
+4. GREEN 不得包含未测试的 Controller/Filter/Config
+5. 非 TDD 模块（前端 UI/配置/SQL DDL）不拆红绿
+6. Controller 层策略必须在 tasks.md §2.0 中声明（策略 A 或 B）
+7. ⛔ **GREEN 任务 YAGNI 围栏**：每个 GREEN-N 任务描述末尾必须包含"不提前实现 [后续 RED 行为]"围栏声明。规则详见 `opsx-tdd-rules/rules/green-yagni-fence.md`
+
+⛔ BEFORE 生成 TDD 任务，必须读取：
+1. opsx-tdd-core/reference.md §6（DAG 生成规则表）
+2. opsx-tdd-rules/rules/dag-generation-rules.md（DAG 规则文件）
+3. opsx-tdd-rules/rules/controller-strategy.md（Controller 策略 A/B）
+4. opsx-tdd-rules/rules/exception-path-coverage.md（异常路径测试覆盖门禁）
+读取后确认："已读取 N 个规则文件"。
+
+> 完整 TDD 拆分示例见 opsx-tdd-core/reference.md §4
+> 非 TDD 模块定义见 opsx-tdd-rules/rules/non-tdd-modules.md
+> 任务类型定义见 opsx-tdd-rules/rules/task-type-definitions.md
 
 ### 8. 质量红线自检
 

package/templates/skills/kld-sdd/opsx-task/checklist.md

@@ -36,16 +36,10 @@ description: opsx-task 的阶段强制检查点与自检清单。仅在执行 ta
 
 ## §8.1 TDD 合规性自检（仅 test-strategy=tdd 时）
 
-- [ ] **RED 任务有真实断言**：每个 测试-RED 任务的验收标准包含"测试运行失败"，而非"断言为空"或"编译通过"
-- [ ] **GREEN 任务为行为级粒度**：每个 实现-GREEN 任务只对应一个 RED 测试，不是模块级整体实现
-- [ ] **存在红绿循环**：DAG 中存在 RED→GREEN 的循环对，而非 TEST(全部)→IMPL(全部)的批次模式
-- [ ] **有 REFACTOR 任务**：每 3-5 个行为点后至少有一个重构任务（可选但推荐）
-- [ ] **GREEN 验收为"最少代码"**：验收标准包含"让对应 RED 测试通过"，不包含"实现完整功能"
-- [ ] **非 TDD 模块已排除**：前端 UI、配置、SQL DDL 等不拆红绿循环
-- [ ] **GREEN 任务无捆绑**：每个 GREEN 任务的输出文件不包含未测试的 Controller/Filter/Config（除非该 GREEN 对应的 RED 测试明确测试了这些组件）
-- [ ] **Controller 层策略已声明**：tasks.md §2.0 中明确声明 Controller 层使用策略 A（拆 RED→GREEN）还是策略 B（非 TDD 任务）
-- [ ] **RED 任务有测试方法名**：每个 RED 任务包含 `{method}_{state}_{outcome}` 格式的测试方法名
-- [ ] **REFACTOR 有具体方向**：每个 REFACTOR 任务列出至少 2 个具体重构点
+⛔ 执行 `opsx-tdd-core/checklist.md` §B（10 项）逐项检查。
+
+> 不在此内联复制，以 opsx-tdd-core/checklist.md §B 为唯一真相源。
+> 额外补充：还需检查 `opsx-tdd-rules/rules/exception-path-coverage.md`（异常路径覆盖门禁）——每个 orElseThrow/边界检查须有对应 RED 任务。
 
 ---