kld-sdd 2.6.5 → 2.6.6

package/package.json

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

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

@@ -211,6 +211,7 @@ g. **继续下一个层级** — 重新检查 DAG，找出依赖已满足的下
 > 合理化预防表见 opsx-tdd-core/SKILL.md §7
 > REFACTOR 检查点见 opsx-tdd-rules/rules/refactor-checklist.md
 > 异常路径覆盖门禁见 opsx-tdd-rules/rules/exception-path-coverage.md
+> TDD 节奏校验（执行后校验）见 `./checklist.md` §5e.1
 
 **【S2.1 RED 测试质量标准】**（test-strategy=tdd 时强制）：
 
@@ -282,6 +283,7 @@ g. **继续下一个层级** — 重新检查 DAG，找出依赖已满足的下
 - **⛔ 编译检查门禁**：每完成一个任务后必须运行编译检查，编译失败禁止标记已完成。
 - **⛔ 测试执行门禁**：根据 `test-strategy` 决定（tdd=强制, impl-first=强制补跑, none=跳过）；须真实执行并留 telemetry。${HOOK_GATE_DESCRIPTION}
 - **⛔ 必须实时更新任务状态**：每完成一个任务立即改 tasks.md，两种格式同步。
+- **⛔ apply 结束前 checkbox 全量同步校验**：`stage_end` 前对比 telemetry `task_update` 记录数与 tasks.md `[x]` 数量，不一致则补齐（见 `./checklist.md` §5f.1）。
 - **⛔ 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` 继续执行。
@@ -298,7 +300,7 @@ g. **继续下一个层级** — 重新检查 DAG，找出依赖已满足的下
 
 ## 渐进披露
 
-- Read `checklist.md` 仅在执行 apply 需要校验门禁/自检时 — 含 §1.2 Check 门禁检查点、§5d/§5e 编译/测试门禁自检、§6.0 单元测试真实执行自检、§6.1 worktree 收尾前置条件、Guardrails ⛔ 强制项勾选表。
+- Read `checklist.md` 仅在执行 apply 需要校验门禁/自检时 — 含 §1.2 Check 门禁检查点、§5d/§5e 编译/测试门禁自检、§5e.1 TDD 节奏校验、§5f.1 checkbox 全量同步校验、§6.0 单元测试真实执行自检、§6.1 worktree 收尾前置条件、Guardrails ⛔ 强制项勾选表。
 - Read `reference.md` 仅在需要参考详细模板时 — 含 📊 Telemetry 命令模板（start/end/task_update/ai_adoption_review/worktree_finish）、§1.5 worktree 全套策略（Step 0.1-3 + record-base + 多 cap 合并顺序）、§5c 子代理派发、§5.1 AI 产出快照、§6.0 单元测试、§6.1 worktree 收尾脚本。
 - `implementer-prompt.md` 为子代理派发提示模板（§5c 派发时组合 tasks/design/overview 上下文使用）。
 - `worktree-setup.md` 为 worktree 快速参考（§1.5 策略的精简版，与 reference.md §1.5 完整版并存：reference=完整策略，worktree-setup=快速参考）。

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

@@ -47,6 +47,11 @@ description: opsx-apply 的阶段强制检查点与自检清单。仅在执行 a
 > 不在此内联复制，以 opsx-tdd-core/checklist.md §A 为唯一真相源。
 > 额外补充：REFACTOR 任务还需执行 `opsx-tdd-rules/rules/refactor-checklist.md`（7 项重构检查点）。
 
+⛔ **TDD 节奏校验**（RED→GREEN 严格串行的执行后校验）：
+- [ ] 连续的 RED-N `task_update` 与 GREEN-N `task_update` 之间有可验证的执行间隔（建议 >60 秒），若时间戳差距过小视为批量执行信号
+- [ ] 每对 RED→GREEN 之间已执行 🔴 中断声明（`🔴 RED-N 确认失败，原因：XXX。现在进入 GREEN-N`）
+- [ ] 若同层有多个 RED→GREEN 对，确认是逐对完成而非一次性编写多个 RED 再一次性实现多个 GREEN
+
 ### §5e.2 RED 测试质量门禁（仅 test-strategy=tdd 时，RED 任务完成后强制检查）
 
 ⛔ 核心原则（引用 opsx-tdd-quality/SKILL.md §2）：Mock 边界，不 Mock 行为
@@ -79,6 +84,15 @@ description: opsx-apply 的阶段强制检查点与自检清单。仅在执行 a
 - [ ] 记录任务级 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 并报告
 
+### §5f.1 apply 结束前 checkbox 全量同步校验
+
+> ⛔ 在 `stage_end` telemetry 记录前必须执行此校验，防止任务状态滞后到 archive 阶段。
+
+- [ ] 对比 telemetry `task_update` 记录的已完成任务数与 tasks.md 中 `[x]` 数量，不一致则补齐
+- [ ] tasks.md 中所有 `- [ ]` / `- [x]` 与 `**状态**: [ ]` / `[x]` 两种格式已同步
+- [ ] 手动验证清单（如有）已勾选
+- [ ] 文档更新项（如有）已完成或显式标注推迟
+
 ---
 
 ## §6.0 单元测试真实执行自检（`test-strategy` 非 `none`）
@@ -114,8 +128,10 @@ description: opsx-apply 的阶段强制检查点与自检清单。仅在执行 a
 - [ ] ⛔ **测试执行门禁**：根据 `test-strategy` 决定（tdd=强制, impl-first=强制补跑, none=跳过）；须真实执行并留 telemetry，`sdd-apply-test-gate` 校验非占位数据
 - [ ] ⛔ **RED 测试质量门禁**：见 §5e.2（引用 opsx-tdd-quality + opsx-tdd-anti-patterns，不在此内联复制）
 - [ ] ⛔ **必须实时更新任务状态**：每完成一个任务立即改 tasks.md，两种格式（`- [ ]`→`- [x]` 与 `**状态**: [ ]`→`[x]`）同步
+- [ ] ⛔ **apply 结束前 checkbox 全量同步校验**：见 §5f.1，`stage_end` 前对比 telemetry `task_update` 记录数与 tasks.md `[x]` 数量
 - [ ] ⛔ **task_update 后必须验证 checkbox 已更新**：执行 `check-task` 确认 tasks.md 对应行已变更；未更新则手动修改
 - [ ] ⛔ **TDD RED→GREEN 严格串行**：不适用同层并行派发；RED-N 确认失败后必须执行中断声明再进入 GREEN-N；GREEN 完成后必须通过 Scope 门禁再进入下一个 RED
+- [ ] ⛔ **TDD 节奏校验**：见 §5e.1，连续 RED-N/GREEN-N 的 `task_update` 时间戳须有可验证间距
 - [ ] **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-check/SKILL.md

@@ -97,6 +97,10 @@ openspec list
 - [ ] spec.md 的需求项在 design.md 中 100% 被覆盖
 - [ ] design.md 的设计点在 tasks.md 中 100% 被拆解
 - [ ] 跨文档引用路径正确
+- [ ] ⛔ **CON 覆盖一致性**：spec.md 中每个 CON 在 tasks.md 中有对应验证任务或显式声明间接覆盖；tasks.md 声明"100% 覆盖 CON"时必须可追溯
+- [ ] ⛔ **安全/审计要求覆盖一致性**：spec.md §5.x 中的安全与审计要求在 tasks.md 中有对应任务或显式声明推迟
+- [ ] ⛔ **AC 变体覆盖一致性**：spec.md 中含"或"条件的 AC 场景，其 RED 任务验收标准须列出所有变体的测试方法（规则见 `opsx-tdd-rules/rules/multi-validation-split.md` §AC 内"或"条件变体覆盖）
+- [ ] ⛔ **tasks.md §4.x 验证方式表内部一致性**：§4.x 验证方式表中的测试注解/配置与任务实现步骤中的声明一致
 
 #### 4.3 算法正确性检查
 

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

@@ -36,6 +36,13 @@ description: "opsx-check 阶段日志自检清单 — 仅在 check 自检时读
 - [ ] 完整性、一致性、算法正确性、可执行性、TDD合规性（仅test-strategy=tdd时）五维均已输出
 - [ ] 报告问题对应修复建议（spec/design/task）
 
+## D2. 一致性补充检查（SKILL.md §4.2 扩展）
+
+- [ ] **CON 覆盖**：spec.md 中每个 CON 在 tasks.md 中有对应验证任务或显式声明间接覆盖
+- [ ] **安全/审计要求覆盖**：spec.md §5.x 中的安全与审计要求在 tasks.md 中有对应任务或显式声明推迟
+- [ ] **AC 变体覆盖**：spec.md 中含"或"条件的 AC 场景，其 RED 任务验收标准列出所有变体的测试方法（引用 `opsx-tdd-rules/rules/multi-validation-split.md`）
+- [ ] **§4.x 验证方式表内部一致性**：tasks.md §4.x 验证方式表中的测试注解/配置与任务实现步骤中的声明一致
+
 ## E. TDD 合规性检查（仅 test-strategy=tdd 时）
 
 ⛔ 执行 `opsx-tdd-core/checklist.md` §B（11 项）逐项检查。

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

@@ -189,7 +189,14 @@ Simple 模式或单文件能力域下，**不要拆成多个同文件任务**。
 
 ### 8. 质量红线自检
 
-> 逐项确认，完整 7 项自检清单 + TDD 合规性自检（结构符合模板 / 拓扑图已绘制 / 依赖字段已填写 / 无循环依赖 / 颗粒度 ≤5 分钟 / 100% 覆盖 design / 每任务有验收标准）见 `./checklist.md`「§8 质量红线自检 + §8.1 TDD 合规性自检」。如有任意一项未满足，重新生成对应章节，直至全部通过。
+> 逐项确认，完整 7 项自检清单 + TDD 合规性自检（结构符合模板 / 拓扑图已绘制 / 依赖字段已填写 / 无循环依赖 / 颗粒度 ≤5 分钟 / 100% 覆盖 design / 每任务有验收标准）见 `./checklist.md`「§8 质量红线自检 + §8.1 TDD 合规性自检」。
+>
+> 额外强制项（见 `./checklist.md` §8）：
+> - ⛔ **CON 覆盖**：spec.md 中每个 CON 必须有对应验证任务或显式声明间接覆盖
+> - ⛔ **安全/审计要求覆盖**：spec.md §5.x 中的安全与审计要求必须有对应任务或显式声明推迟
+> - ⛔ **§4.x 验证方式表内部一致性**：§4.x 验证方式表中的测试注解/配置必须与任务实现步骤中的声明一致
+>
+> 如有任意一项未满足，重新生成对应章节，直至全部通过。
 
 ### 9. 确认任务并输出
 

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

@@ -29,6 +29,9 @@ description: opsx-task 的阶段强制检查点与自检清单。仅在执行 ta
 - [ ] 每个任务颗粒度 ≤ 5 分钟
 - [ ] 100% 覆盖 design.md 定义
 - [ ] 每个任务都有验收标准
+- [ ] ⛔ **约束（CON）覆盖**：spec.md 中每个 CON 必须有对应验证任务，或在任务中显式声明"通过现有 AC 间接覆盖"并说明理由；tasks.md 质量红线声明"100% 覆盖 CON"时必须可追溯
+- [ ] ⛔ **安全/审计要求覆盖**：spec.md §5.x 中的安全与审计要求（日志记录、脱敏、告警等）必须有对应任务，或显式声明推迟到后续迭代并在任务中标注
+- [ ] ⛔ **§4.x 验证方式表内部一致性**：§4.x 验证方式表中的测试注解/配置必须与任务实现步骤中的声明一致，不得出现"§4.1 声明 @WebMvcTest 但实现步骤允许 @SpringBootTest"的矛盾
 
 **如有任意一项未满足，重新生成对应章节，直至全部通过。**
 

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

@@ -1,6 +1,6 @@
 ---
 name: opsx-tdd-anti-patterns
-description: "测试反模式防护层 — 15 种反模式检测（RED 阶段 3 种 + GREEN 后 12 种），每种带门禁函数和修复方案。当编写或审查测试代码时引用本技能。"
+description: "测试反模式防护层 — 16 种反模式检测（RED 阶段 3 种 + GREEN 后 13 种），每种带门禁函数和修复方案。当编写或审查测试代码时引用本技能。"
 ---
 
 # opsx-tdd-anti-patterns — 反模式防护层
@@ -32,7 +32,7 @@ description: "测试反模式防护层 — 15 种反模式检测（RED 阶段 3
 | 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 GREEN 后反模式（13 种）
 
 | # | 反模式 | 问题表现 | 修复方案 |
 |---|--------|---------|---------|
@@ -48,6 +48,7 @@ description: "测试反模式防护层 — 15 种反模式检测（RED 阶段 3
 | 13 | **魔法值** | 测试中使用未解释的字面值（如 `assertEquals(42, result)` 无注释说明 42 的含义） | 使用命名常量或注释解释字面值含义 |
 | 14 | **断言不足** | 只断言了部分结果，遗漏了关键属性（如只 assertNotNull 但不 assertEquals 具体值） | 每个测试至少有一个具体值断言（assertEquals），而非仅 assertNotNull |
 | 15 | **缺少负面测试** | 只测试正常路径，不测试错误条件 | 每个方法至少有一个异常路径测试（见 `opsx-tdd-rules/rules/exception-path-coverage.md`） |
+| 16 | **AC 变体覆盖不足** | AC 场景描述含"或"条件（如"缺少 A 或 B 或为空"），但测试只覆盖部分变体 | AC 中每个"或"条件变体必须有对应测试方法（规则见 `opsx-tdd-rules/rules/multi-validation-split.md` §AC 内"或"条件变体覆盖） |
 
 ## §5 门禁函数
 
@@ -82,3 +83,5 @@ AFTER GREEN（GREEN 完成后、标记通过前）：
 - 测试中只有 `assertNotNull` 无具体值断言
 - 测试中存在未解释的魔法数字/字符串
 - 正常路径有测试但异常路径无测试
+- AC 场景描述含"或"条件但测试只覆盖部分变体
+- 连续 RED/GREEN 的 task_update 时间戳差距过小（批量执行信号，违反 TDD 严格串行）

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

@@ -195,6 +195,35 @@ assertEquals("user-001", result.getUserId());
 
 **修复**：每个方法至少有一个异常路径测试。规则见 `opsx-tdd-rules/rules/exception-path-coverage.md`。
 
+## 反模式 16：AC 变体覆盖不足
+
+**问题**：AC 场景描述含"或"条件（如"缺少 A 或 B 或为空"），但测试只覆盖部分变体，其余变体无测试守护。
+
+**反例**：
+```java
+// AC-004: 请求体缺少 username 或 password 字段，或字段值为空字符串
+// 仅测试 1/6 变体
+@Test
+void login_withMissingParams_returns1001() {
+    mockMvc.perform(post("/login")
+            .content("{\"username\":\"\",\"password\":\"admin123\"}"))
+            .andExpect(jsonPath("$.code").value(1001));
+}
+```
+
+**正例**：
+```java
+// 每个变体都有测试方法（或参数化测试）
+@Test void login_withEmptyUsername_returns1001() { ... }
+@Test void login_withEmptyPassword_returns1001() { ... }
+@Test void login_withMissingUsernameField_returns1001() { ... }
+@Test void login_withMissingPasswordField_returns1001() { ... }
+@Test void login_withBothEmpty_returns1001() { ... }
+@Test void login_withBothMissing_returns1001() { ... }
+```
+
+**修复**：AC 中每个"或"条件变体必须有对应测试方法。规则见 `opsx-tdd-rules/rules/multi-validation-split.md` §AC 内"或"条件变体覆盖。
+
 ## TDD 如何防止这些反模式
 
 1. 先写测试 → 迫使你思考实际在测试什么

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

@@ -40,6 +40,9 @@ description: "opsx-tdd-core 自检清单 — TDD 执行合规自检、合规性
 - [ ] 每个 RED 任务包含测试方法名（`{method}_{state}_{outcome}` 格式）
 - [ ] 每个 GREEN 任务包含 YAGNI 围栏声明（"不提前实现 [后续 RED 行为]"）
 - [ ] 每个 REFACTOR 任务列出至少 2 个具体重构点
+- [ ] ⛔ **CON 覆盖**：spec.md 中每个 CON 在 tasks.md 中有对应验证任务或显式声明间接覆盖
+- [ ] ⛔ **安全/审计要求覆盖**：spec.md §5.x 中的安全与审计要求在 tasks.md 中有对应任务或显式声明推迟
+- [ ] ⛔ **AC 变体覆盖**：spec.md 中含"或"条件的 AC 场景，其 RED 任务验收标准列出所有变体的测试方法（引用 `opsx-tdd-rules/rules/multi-validation-split.md`）
 
 ## §C 完成验证清单（8 项）
 
@@ -53,5 +56,6 @@ description: "opsx-tdd-core 自检清单 — TDD 执行合规自检、合规性
 - [ ] 输出纯净（无错误/警告）
 - [ ] 测试使用真实代码（仅在不可避免时使用 mock）
 - [ ] 边界情况和错误已覆盖
+- [ ] ⛔ **AC "或"条件变体全覆盖**：AC 场景描述含"或"条件时，每个变体都有对应测试方法（引用 `opsx-tdd-rules/rules/multi-validation-split.md`）
 
 > Can't check all boxes? You skipped TDD. Start over.

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

@@ -24,6 +24,6 @@ description: "TDD 规则库 — DAG 生成规则、Controller 策略、任务类
 | `rules/green-yagni-fence.md` | GREEN 任务 YAGNI 围栏自动注入规则 | HIGH | opsx-task |
 | `rules/green-scope-declaration.md` | GREEN 任务 Scope 声明步骤（断言清单→流程标记→仅实现属于的步骤） | HIGH | opsx-apply |
 | `rules/des-step-annotation.md` | DES 元素步骤级标注规则（TDD 模式下标注 [GREEN-N] 归属） | MEDIUM | opsx-design |
-| `rules/multi-validation-split.md` | 多校验条件拆分规则（每个校验条件须有独立 AC 场景） | MEDIUM | opsx-spec |
+| `rules/multi-validation-split.md` | 多校验条件拆分规则（每个校验条件须有独立 AC 场景；AC 内"或"条件变体须全覆盖） | MEDIUM | opsx-spec, opsx-task, opsx-check |
 | `rules/exception-path-coverage.md` | 异常路径测试覆盖门禁（每个 orElseThrow/边界检查须有对应 RED 测试） | HIGH | opsx-task, opsx-apply, opsx-check |
 | `rules/refactor-checklist.md` | REFACTOR 阶段检查点（public API 不变、行为保持、重构质量评估） | HIGH | opsx-apply, opsx-tdd-core |

package/templates/skills/kld-sdd/opsx-tdd-rules/rules/multi-validation-split.md

@@ -1,7 +1,7 @@
 # 多校验拆分规则
 
 > 影响等级：MEDIUM
-> 引用方：opsx-spec（spec.md 生成）、opsx-spec/checklist.md（自检）
+> 引用方：opsx-spec（spec.md 生成）、opsx-spec/checklist.md（自检）、opsx-task（RED 任务拆解）、opsx-check（一致性检查）
 
 ## 问题
 
@@ -34,3 +34,37 @@ AC-03: 可借数量不足（available_count = 0）
 ```
 
 > 目的：每个校验条件有独立场景 → 独立 RED 测试 → 独立 GREEN 实现，避免 AI 在一个 GREEN 中实现所有校验。
+
+## AC 内"或"条件变体覆盖
+
+> 引用方：opsx-spec（spec.md 生成）、opsx-task（RED 任务拆解）、opsx-check（一致性检查）
+
+### 问题
+
+单个 AC 场景描述中包含"或"条件时（如"缺少 username **或** password 字段，或字段值为空字符串"），AI 在拆解 RED 任务时倾向于只取一个变体编写测试，导致其余变体无测试守护。
+
+### 规则
+
+当单个 AC 场景描述包含"或"条件时，必须检查：
+
+1. 每个"或"条件变体是否有对应的测试方法
+2. 若多个变体共享一个 RED 任务，RED 验收标准中必须列出所有变体的测试方法名
+3. 变体可合并到一个 RED 任务的多个 `@Test` 方法中，但不得遗漏任何变体
+
+### 反例（禁止）
+
+```
+AC-004: 请求体缺少 username 或 password 字段，或字段值为空字符串
+RED-4: login_withMissingParams_returns1001
+  → 仅测试 username="" 一种变体，password="" / 缺少字段 / 双空 / 双缺共 5 种变体未覆盖
+```
+
+### 正例（要求）
+
+```
+AC-004: 请求体缺少 username 或 password 字段，或字段值为空字符串
+RED-4: login_withMissingParams_returns1001（含 6 个 @Test 方法或参数化测试）
+  → username="" / password="" / 缺少 username / 缺少 password / 双空 / 双缺 均有测试
+```
+
+> 目的：spec 中"或"条件描述的每个变体都有测试守护，防止参数校验逻辑回归。