kld-sdd 2.6.1 → 2.6.2

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

@@ -18,6 +18,8 @@ description: opsx-task 的详细模板：telemetry 命令、DAG 生成规则表
 
 ## §6 DAG 生成规则表
 
+> 完整规则见 `opsx-tdd-rules/rules/dag-generation-rules.md`，此处仅保留快速参考。
+
 **根据 test-strategy 调整 DAG 生成规则：**
 
 | test-strategy | DAG 生成规则 |
@@ -37,19 +39,21 @@ spec.md user-auth 定义了 7 个场景，拆为 7 对 RED+GREEN + 1 个 REFACTO
 | 任务 ID | 行为点 | 类型 | 依赖 | 验收标准 |
 |---------|--------|------|------|---------|
 | TASK-05-RED-1 | 登录成功返回 Token | 测试-RED | TASK-04-IMPL | 测试带断言运行失败，失败原因：AuthService 未实现 |
-| TASK-05-GREEN-1 | 登录成功最小实现 | 实现-GREEN | TASK-05-RED-1 | 写最少代码让 RED-1 通过，不提前实现密码校验等 |
+| TASK-05-GREEN-1 | 登录成功最小实现 | 实现-GREEN | TASK-05-RED-1 | 写最少代码让 RED-1 通过。不提前实现密码校验（RED-2 的行为），仅让当前 RED 测试通过。 |
 | TASK-05-RED-2 | 密码错误返回 2001 | 测试-RED | TASK-05-GREEN-1 | 测试失败，失败原因：未校验密码 |
-| TASK-05-GREEN-2 | 密码校验实现 | 实现-GREEN | TASK-05-RED-2 | 让 RED-2 通过 |
+| TASK-05-GREEN-2 | 密码校验实现 | 实现-GREEN | TASK-05-RED-2 | 让 RED-2 通过。不提前实现账号状态校验（RED-3 的行为），仅让当前 RED 测试通过。 |
 | TASK-05-RED-3 | 账号禁用返回 2002 | 测试-RED | TASK-05-GREEN-2 | 测试失败 |
-| TASK-05-GREEN-3 | 账号状态校验 | 实现-GREEN | TASK-05-RED-3 | 让 RED-3 通过 |
+| TASK-05-GREEN-3 | 账号状态校验 | 实现-GREEN | TASK-05-RED-3 | 让 RED-3 通过。不提前实现 Refresh Token（RED-4 的行为），仅让当前 RED 测试通过。 |
 | TASK-05-RED-4 | Refresh Token 有效 | 测试-RED | TASK-05-GREEN-3 | 测试失败 |
-| TASK-05-GREEN-4 | Refresh 实现 | 实现-GREEN | TASK-05-RED-4 | 让 RED-4 通过 |
+| TASK-05-GREEN-4 | Refresh 实现 | 实现-GREEN | TASK-05-RED-4 | 让 RED-4 通过。不提前实现 Refresh Token 无效校验（RED-5 的行为），仅让当前 RED 测试通过。 |
 | TASK-05-RED-5 | Refresh Token 无效返回 3001 | 测试-RED | TASK-05-GREEN-4 | 测试失败 |
-| TASK-05-GREEN-5 | Refresh 校验实现 | 实现-GREEN | TASK-05-RED-5 | 让 RED-5 通过 |
+| TASK-05-GREEN-5 | Refresh 校验实现 | 实现-GREEN | TASK-05-RED-5 | 让 RED-5 通过。不提前实现登出功能（RED-6 的行为），仅让当前 RED 测试通过。 |
 | TASK-05-RED-6 | 登出加入黑名单 | 测试-RED | TASK-05-GREEN-5 | 测试失败 |
-| TASK-05-GREEN-6 | 登出实现 | 实现-GREEN | TASK-05-RED-6 | 让 RED-6 通过 |
+| TASK-05-GREEN-6 | 登出实现 | 实现-GREEN | TASK-05-RED-6 | 让 RED-6 通过。仅实现当前 RED 测试覆盖的行为路径，不提前实现后续 capability 的功能。 |
 | TASK-05-REFACTOR | 重构优化 | 重构-REFACTOR | TASK-05-GREEN-6 | 所有测试仍绿，代码清理 |
 
+> GREEN 任务的 YAGNI 围栏生成规则详见 `opsx-tdd-rules/rules/green-yagni-fence.md`
+
 **关键区别**：
 - 每个 RED 任务都带**真实断言**，跑起来确实失败
 - 每个 GREEN 任务只写**让当前测试通过的最少代码**
@@ -81,6 +85,8 @@ spec.md user-auth 定义了 7 个场景，拆为 7 对 RED+GREEN + 1 个 REFACTO
 
 ## §6.2 非 TDD 模块处理规则
 
+> 完整规则见 `opsx-tdd-rules/rules/non-tdd-modules.md`，此处仅保留快速参考。
+
 以下模块不需要红绿循环，按常规任务处理：
 - 前端 UI 页面（Vue 组件）→ UI层任务
 - 项目脚手架/配置（pom.xml, application.yml）→ 配置任务

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

@@ -0,0 +1,79 @@
+---
+name: opsx-tdd-anti-patterns
+description: "测试反模式防护层 — 15 种反模式检测（RED 阶段 3 种 + GREEN 后 12 种），每种带门禁函数和修复方案。当编写或审查测试代码时引用本技能。"
+---
+
+# opsx-tdd-anti-patterns — 反模式防护层
+
+> **定位**：测试反模式的系统化检测，RED 阶段 + GREEN 后双重检查。
+> **参考来源**：Superpowers `testing-anti-patterns.md`
+
+---
+
+## §1 核心原则
+
+> 测试必须验证真实行为，而非 mock 行为。Mock 是隔离的手段，不是被测试的对象。
+
+> 遵循严格 TDD 可以防止这些反模式。
+
+## §2 三条铁律
+
+1. **NEVER test mock behavior** — 永远不要测试 mock 行为
+2. **NEVER add test-only methods to production classes** — 永远不要向生产类添加测试专用方法
+3. **NEVER mock without understanding dependencies** — 永远不要在不理解依赖的情况下 mock
+
+## §3 RED 阶段反模式（3 种）
+
+⛔ RED 阶段就必须检查，不要等到 GREEN 之后才发现测试是假的。
+
+| # | 反模式 | 问题表现 | 门禁函数 | 修复方案 |
+|---|--------|---------|---------|---------|
+| 1 | **Mock 被测行为本身** | `when(jwtUtil.parseToken("invalid")).thenThrow(...)` — mock 了被测行为（解析失败），GREEN 只需加 try-catch | "我在测试真实组件行为还是仅测试 mock 存在？" | 使用真实 JwtUtil + 真实 invalid token，让解析自然失败 |
+| 2 | **Mock 预定结论而非准备条件** | `when(bookMapper.countByPublisher(1L)).thenReturn(3)` 后只测 `if (count > 0) throw` — trivial 逻辑 | "我的测试是在验证完整行为链路，还是只验证一个 if 分支？" | Mock 边界依赖（Mapper）是合理的，但测试断言应验证完整行为链路（如 verify 不会执行 delete） |
+| 3 | **Given 不是真实输入** | mock 出"这个输入会导致什么结果"，而非传入真实数据让被测代码自行处理 | "我的 Given 是真实数据还是 mock 出的预定结论？" | 传入真实数据（如 `"invalid"` 字符串、`null`、空对象），让被测代码自行决定结果 |
+
+## §4 GREEN 后反模式（12 种）
+
+| # | 反模式 | 问题表现 | 修复方案 |
+|---|--------|---------|---------|
+| 4 | **测试 mock 行为而非真实行为** | 测试验证的是 mock 被调用，而非真实业务逻辑 | 测试应验证输出/状态变化，而非方法调用 |
+| 5 | **生产类中加测试专用方法** | 为方便测试在生产类中加了 public/protected 方法 | 通过公共 API 测试，不加测试专用方法 |
+| 6 | **不理解依赖就 mock** | mock 了不理解的依赖，隐藏了结构假设 | 先理解依赖的职责再决定是否 mock |
+| 7 | **不完整的 mock** | partial mock 隐藏了对象间的结构关系 | 要么完整 mock，要么用真实对象 |
+| 8 | **集成测试作为事后补充** | 单元测试不足，用集成测试弥补 | 每个行为点应有独立的单元测试 |
+| 9 | **测试通过但无真实断言** | 测试只有 `assertTrue(true)` 或无断言 | 测试必须有真实断言（assertNotNull/assertEquals/assertThrows/verify） |
+| 10 | **过度 mock** | 单个测试 mock 了 >5 个依赖，测试脆弱且难以维护 | 减少依赖数量，或拆分为多个聚焦的测试 |
+| 11 | **测试间隐式依赖** | 测试 B 依赖测试 A 的副作用（如数据库状态残留） | 每个测试自包含，`@BeforeEach` 重置状态 |
+| 12 | **测试代码重复** | 大量 copy-paste 的测试代码，缺少 helper 提取 | 提取 test fixture builder 或 helper 方法 |
+| 13 | **魔法值** | 测试中使用未解释的字面值（如 `assertEquals(42, result)` 无注释说明 42 的含义） | 使用命名常量或注释解释字面值含义 |
+| 14 | **断言不足** | 只断言了部分结果，遗漏了关键属性（如只 assertNotNull 但不 assertEquals 具体值） | 每个测试至少有一个具体值断言（assertEquals），而非仅 assertNotNull |
+| 15 | **缺少负面测试** | 只测试正常路径，不测试错误条件 | 每个方法至少有一个异常路径测试（见 `opsx-tdd-rules/rules/exception-path-coverage.md`） |
+
+## §5 门禁函数
+
+每种反模式对应一个自检问题，在编写测试时强制自问：
+
+```
+BEFORE 编写测试代码：
+  1. "我在测试真实组件行为还是仅测试 mock 存在？" → 如果仅测试 mock 存在，停止
+  2. "我的 Given 是真实数据还是 mock 出的预定结论？" → 如果是预定结论，重写
+  3. "我是否完全理解被 mock 依赖的副作用？" → 如果不理解，先理解再 mock
+```
+
+## §6 红旗列表
+
+以下信号出现时，测试可能存在反模式：
+
+- 断言检查 `*-mock` 测试 ID
+- 仅在测试文件中调用的方法
+- Mock 设置占测试的 >50%
+- 移除 mock 后测试失败
+- 无法解释为什么需要 mock
+- "为了安全"而 mock
+- 测试立即通过（RED 阶段）
+- 无法解释测试为何失败
+- 单个测试 mock >5 个依赖
+- 测试方法名包含 "and"（多行为混合）
+- 测试中只有 `assertNotNull` 无具体值断言
+- 测试中存在未解释的魔法数字/字符串
+- 正常路径有测试但异常路径无测试

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

@@ -0,0 +1,203 @@
+---
+description: "opsx-tdd-anti-patterns 详细参考 — 9 种反模式完整详表 + 修复方案代码示例。仅在需要详细反模式检查时读取。"
+---
+
+# opsx-tdd-anti-patterns — 详细参考
+
+> 仅在需要详细反模式检查时读取。日常检查见 `SKILL.md`。
+
+---
+
+## 反模式 1：Mock 被测行为本身
+
+**问题**：验证 mock 是否存在，而非组件是否正常工作。
+
+**反例**：
+```java
+@Mock
+private JwtUtil jwtUtil;
+
+@Test
+void refresh_invalidToken_returns3001() {
+    when(jwtUtil.parseToken("invalid")).thenThrow(new RuntimeException());
+    // GREEN 只需加 try-catch 就通过，测试无意义
+    assertThrows(BusinessException.class, () -> authService.refresh("invalid"));
+}
+```
+
+**正例**：
+```java
+private JwtUtil jwtUtil; // 真实实例
+
+@BeforeEach
+void setUp() {
+    jwtUtil = new JwtUtil("real-secret-key-at-least-256-bits-long", 7200, 604800);
+    authService = new AuthService(userMapper, jwtUtil);
+}
+
+@Test
+void refresh_invalidToken_returns3001() {
+    // 传入真实无效 token，让 JwtUtil.parseToken 自然抛异常
+    assertThrows(BusinessException.class, () -> authService.refresh("invalid-token-string"));
+}
+```
+
+## 反模式 2：Mock 预定结论而非准备条件
+
+**问题**：mock 出期望的中间结果，测试只验证 trivial 逻辑。
+
+**反例**：
+```java
+when(bookMapper.countByPublisher(1L)).thenReturn(3);
+publisherService.delete(1L);
+// 只测了 if (count > 0) throw，trivial 逻辑
+```
+
+**正例**：
+```java
+when(bookMapper.countByPublisher(1L)).thenReturn(3);
+assertThrows(BusinessException.class, () -> publisherService.delete(1L));
+// 验证完整行为链路：抛异常且不执行 delete
+verify(publisherMapper, never()).update(any());
+```
+
+## 反模式 3：Given 不是真实输入
+
+**问题**：mock 出"这个输入会导致什么结果"，而非传入真实数据。
+
+**反例**：
+```java
+when(parseToken("invalid")).thenThrow(); // 预定了"invalid 会导致抛异常"这个结论
+```
+
+**正例**：
+```java
+// 传入 "invalid" 字符串，让真实的 parseToken 自行决定是否失败
+authService.refresh("invalid");
+```
+
+## 反模式 4：测试 mock 行为而非真实行为
+
+**问题**：测试验证的是 mock 被调用，而非真实业务逻辑。
+
+**反例**：
+```java
+verify(jwtUtil).parseToken(any()); // 只验证 mock 被调用
+```
+
+**正例**：
+```java
+assertNotNull(result.getAccessToken()); // 验证输出/状态变化
+```
+
+## 反模式 5：生产类中加测试专用方法
+
+**问题**：为方便测试在生产类中加了 public/protected 方法。
+
+**修复**：通过公共 API 测试，不加测试专用方法。如果需要测试内部逻辑，提取为独立类。
+
+## 反模式 6：不理解依赖就 mock
+
+**问题**：mock 了不理解的依赖，隐藏了结构假设。
+
+**门禁函数**：在 mock 任何方法之前，先问三个问题：
+1. "真实方法有什么副作用？"
+2. "此测试是否依赖这些副作用？"
+3. "我是否完全理解此测试需要什么？"
+
+## 反模式 7：不完整的 mock
+
+**问题**：partial mock 隐藏了结构假设，下游代码可能依赖未包含的字段。
+
+**铁律**：Mock 完整的数据结构，如同现实中存在的那样。
+
+## 反模式 8：集成测试作为事后补充
+
+**问题**：测试是实现的一部分，不是可选的后续步骤。
+
+**修复**：TDD 循环——写失败测试 → 实现通过 → 重构 → 然后声称完成。
+
+## 反模式 9：测试通过但无真实断言
+
+**问题**：测试只有 `assertTrue(true)` 或无断言。
+
+**修复**：测试必须有真实断言（assertNotNull/assertEquals/assertThrows/verify）。
+
+## 反模式 10：过度 mock
+
+**问题**：单个测试 mock 了 >5 个依赖，测试脆弱且难以维护。
+
+**反例**：
+```java
+@Mock private UserMapper userMapper;
+@Mock private BookMapper bookMapper;
+@Mock private PublisherMapper publisherMapper;
+@Mock private AuthorMapper authorMapper;
+@Mock private CategoryMapper categoryMapper;
+@Mock private BorrowMapper borrowMapper;
+// 6 个 mock，测试脆弱
+```
+
+**修复**：减少依赖数量，或拆分为多个聚焦的测试。考虑使用真实对象替代部分 mock。
+
+## 反模式 11：测试间隐式依赖
+
+**问题**：测试 B 依赖测试 A 的副作用（如数据库状态残留）。
+
+**反例**：
+```java
+@Test void testA() { repository.save(user); }
+@Test void testB() { assertEquals(1, repository.count()); } // 依赖 testA 的 save
+```
+
+**修复**：每个测试自包含，`@BeforeEach` 重置状态。
+
+## 反模式 12：测试代码重复
+
+**问题**：大量 copy-paste 的测试代码，缺少 helper 提取。
+
+**修复**：提取 test fixture builder 或 helper 方法。
+
+## 反模式 13：魔法值
+
+**问题**：测试中使用未解释的字面值。
+
+**反例**：
+```java
+assertEquals(42, result); // 42 是什么？
+```
+
+**正例**：
+```java
+int expectedAvailableCount = 2; // total=3, borrowed=1, so available=2
+assertEquals(expectedAvailableCount, result);
+```
+
+## 反模式 14：断言不足
+
+**问题**：只断言了部分结果，遗漏了关键属性。
+
+**反例**：
+```java
+assertNotNull(result); // 弱断言，不验证具体值
+```
+
+**正例**：
+```java
+assertNotNull(result);
+assertEquals("borrowed", result.getStatus());
+assertEquals("user-001", result.getUserId());
+```
+
+## 反模式 15：缺少负面测试
+
+**问题**：只测试正常路径，不测试错误条件。
+
+**修复**：每个方法至少有一个异常路径测试。规则见 `opsx-tdd-rules/rules/exception-path-coverage.md`。
+
+## TDD 如何防止这些反模式
+
+1. 先写测试 → 迫使你思考实际在测试什么
+2. 看它失败 → 确认测试测试的是真实行为，不是 mock
+3. 最小实现 → 不会出现测试专用方法
+4. 真实依赖 → 在 mock 之前看到测试实际需要什么

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

@@ -0,0 +1,167 @@
+---
+name: opsx-tdd-core
+description: "TDD 流程纪律层 — 铁律、红绿重构循环、执行门禁、合规自检。当 test-strategy=tdd 时，所有 SDD 阶段引用本技能获取 TDD 流程规则。"
+---
+
+# opsx-tdd-core — TDD 流程纪律层
+
+> **定位**：TDD 铁律、红绿重构循环定义、执行门禁的唯一真相源。
+> **参考来源**：Superpowers `test-driven-development`
+
+---
+
+## §1 铁律
+
+```
+NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+```
+
+- 先写了生产代码再写测试？删除它，从测试开始
+- "太简单不用测" → 如果值得写，就值得测
+- "事后补测一样" → 不一样，TDD 的价值在于测试驱动设计
+- "删了浪费" → 删掉重来比带着错误前提实现更省时间
+- "保留作参考" → 你会改编它，那就是后写测试，删除就是删除
+
+## §2 基础原则
+
+> 违反规则的字面意义就是违反规则的精神。
+
+## §3 红绿重构循环
+
+```
+RED → Verify RED → 🔴中断声明 → GREEN → Verify GREEN → GREEN Scope 门禁 → REFACTOR → Repeat
+```
+
+> **⛔ 严格串行**：RED→GREEN 对不可并行、不可批量。每个 RED 必须先确认失败，再进入 GREEN；每个 GREEN 必须先通过 Scope 门禁，再进入下一个 RED。禁止"看到全貌后一次性实现多个行为点"。
+
+- **RED**：写一个最小的失败测试，展示期望行为
+  - 一个行为、清晰名称、真实代码（除非不可避免否则不用 mock）
+  - ⛔ **只写当前 RED 对应的测试方法**，不提前写后续 RED 的测试
+- **Verify RED**（强制执行，绝不跳过）：
+  - 确认测试失败（不是报错）
+  - 失败信息符合预期
+  - 因功能缺失而失败（不是拼写错误）
+  - 测试通过？说明在测试已有行为，修复测试
+  - 测试报错？修复错误，重新运行直到正确失败
+- **🔴 中断声明**（强制执行，绝不跳过）：
+  - RED 确认失败后，必须显式声明中断点：
+    `🔴 RED-N 确认失败，原因：[具体原因]。现在进入 GREEN-N，仅实现让此测试通过的最少代码。`
+  - 此声明强制 agent 在 RED 和 GREEN 之间产生节奏断点，防止从 RED 滑入 GREEN 再滑入下一个行为点
+- **GREEN**：写最简单的代码通过测试
+  - 不添加功能、不重构其他代码、不"改进"超出测试范围的内容
+  - ⛔ **执行 GREEN Scope 声明**（见 `opsx-tdd-rules/rules/green-scope-declaration.md`）：
+    1. 列出当前 RED 测试的断言清单
+    2. 列出 design.md 中本 DES 元素的完整流程步骤
+    3. 标记步骤归属（✅ 属于当前 RED / ⛔ 属于后续 RED）
+    4. 仅实现标记为 ✅ 的步骤
+  - ⛔ **逐条确认 YAGNI 围栏**：读取 tasks.md 中本 GREEN 任务的 YAGNI 围栏声明，逐条确认"未实现 [后续 RED 的行为]：✅"
+- **Verify GREEN**（强制执行）：
+  - 确认测试通过
+  - 其他测试仍通过
+  - 输出纯净（无错误/警告）
+  - 测试失败？修复代码，不是修复测试
+- **GREEN Scope 门禁**（强制执行，在 Verify GREEN 之后）：
+  - 检查生产代码中是否有未被当前 RED 断言覆盖的逻辑分支
+  - 若存在且属于后续 RED 的行为 → 删除多余代码
+  - 自检："当前实现是否只覆盖了当前 RED 的断言？"
+  - 若发现越界 → 删除越界代码，重新运行测试确认仍绿
+- **REFACTOR**：仅在绿色之后
+  - 移除重复、改善命名、提取辅助函数
+  - 保持测试绿色，不添加行为
+  - ⛔ 执行 `opsx-tdd-rules/rules/refactor-checklist.md`（7 项重构检查点）
+- **Repeat**：下一个失败测试，下一个功能
+
+## §4 执行门禁
+
+> 完整规则见 `opsx-tdd-rules/rules/test-execution-gate.md`，此处仅保留快速参考。
+
+| test-strategy | 行为 |
+|---------------|------|
+| `tdd` | ⛔ 强制执行：RED 确认失败、GREEN 确认通过、REFACTOR 全部测试仍绿 |
+| `impl-first` | ⚠️ 警告模式：运行测试，失败时显示警告但允许继续 |
+| `none` | 跳过：不执行测试门禁 |
+
+## §5 TDD 策略定义
+
+> 完整规则见 `opsx-tdd-rules/rules/tdd-strategy-selection.md`，此处仅保留快速参考。
+
+三种策略（tdd/impl-first/none）的定义与适用场景：
+
+- **A) TDD（红绿重构循环）**：每个行为点先写失败测试（红），再写最少代码让它通过（绿），最后重构。DAG: RED → GREEN → REFACTOR → ...。任务数量约为模块级拆分的 3-5 倍。适合核心业务逻辑/质量要求高/需要测试驱动设计。
+- **B) Impl-First（代码先行）**：先生成实现任务，测试作为验证步骤。DAG: 实现代码 → 测试验证。适合 UI 层/配置类/快速原型。
+- **C) None（仅实现）**：不生成测试任务，仅编译检查。适合简单配置/文档更新。
+
+## §6 Controller 层策略
+
+> 完整规则见 `opsx-tdd-rules/rules/controller-strategy.md`，此处仅保留快速参考。
+
+| 策略 | 说明 | 适用 |
+|------|------|------|
+| 策略 A | 为每个 Controller 接口生成 RED 测试（@WebMvcTest），拆为 RED→GREEN 对 | Controller 含业务逻辑 |
+| 策略 B | Controller 作为非 TDD 模块，独立接口层任务，仅做编译检查 | Controller 为纯接线（调用 Service + 返回 Result） |
+
+必须在 tasks.md §2.0 中声明使用哪种策略。
+
+## §7 合理化预防表
+
+| 借口 | 现实 |
+|------|------|
+| "太简单不需要测试" | 简单代码也会出错。测试只需30秒。 |
+| "我之后测试" | 立即通过的测试什么也证明不了。 |
+| "后写测试能达到同样目标" | 后写测试="这做什么？" 先写测试="这应该做什么？" |
+| "已经手动测试了" | 临时测试 ≠ 系统测试。无记录，无法重跑。 |
+| "删除X小时是浪费" | 沉没成本谬误。保留未验证代码是技术债务。 |
+| "保留作为参考，先写测试" | 你会改编它。那就是后写测试。删除就是删除。 |
+| "需要先探索" | 可以。但扔掉探索代码，用TDD重新开始。 |
+| "测试困难=设计不清晰" | 听测试的。难测试=难使用。 |
+| "TDD会拖慢我" | TDD比调试快。务实=先测试。 |
+| "手动测试更快" | 手动测试无法证明边界情况。每次改动都要重测。 |
+| "现有代码没有测试" | 你在改进它。为现有代码添加测试。 |
+| "这次不同因为..." | 不，没有不同。 |
+
+## §8 红旗列表
+
+以下信号出现时，**STOP and Start Over**：
+
+- 代码先于测试
+- 实现后写测试
+- 测试立即通过
+- 无法解释测试为何失败
+- 测试"稍后"添加
+- 合理化"就这一次"
+- "我已经手动测试过了"
+- "后写测试能达到同样目的"
+- "这是精神而非仪式"
+- "保留作为参考"或"改编现有代码"
+- "已经花了X小时，删除是浪费"
+
+> 所有这些都意味着：删除代码，用 TDD 重新开始。
+
+## §9 完成验证清单
+
+标记工作完成前必须全部勾选：
+
+- [ ] 每个新函数/方法都有测试
+- [ ] 在实现前观看了每个测试失败
+- [ ] 每个测试因预期原因失败（功能缺失，非拼写错误）
+- [ ] 写了最小代码通过每个测试
+- [ ] 所有测试通过
+- [ ] 输出纯净（无错误/警告）
+- [ ] 测试使用真实代码（仅在不可避免时使用 mock）
+- [ ] 边界情况和错误已覆盖
+
+> Can't check all boxes? You skipped TDD. Start over.
+
+## §10 跨技能引用
+
+- → `opsx-tdd-quality`：单测代码质量标准（Mock 边界矩阵、命名规范、Java 规则等）
+- → `opsx-tdd-anti-patterns`：测试反模式检测（15 种反模式 + 门禁函数）
+- → `opsx-tdd-review`：测试审查（8 项质量检查 + 缺失测试检测）
+- → `opsx-tdd-metrics`：度量分析（隔离评分、命名评分、覆盖率缺口）
+- → `opsx-tdd-rules`：规则库（DAG 规则、Controller 策略、telemetry 模板等）
+  - `rules/green-yagni-fence.md`：GREEN 任务 YAGNI 围栏（引用方：opsx-task）
+  - `rules/green-scope-declaration.md`：GREEN Scope 声明（引用方：opsx-apply）
+  - `rules/des-step-annotation.md`：DES 步骤级标注（引用方：opsx-design）
+  - `rules/multi-validation-split.md`：多校验拆分（引用方：opsx-spec）
+  - `rules/exception-path-coverage.md`：异常路径测试覆盖门禁（引用方：opsx-task, opsx-apply, opsx-check）
+  - `rules/refactor-checklist.md`：REFACTOR 阶段检查点（引用方：opsx-apply, opsx-tdd-core）

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

@@ -0,0 +1,55 @@
+---
+description: "opsx-tdd-core 自检清单 — TDD 执行合规自检、合规性检查、完成验证。仅在执行 TDD 任务自检时读取。"
+---
+
+# opsx-tdd-core — 自检清单
+
+> 仅在执行 TDD 任务自检时读取。日常流程见 `SKILL.md`。
+
+---
+
+## §A TDD 执行合规自检（11 项）
+
+⛔ 每完成一个 RED/GREEN/REFACTOR 任务后，必须逐项勾选：
+
+- [ ] RED 任务已运行测试并确认失败
+- [ ] RED 失败原因是"功能未实现"而非编译错误
+- [ ] ⛔ **RED 只写了当前行为点的测试**：测试文件中未提前编写后续 RED 的测试方法
+- [ ] ⛔ **RED→GREEN 中断声明已执行**：RED 确认失败后，显式声明了"🔴 RED-N 确认失败，现在进入 GREEN-N"
+- [ ] GREEN 任务已运行测试确认通过
+- [ ] GREEN 未提前实现没有测试要求的功能
+- [ ] ⛔ **GREEN Scope 越界检测**：GREEN 实现后检查生产代码是否包含未被当前 RED 断言覆盖的逻辑分支（规则见 `opsx-tdd-rules/rules/green-scope-declaration.md` §Scope 自检）
+- [ ] ⛔ **GREEN YAGNI 围栏逐条确认**：读取 tasks.md 中本 GREEN 任务的 YAGNI 围栏声明，逐条确认"未实现 [后续 RED 的行为]：✅"
+- [ ] ⛔ **GREEN Scope 门禁已执行**：Verify GREEN 之后，检查生产代码无越界逻辑分支
+- [ ] REFACTOR 后全部测试仍绿
+- [ ] 未出现"先写生产代码再补测试"的情况
+
+## §B TDD 合规性检查（10 项）
+
+仅 `test-strategy=tdd` 时执行：
+
+- [ ] RED 任务验收标准包含"测试运行失败"
+- [ ] 无"断言为空"或"编译通过但断言为空"的验收标准
+- [ ] GREEN 任务为行为级粒度（一对一对应 RED）
+- [ ] DAG 存在 RED→GREEN 循环对
+- [ ] 非 TDD 模块未拆红绿循环
+- [ ] GREEN 任务验收标准为"让对应 RED 通过"（而非"实现完整功能"）
+- [ ] GREEN 任务输出不含未测试的 Controller/Filter/Config
+- [ ] 已声明 Controller 层处理策略（策略 A 或 B）
+- [ ] 每个 RED 任务包含测试方法名（`{method}_{state}_{outcome}` 格式）
+- [ ] 每个 REFACTOR 任务列出至少 2 个具体重构点
+
+## §C 完成验证清单（8 项）
+
+标记工作完成前必须全部勾选：
+
+- [ ] 每个新函数/方法都有测试
+- [ ] 在实现前观看了每个测试失败
+- [ ] 每个测试因预期原因失败（功能缺失，非拼写错误）
+- [ ] 写了最小代码通过每个测试
+- [ ] 所有测试通过
+- [ ] 输出纯净（无错误/警告）
+- [ ] 测试使用真实代码（仅在不可避免时使用 mock）
+- [ ] 边界情况和错误已覆盖
+
+> Can't check all boxes? You skipped TDD. Start over.