kld-sdd 2.6.2 → 2.6.3

package/package.json

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

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

@@ -204,7 +204,8 @@ g. **继续下一个层级** — 重新检查 DAG，找出依赖已满足的下
 3. **GREEN**：读取 RED 失败原因 → 执行 GREEN Scope 声明 → 逐条确认 YAGNI 围栏 → 写最少代码让测试通过 → 禁止捆绑未测试代码
 4. **GREEN Scope 门禁**：Verify GREEN 之后，检查生产代码无越界逻辑分支（属于后续 RED 的行为 → 删除）
 5. **REFACTOR**：在测试全绿状态下重构 → 运行全部测试确认仍绿
-6. 再进入下一个任务
+6. **可选：TDD 审查子代理**：GREEN 任务完成后，可派发独立审查子代理执行 `opsx-tdd-review/SKILL.md` §7（子代理审查提示模板），检测"测试通过但没测到关键点"。implementer 自审查 ≠ 独立审查。
+7. 再进入下一个任务
 
 > 完整执行步骤见 opsx-tdd-core/reference.md §1-§3
 > 合理化预防表见 opsx-tdd-core/SKILL.md §7

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

@@ -42,7 +42,7 @@ description: opsx-apply 的阶段强制检查点与自检清单。仅在执行 a
 
 ### §5e.1 TDD 执行合规自检（仅 test-strategy=tdd 时）
 
-⛔ 每完成一个 RED/GREEN/REFACTOR 任务后，必须执行 `opsx-tdd-core/checklist.md` §A（7 项）逐项勾选。
+⛔ 每完成一个 RED/GREEN/REFACTOR 任务后，必须执行 `opsx-tdd-core/checklist.md` §A（11 项）逐项勾选。
 
 > 不在此内联复制，以 opsx-tdd-core/checklist.md §A 为唯一真相源。
 > 额外补充：REFACTOR 任务还需执行 `opsx-tdd-rules/rules/refactor-checklist.md`（7 项重构检查点）。
@@ -55,7 +55,7 @@ description: opsx-apply 的阶段强制检查点与自检清单。仅在执行 a
 - [ ] RED 测试 Given 是真实输入
 
 ⛔ 测试命名与结构（引用 opsx-tdd-quality/SKILL.md §3-§4）：
-- [ ] 测试方法名符合 `{method}_{given}_{expected}` 格式
+- [ ] 测试方法名符合 `{method}_{state}_{outcome}` 格式
 - [ ] 测试包含 `// Given` / `// When` / `// Then` 注释结构
 - [ ] 一测一场景（测试方法名不含 "and"）
 

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

@@ -113,11 +113,15 @@ openspec list
 
 #### 4.4a TDD 合规性检查（仅 test-strategy=tdd 时执行）
 
-⛔ 执行 `opsx-tdd-core/checklist.md` §B（10 项）逐项检查。
+⛔ 执行 `opsx-tdd-core/checklist.md` §B（11 项）逐项检查。
 
 > 不在此内联复制，以 opsx-tdd-core/checklist.md §B 为唯一真相源。
 > 额外补充：还需检查 `opsx-tdd-rules/rules/exception-path-coverage.md`（异常路径覆盖门禁）。
 
+**检查项适用阶段**：§B 中部分检查项在 apply 前后均可验证（文档级），部分仅在 apply 后可验证（代码级）：
+- **apply 前可验证**（文档级）：RED 验收标准包含"测试运行失败"、无"断言为空"、GREEN 为行为级粒度、DAG 存在 RED→GREEN 循环对、非 TDD 模块未拆红绿、GREEN 验收标准为"让对应 RED 通过"、已声明 Controller 策略、Controller 两种策略都生成测试任务、每个 RED 含测试方法名、每个 GREEN 含 YAGNI 围栏、每个 REFACTOR 列出重构点
+- **apply 后可验证**（代码级）：GREEN 任务输出不含未测试的 Controller/Filter/Config
+
 ⛔ BEFORE 完成 TDD 合规性检查，如需深度审查测试质量，必须读取：
 - opsx-tdd-review/SKILL.md（测试质量审查清单 8 项 + 缺失测试检测）
 读取后确认："已读取测试质量审查清单"。

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

@@ -38,11 +38,15 @@ description: "opsx-check 阶段日志自检清单 — 仅在 check 自检时读
 
 ## E. TDD 合规性检查（仅 test-strategy=tdd 时）
 
-⛔ 执行 `opsx-tdd-core/checklist.md` §B（10 项）逐项检查。
+⛔ 执行 `opsx-tdd-core/checklist.md` §B（11 项）逐项检查。
 
 > 不在此内联复制，以 opsx-tdd-core/checklist.md §B 为唯一真相源。
 > 额外补充：还需检查 `opsx-tdd-rules/rules/exception-path-coverage.md`（异常路径覆盖门禁）。
 
+**检查项适用阶段**：
+- **apply 前可验证**（文档级）：§B 中除"GREEN 任务输出不含未测试的 Controller/Filter/Config"外的所有检查项（含 Controller 策略声明和测试任务生成）
+- **apply 后可验证**（代码级）："GREEN 任务输出不含未测试的 Controller/Filter/Config"
+
 ## F. 语义门禁与工作态
 
 - [ ] `openspec/changes/<变更名称>/artifact-index.json` 已覆盖当前全部 proposal/spec/design/tasks，且每份 `artifacts/*.ontology.json` 与 `working-ontology.json` revision 一致

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

@@ -34,6 +34,7 @@ description: opsx-spec 的阶段强制检查点与自检清单。仅在执行 sp
 - [ ] 已消费工程知识库 `answeredQuestions`，没有重复询问历史事实已经回答的问题
 - [ ] 仅将 `reuseMode=INHERIT` 的事实作为身份继承；`REFERENCE` 候选使用新实体身份
 - [ ] 已处理与当前 Capability 有关的 `clarificationQuestions`
+- [ ] ⛔ **多校验拆分（TDD 模式）**：当 test-strategy=tdd 时，单个 STMT 包含多个"必须校验"条件时，每个校验条件有对应的独立 AC 场景（规则见 `opsx-tdd-rules/rules/multi-validation-split.md`）
 
 **如有任意一项未满足，重新生成对应章节，直至全部通过。** 自检完成后必须输出结构化自检报告（模板见 `./reference.md`「§7 质量自检报告模板」），未通过项自动修复后重新输出。
 

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

@@ -153,6 +153,7 @@ Simple 模式或单文件能力域下，**不要拆成多个同文件任务**。
 > - RED 任务验收标准：测试运行失败，且失败原因正确（功能未实现）
 > - GREEN 任务验收标准：写最少代码让对应 RED 测试通过
 > - 非 TDD 模块（前端 UI、配置、SQL DDL）不拆红绿，按常规任务处理
+> - Controller 层必须选择策略 A（红绿循环）或策略 B（impl-first 接线测试），两种策略都生成测试
 >
 > 是否继续使用 TDD 策略？"
 
@@ -172,7 +173,7 @@ Simple 模式或单文件能力域下，**不要拆成多个同文件任务**。
 3. GREEN 验收标准必须包含"写最少代码让对应 RED 测试通过"，禁止捆绑
 4. GREEN 不得包含未测试的 Controller/Filter/Config
 5. 非 TDD 模块（前端 UI/配置/SQL DDL）不拆红绿
-6. Controller 层策略必须在 tasks.md §2.0 中声明（策略 A 或 B）
+6. Controller 层策略必须在 tasks.md §2.0 中声明（策略 A 或 B），两种策略都必须生成测试任务
 7. ⛔ **GREEN 任务 YAGNI 围栏**：每个 GREEN-N 任务描述末尾必须包含"不提前实现 [后续 RED 行为]"围栏声明。规则详见 `opsx-tdd-rules/rules/green-yagni-fence.md`
 
 ⛔ BEFORE 生成 TDD 任务，必须读取：

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

@@ -36,7 +36,7 @@ description: opsx-task 的阶段强制检查点与自检清单。仅在执行 ta
 
 ## §8.1 TDD 合规性自检（仅 test-strategy=tdd 时）
 
-⛔ 执行 `opsx-tdd-core/checklist.md` §B（10 项）逐项检查。
+⛔ 执行 `opsx-tdd-core/checklist.md` §B（11 项）逐项检查。
 
 > 不在此内联复制，以 opsx-tdd-core/checklist.md §B 为唯一真相源。
 > 额外补充：还需检查 `opsx-tdd-rules/rules/exception-path-coverage.md`（异常路径覆盖门禁）——每个 orElseThrow/边界检查须有对应 RED 任务。

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

@@ -62,7 +62,7 @@ spec.md user-auth 定义了 7 个场景，拆为 7 对 RED+GREEN + 1 个 REFACTO
 
 ### Controller 层处理示例
 
-**策略 A：Controller 也拆 RED→GREEN（推荐，适合接口数量少时）**
+**策略 A：Controller 也拆 RED→GREEN（适合 Controller 含业务逻辑时）**
 
 | 任务 ID | 行为点 | 类型 | 依赖 | 验收标准 |
 |---------|--------|------|------|---------|
@@ -73,13 +73,14 @@ spec.md user-auth 定义了 7 个场景，拆为 7 对 RED+GREEN + 1 个 REFACTO
 | TASK-05-RED-10 | POST /auth/logout 返回成功 | 测试-RED | TASK-05-GREEN-6 | 测试失败 |
 | TASK-05-GREEN-10 | AuthController.logout() 实现 | 实现-GREEN | TASK-05-RED-10 | 只实现 logout 接口 |
 
-**策略 B：Controller 作为非 TDD 任务（适合接口数量多时）**
+**策略 B：Controller 先接线，再写 @WebMvcTest 验证（适合 Controller 为纯接线时）**
 
 | 任务 ID | 行为点 | 类型 | 依赖 | 验收标准 |
 |---------|--------|------|------|---------|
-| TASK-05-CTRL | AuthController 3 个接口接线 | 接口层 | TASK-05-GREEN-6 | Controller 编译通过，调用对应 Service 方法，返回 Result 统一响应体 |
+| TASK-05-CTRL-IMPL | AuthController 3 个接口接线 | 接口层 | TASK-05-GREEN-6 | Controller 编译通过，调用对应 Service 方法，返回 Result 统一响应体 |
+| TASK-05-CTRL-TEST | AuthController HTTP 契约验证 | 接口测试 | TASK-05-CTRL-IMPL | @WebMvcTest 通过：URL 映射正确、请求体绑定正确、响应 JSON 结构正确、错误响应正确 |
 
-注意：策略 B 中 Controller 任务不是 GREEN，不对应任何 RED 测试，仅做编译检查。
+注意：策略 B 中 Controller 任务不是 GREEN，不对应 RED 测试。但**必须生成 CTRL-TEST 任务**，使用 @WebMvcTest 验证 HTTP 契约（URL 映射、请求绑定、响应结构、错误处理）。策略 B 本质是对 Controller 层单独应用 impl-first 模式。
 
 ---
 
@@ -92,7 +93,8 @@ spec.md user-auth 定义了 7 个场景，拆为 7 对 RED+GREEN + 1 个 REFACTO
 - 项目脚手架/配置（pom.xml, application.yml）→ 配置任务
 - 数据库迁移脚本（SQL DDL）→ 数据层任务
 - 前端路由/状态管理/API 封装 → UI层任务
-- Controller 层（可选）→ 接口层任务（当选择策略 B 时，Controller 作为接线层不拆红绿）
+
+> Controller 层不属于非 TDD 模块，必须通过策略 A（TDD 红绿循环）或策略 B（impl-first 接线测试）生成测试。
 
 ⚠️ Controller 层处理策略需在 tasks.md §2.0 中明确声明，不能默认选择。
 

package/templates/skills/kld-sdd/opsx-tdd-anti-patterns/SKILL.md

@@ -58,6 +58,11 @@ BEFORE 编写测试代码：
   1. "我在测试真实组件行为还是仅测试 mock 存在？" → 如果仅测试 mock 存在，停止
   2. "我的 Given 是真实数据还是 mock 出的预定结论？" → 如果是预定结论，重写
   3. "我是否完全理解被 mock 依赖的副作用？" → 如果不理解，先理解再 mock
+
+AFTER GREEN（GREEN 完成后、标记通过前）：
+  4. "测试是否有真实断言（assertEquals/assertThrows），而非仅 assertNotNull？" → 如果只有弱断言，补充具体值断言
+  5. "单个测试 mock 了几个依赖？" → 如果 >5 个，拆分测试或减少依赖
+  6. "正常路径有测试，异常路径呢？" → 每个 orElseThrow/边界检查须有对应测试
 ```
 
 ## §6 红旗列表

package/templates/skills/kld-sdd/opsx-tdd-core/SKILL.md

@@ -37,6 +37,38 @@ RED → Verify RED → 🔴中断声明 → GREEN → Verify GREEN → GREEN Sco
 - **RED**：写一个最小的失败测试，展示期望行为
   - 一个行为、清晰名称、真实代码（除非不可避免否则不用 mock）
   - ⛔ **只写当前 RED 对应的测试方法**，不提前写后续 RED 的测试
+
+  <Good>
+  ```java
+  // ✅ 一个行为、清晰名称、真实断言
+  @Test
+  void login_validCredentials_returnsToken() {
+      // Given
+      UserMapper mapper = mock(UserMapper.class);
+      when(mapper.findByUsername("admin")).thenReturn(testUser);
+      AuthService service = new AuthService(mapper);
+
+      // When
+      Token result = service.login("admin", "password123");
+
+      // Then
+      assertNotNull(result);
+      assertNotNull(result.getAccessToken());
+  }
+  ```
+  </Good>
+
+  <Bad>
+  ```java
+  // ❌ 模糊名称、测试 mock 而非真实行为
+  @Test
+  void testLogin() {
+      when(mapper.findByUsername(any())).thenReturn(testUser);
+      service.login("admin", "password123");
+      verify(mapper).findByUsername("admin"); // 只验证 mock 被调用
+  }
+  ```
+  </Bad>
 - **Verify RED**（强制执行，绝不跳过）：
   - 确认测试失败（不是报错）
   - 失败信息符合预期
@@ -55,6 +87,32 @@ RED → Verify RED → 🔴中断声明 → GREEN → Verify GREEN → GREEN Sco
     3. 标记步骤归属（✅ 属于当前 RED / ⛔ 属于后续 RED）
     4. 仅实现标记为 ✅ 的步骤
   - ⛔ **逐条确认 YAGNI 围栏**：读取 tasks.md 中本 GREEN 任务的 YAGNI 围栏声明，逐条确认"未实现 [后续 RED 的行为]：✅"
+
+  <Good>
+  ```java
+  // ✅ RED 只断言了 login 返回 Token，GREEN 只实现到返回 Token
+  public Token login(String username, String password) {
+      User user = userMapper.findByUsername(username);
+      return new Token(jwtUtil.generate(user.getId()));
+  }
+  ```
+  </Good>
+
+  <Bad>
+  ```java
+  // ❌ RED 只断言了 login 返回 Token，GREEN 却同时实现了密码校验（后续 RED 的行为）
+  public Token login(String username, String password) {
+      User user = userMapper.findByUsername(username);
+      if (!passwordEncoder.matches(password, user.getPassword())) {
+          throw new BusinessException(2001, "密码错误"); // 越界！后续 RED 才需要
+      }
+      if (user.getStatus() == UserStatus.DISABLED) {
+          throw new BusinessException(2002, "账号禁用"); // 越界！后续 RED 才需要
+      }
+      return new Token(jwtUtil.generate(user.getId()));
+  }
+  ```
+  </Bad>
 - **Verify GREEN**（强制执行）：
   - 确认测试通过
   - 其他测试仍通过
@@ -95,10 +153,12 @@ RED → Verify RED → 🔴中断声明 → GREEN → Verify GREEN → GREEN Sco
 
 > 完整规则见 `opsx-tdd-rules/rules/controller-strategy.md`，此处仅保留快速参考。
 
-| 策略 | 说明 | 适用 |
-|------|------|------|
-| 策略 A | 为每个 Controller 接口生成 RED 测试（@WebMvcTest），拆为 RED→GREEN 对 | Controller 含业务逻辑 |
-| 策略 B | Controller 作为非 TDD 模块，独立接口层任务，仅做编译检查 | Controller 为纯接线（调用 Service + 返回 Result） |
+⛔ Controller 层**必须**有测试。两种策略的区别在于测试方式，而非"有无测试"。
+
+| 策略 | 说明 | 适用 | 测试方式 |
+|------|------|------|----------|
+| 策略 A | Controller 拆 RED→GREEN（@WebMvcTest） | Controller 含业务逻辑 | TDD 红绿循环 |
+| 策略 B | Controller 先接线，再写 @WebMvcTest 验证 | Controller 为纯接线（调用 Service + 返回 Result） | impl-first：CTRL-IMPL → CTRL-TEST |
 
 必须在 tasks.md §2.0 中声明使用哪种策略。
 

package/templates/skills/kld-sdd/opsx-tdd-core/checklist.md

@@ -24,7 +24,7 @@ description: "opsx-tdd-core 自检清单 — TDD 执行合规自检、合规性
 - [ ] REFACTOR 后全部测试仍绿
 - [ ] 未出现"先写生产代码再补测试"的情况
 
-## §B TDD 合规性检查（10 项）
+## §B TDD 合规性检查（11 项）
 
 仅 `test-strategy=tdd` 时执行：
 
@@ -36,7 +36,9 @@ description: "opsx-tdd-core 自检清单 — TDD 执行合规自检、合规性
 - [ ] GREEN 任务验收标准为"让对应 RED 通过"（而非"实现完整功能"）
 - [ ] GREEN 任务输出不含未测试的 Controller/Filter/Config
 - [ ] 已声明 Controller 层处理策略（策略 A 或 B）
+- [ ] Controller 层两种策略都生成了测试任务（策略 A: RED→GREEN 对；策略 B: CTRL-IMPL → CTRL-TEST）
 - [ ] 每个 RED 任务包含测试方法名（`{method}_{state}_{outcome}` 格式）
+- [ ] 每个 GREEN 任务包含 YAGNI 围栏声明（"不提前实现 [后续 RED 行为]"）
 - [ ] 每个 REFACTOR 任务列出至少 2 个具体重构点
 
 ## §C 完成验证清单（8 项）

package/templates/skills/kld-sdd/opsx-tdd-core/reference.md

@@ -82,16 +82,19 @@ description: "opsx-tdd-core 详细参考 — 执行步骤、拆分示例、DAG
 
 **策略 A**（Controller 拆 RED→GREEN，使用 @WebMvcTest）：
 
-| TASK-ID | 行为点 | 类型 | 验收标准 |
-|---------|--------|------|---------|
-| TASK-CTRL-RED-1 | POST /api/v1/auth/login 返回 Token | 测试-RED | @WebMvcTest 测试运行失败 |
-| TASK-CTRL-GREEN-1 | AuthController 接线 | 实现-GREEN | RED 测试通过 |
+| TASK-ID | 行为点 | 类型 | 依赖 | 验收标准 |
+|---------|--------|------|------|---------|
+| TASK-CTRL-RED-1 | POST /api/v1/auth/login 返回 Token | 测试-RED | TASK-05-GREEN-1 | @WebMvcTest 测试运行失败，失败原因：Controller 未实现 |
+| TASK-CTRL-GREEN-1 | AuthController.login() 接线 | 实现-GREEN | TASK-CTRL-RED-1 | RED 测试通过 |
+
+**策略 B**（Controller 先接线，再写 @WebMvcTest 验证）：
 
-**策略 B**（Controller 作为非 TDD 任务）：
+| TASK-ID | 行为点 | 类型 | 依赖 | 验收标准 |
+|---------|--------|------|------|---------|
+| TASK-CTRL-IMPL | AuthController 3 个接口接线 | 接口层 | TASK-05-GREEN-6 | Controller 编译通过，调用对应 Service 方法，返回 Result |
+| TASK-CTRL-TEST | AuthController HTTP 契约验证 | 接口测试 | TASK-CTRL-IMPL | @WebMvcTest 通过：URL 映射、请求绑定、响应 JSON 结构、错误处理 |
 
-| TASK-ID | 类型 | 验收标准 |
-|---------|------|---------|
-| TASK-CTRL | 接口层（非 TDD） | Controller 编译通过，调用对应 Service 方法，返回 Result |
+> 策略 B 本质是对 Controller 层单独应用 impl-first 模式：先实现接线，再写测试验证 HTTP 契约。
 
 ## §6 DAG 生成规则
 
@@ -112,7 +115,8 @@ description: "opsx-tdd-core 详细参考 — 执行步骤、拆分示例、DAG
 - 项目脚手架/配置 → 配置任务
 - 数据库迁移脚本（SQL DDL）→ 数据层任务
 - 前端路由/状态管理/API 封装 → UI层任务
-- Controller 层（可选）→ 接口层任务（当选择策略 B 时）
+
+> Controller 层不属于非 TDD 模块，必须通过策略 A 或策略 B 生成测试。
 
 ## §8 Telemetry 模板
 

package/templates/skills/kld-sdd/opsx-tdd-metrics/SKILL.md

@@ -7,6 +7,7 @@ description: "度量分析层 — 测试质量量化度量：隔离评分、命
 
 > **定位**：测试质量的量化度量，提供可计算的评分。
 > **参考来源**：tdd-guide `metrics_calculator.py`
+> **引用方式**：**可选引用**。本技能不参与强制流程，仅在需要量化评估测试质量时按需读取。`opsx-check` 和 `opsx-apply` 的强制检查引用 `opsx-tdd-core/checklist.md` 和 `opsx-tdd-review`，不引用本技能。
 
 ---
 

package/templates/skills/kld-sdd/opsx-tdd-review/SKILL.md

@@ -64,3 +64,42 @@ description: "测试审查层 — 从审查者角度检测'测试通过但没测
 | 不确定 | 举证责任在期望方（默认 FAIL） |
 
 > 不给予部分分数。每个断言要么通过要么失败。
+
+## §7 子代理审查提示模板
+
+> 当 `opsx-apply` 在 GREEN 任务完成后派发独立审查子代理时使用此模板。参考 Superpowers `subagent-driven-development` 的 task-reviewer 模式：implementer 自审查 ≠ 独立审查。
+
+```
+Agent (general-purpose):
+  description: "TDD 审查任务 [TASK-ID]: [任务描述]"
+  prompt: |
+    你是 TDD 测试质量审查者。你的职责是审查 implementer 的测试代码和实现代码，
+    检测"测试通过但没测到关键点"的问题。
+
+    ## 审查范围
+
+    - 任务 ID: [TASK-ID]
+    - 任务类型: [测试-RED / 实现-GREEN / 重构-REFACTOR]
+    - 审审查文件: [implementer 修改的文件列表]
+
+    ## 审查清单
+
+    执行 opsx-tdd-review/SKILL.md §3（8 项质量审查）+ §4（缺失测试检测）+ §5（测试异味检测）。
+    对于 GREEN 任务，额外检查：
+    - GREEN Scope: 生产代码中是否有未被当前 RED 断言覆盖的逻辑分支？
+    - YAGNI 围栏: 是否提前实现了后续 RED 的行为？
+    - 反模式: 执行 opsx-tdd-anti-patterns/SKILL.md §4（12 种 GREEN 后反模式）
+
+    ## 审查标准
+
+    - PASS: 需明确证据且证据反映真实任务完成
+    - FAIL: 无证据、证据矛盾、证据表面化、巧合满足
+    - 不确定: 举证责任在期望方（默认 FAIL）
+
+    ## 报告格式
+
+    - **审查结果**: PASS / FAIL / 不确定
+    - **通过项**: [列表]
+    - **失败项**: [列表，含具体文件:行号和问题描述]
+    - **建议修复**: [具体修复方案]
+```

package/templates/skills/kld-sdd/opsx-tdd-rules/rules/controller-strategy.md

@@ -2,30 +2,52 @@
 
 > 影响等级：HIGH
 
-## 策略 A：拆 RED→GREEN
+## 核心原则
+
+Controller 层**必须**有测试。两种策略的区别在于测试方式（TDD 红绿循环 vs impl-first 验证），而非"有无测试"。
+
+## 策略 A：TDD 红绿循环
 
 为每个 Controller 接口生成 RED 测试（使用 @WebMvcTest），拆为 RED→GREEN 对。
 
-适用：Controller 含业务逻辑。
+适用：Controller 含业务逻辑（参数校验、条件转发、响应转换等）。
 
 示例任务表：
 
-| TASK-ID | 行为点 | 类型 | 验收标准 |
-|---------|--------|------|---------|
-| CTRL-RED-1 | POST /api/v1/auth/login 返回 Token | 测试-RED | @WebMvcTest 测试运行失败 |
-| CTRL-GREEN-1 | AuthController 接线 | 实现-GREEN | RED 测试通过 |
+| TASK-ID | 行为点 | 类型 | 依赖 | 验收标准 |
+|---------|--------|------|------|---------|
+| CTRL-RED-1 | POST /api/v1/auth/login 返回 Token | 测试-RED | GREEN-Service | @WebMvcTest 测试运行失败，失败原因：Controller 未实现 |
+| CTRL-GREEN-1 | AuthController.login() 接线 | 实现-GREEN | CTRL-RED-1 | RED 测试通过 |
 
-## 策略 B：非 TDD 接线任务
+## 策略 B：Impl-First 接线测试
 
-Controller 作为非 TDD 模块，独立接口层任务，仅做编译检查。
+Controller 先实现接线，再写 @WebMvcTest 验证 HTTP 契约。不拆 RED→GREEN 循环，但**必须生成测试任务**。
 
 适用：Controller 为纯接线（调用 Service + 返回 Result）。
 
 示例任务表：
 
-| TASK-ID | 类型 | 验收标准 |
-|---------|------|---------|
-| CTRL | 接口层（非 TDD） | Controller 编译通过，调用对应 Service 方法，返回 Result |
+| TASK-ID | 行为点 | 类型 | 依赖 | 验收标准 |
+|---------|--------|------|------|---------|
+| CTRL-IMPL | AuthController 3 个接口接线 | 接口层 | GREEN-Service | Controller 编译通过，调用对应 Service 方法，返回 Result |
+| CTRL-TEST | AuthController HTTP 契约验证 | 接口测试 | CTRL-IMPL | @WebMvcTest 通过：URL 映射正确、请求体绑定正确、响应 JSON 结构正确、错误响应正确 |
+
+### 策略 B 测试范围
+
+@WebMvcTest 必须覆盖以下 HTTP 契约点：
+
+1. **URL 映射**：请求路径和 HTTP 方法正确
+2. **请求绑定**：`@RequestBody`/`@RequestParam`/`@PathVariable` 正确反序列化
+3. **响应结构**：`jsonPath()` 断言响应 JSON 字段
+4. **状态码**：200/201/400/401/403/404 等正确返回
+5. **错误处理**：`@ControllerAdvice`/`@ExceptionHandler` 响应正确
+
+### 策略 B 与 impl-first 的关系
+
+策略 B 本质上是**对 Controller 层单独应用 impl-first 模式**：
+- 实现任务在前（CTRL-IMPL）
+- 测试任务 Depends-On 实现任务（CTRL-TEST）
+- 测试使用 @WebMvcTest（非 @SpringBootTest）
 
 ## 声明要求
 

package/templates/skills/kld-sdd/opsx-tdd-rules/rules/dag-generation-rules.md

@@ -18,3 +18,16 @@
 4. GREEN 任务依赖对应的 RED 任务
 5. 可选每 3-5 个行为点后插入 REFACTOR
 6. 模块末尾可保留 VERIFY 任务
+
+## Controller 层 DAG 规则
+
+Controller 层根据策略生成不同的 DAG 结构：
+
+| 策略 | DAG 结构 | 说明 |
+|------|----------|------|
+| 策略 A | CTRL-RED → CTRL-GREEN | 与 Service 层相同的红绿循环 |
+| 策略 B | CTRL-IMPL → CTRL-TEST | impl-first 模式：先接线，再测试 |
+
+- 策略 A 的 CTRL-RED 依赖对应 Service 的 GREEN 任务
+- 策略 B 的 CTRL-IMPL 依赖对应 Service 的 GREEN 任务
+- 两种策略都生成测试任务，区别是测试时序（先测试 vs 先实现）

package/templates/skills/kld-sdd/opsx-tdd-rules/rules/non-tdd-modules.md

@@ -10,8 +10,9 @@
 - 项目脚手架/配置 → 配置任务
 - 数据库迁移脚本（SQL DDL）→ 数据层任务
 - 前端路由/状态管理/API 封装 → UI层任务
-- Controller 层（可选）→ 接口层任务（当选择策略 B 时）
 
-## Controller 层处理策略
+## Controller 层说明
 
-Controller 层处理策略需在 tasks.md §2.0 中明确声明，不能默认选择。
+Controller 层**不属于**非 TDD 模块。Controller 必须有测试，通过策略 A（TDD 红绿循环）或策略 B（impl-first 接线测试）实现。
+
+> Controller 策略选择见 `opsx-tdd-rules/rules/controller-strategy.md`，必须在 tasks.md §2.0 中声明。

package/templates/skills/kld-sdd/opsx-tdd-rules/rules/task-type-definitions.md

@@ -11,6 +11,13 @@
 | 重构-REFACTOR | 测试全绿下的代码清理 | 所有测试仍绿，代码结构改善 |
 | 测试-验证 | 全量测试运行验证 | 全部测试通过 |
 
+## Controller 策略 B 任务类型
+
+| 类型 | 说明 | 验收标准要求 |
+|------|------|-------------|
+| 接口层 | Controller 接线实现 | Controller 编译通过，调用对应 Service 方法，返回 Result |
+| 接口测试 | Controller HTTP 契约验证 | @WebMvcTest 通过：URL 映射、请求绑定、响应结构、错误处理 |
+
 ## RED 任务额外必填字段
 
 - 测试方法名（`{method}_{state}_{outcome}` 格式）

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

@@ -146,7 +146,7 @@ node skywalk-sdd/log.cjs record --type=test_result --command=test --project=. --
 - [ ] 无"生产类中加测试专用方法"
 - [ ] 无"不理解依赖就 mock"
 
-> 完整 5 项反模式检测见 opsx-tdd-anti-patterns/SKILL.md §4
+> 完整 12 项反模式检测见 opsx-tdd-anti-patterns/SKILL.md §4
 > TDD 报告模式见 opsx-tdd-review/SKILL.md §3
 
 ### 6. 【交互引导】根据结果引导下一步