kld-sdd 2.6.12 → 2.6.13

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

@@ -40,7 +40,7 @@ allowed-tools:
 > - 不要省略 `--source=opsx-command` 与 `--session-id=<会话ID>`。
 > **📊 Telemetry（必做，不得跳过）**
 > - 阶段开始：`node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" start --command=check --project=. --change=<变更名称> --capability=<可选capability-name> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID>`（保存 event_id）
-> - 检查报告生成后，必须先记录结构化检查结果：`node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" record --type=check_result --command=check --project=. --change=<变更名称> --capability=<可选capability-name> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID> --result=success/partial/failure --summary="检查结果摘要" --details-json="{\"check_results\":{\"total\":0,\"errors\":0,\"warnings\":0,\"warning_items\":[],\"suggestions\":0,\"fixed_before_apply\":0,\"consistency_score\":null,\"categories\":{\"completeness\":{\"passed\":0,\"total\":0},\"consistency\":{\"passed\":0,\"total\":0},\"executability\":{\"passed\":0,\"total\":0},\"tdd_compliance\":{\"passed\":0,\"total\":0}},\"task_completion\":{\"completed\":0,\"incomplete\":0,\"total\":0,\"has_incomplete\":false,\"checked_for_archive_readiness\":false}}}"`
+> - 检查报告生成后，必须先记录结构化检查结果：`node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" record --type=check_result --command=check --project=. --change=<变更名称> --capability=<可选capability-name> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID> --result=success/partial/failure --summary="检查结果摘要" --details-json="{\"check_results\":{\"total\":0,\"errors\":0,\"warnings\":0,\"warning_items\":[],\"warning_dispositions\":[{\"warning\":\"<稳定编号>\",\"disposition\":\"fixed|accepted|waived|needs_input|open\",\"reason\":\"<处置依据>\"}],\"suggestions\":0,\"fixed_before_apply\":0,\"consistency_score\":null,\"reviewer\":\"<reviewer-identifier>\",\"review_session_id\":\"<当前check会话ID>\",\"author_session_id\":\"<文档作者/apply会话ID或unknown>\",\"reviewer_independence\":\"independent-review|self-review|unknown\",\"categories\":{\"completeness\":{\"passed\":0,\"total\":0},\"consistency\":{\"passed\":0,\"total\":0},\"executability\":{\"passed\":0,\"total\":0},\"tdd_compliance\":{\"passed\":0,\"total\":0}},\"task_completion\":{\"completed\":0,\"incomplete\":0,\"total\":0,\"has_incomplete\":false,\"checked_for_archive_readiness\":false}}}"`
 > - `check_result` 记录成功后，才允许阶段结束：`node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" end --event-id=<event_id> --command=check --project=. --change=<变更名称> --capability=<可选capability-name> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID> --result=success/partial/failure --summary="摘要"`
 > - **【B1 摘要数字校验】** `stage_end --summary` 中的数字（如「N 个场景」「N 层 DAG」「N 个任务」）必须与 `spec.md`/`tasks.md`/`test-scenarios.md` 的实统计交叉校验一致后再填写，不得凭记忆自填。典型失真：summary 写「11 个场景」实际 spec 含 13 条断言、「5 层 DAG」实际 tasks 修复后为 6 层。check 阶段发现不一致时，修正 summary 或补齐文档，使三者数字自洽。
 
@@ -171,7 +171,7 @@ node "$(cat .sdd-spec-root)/skywalk-sdd/ontology/cli.cjs" diagnose-naming --proj
 - [ ] 跨文档引用路径正确
 - [ ] ⛔ **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 内"或"条件变体覆盖）
+- [ ] ⛔ **AC 变体覆盖一致性**：spec.md 中含"或"条件的 AC 场景，其 RED 任务验收标准须列出所有变体的测试方法（规则见 `tdd-rules/rules/multi-validation-split.md` §AC 内"或"条件变体覆盖）
 - [ ] ⛔ **tasks.md §4.x 验证方式表内部一致性**：§4.x 验证方式表中的测试注解/配置与任务实现步骤中的声明一致
 
 #### 4.3 算法正确性检查
@@ -189,17 +189,17 @@ node "$(cat .sdd-spec-root)/skywalk-sdd/ontology/cli.cjs" diagnose-naming --proj
 
 #### 4.4a TDD 合规性检查（仅 test-strategy=tdd 时执行）
 
-⛔ 执行 `opsx-tdd-core/checklist.md` §B（15 项）逐项检查。
+⛔ 执行 `tdd-core/checklist.md` §B（15 项）逐项检查。
 
-> 不在此内联复制，以 opsx-tdd-core/checklist.md §B 为唯一真相源。
-> 额外补充：还需检查 `opsx-tdd-rules/rules/exception-path-coverage.md`（异常路径覆盖门禁）。
+> 不在此内联复制，以 tdd-core/checklist.md §B 为唯一真相源。
+> 额外补充：还需检查 `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 项 + 缺失测试检测）
+- tdd-review/SKILL.md（测试质量审查清单 8 项 + 缺失测试检测）
 读取后确认："已读取测试质量审查清单"。
 
 #### 4.5 任务完成状态检查（实现后 / 归档前）
@@ -244,16 +244,20 @@ node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" tasks-status --project=. --chan
 - `warning_items`: 警告明细数组，每项 `{category, description, target}`（如 `{"category":"task_completion","description":"4.3 手动验证清单未勾选","target":"tasks.md:595"}`），用于报告已知风险区渲染具体待确认项；无明细时省略（向后兼容，旧事件仅 `warnings` 数量，报告降级显示数量）。
 - `suggestions`: 可选优化建议数。
 - `fixed_before_apply`: 进入 apply 前已通过或已确认满足质量门禁的检查项数。**【Q2 口径】**：apply 前第一次 check 全过则 = total（全部通过）；apply 前有 check 但 fixed_before_apply=0 不触发 P4 警示（P4 主指标已改为"apply 前是否 check"，与 fixed_before_apply 解耦）。
-- `consistency_score`: 跨文档一致性评分，取值 0-1；无法评分时填 `null`。
+- `consistency_score`: **legacy 兼容字段**（保留一个发布版本）；跨文档一致性评分 0-1，无法评分时填 `null`。
+- `reviewer`: 执行本次 check 的代理或会话标识。
+- `review_session_id`: 当前 check 会话 ID（与 `--session-id` 一致）。
+- `author_session_id`: 文档作者或 apply 阶段会话 ID；无法确定时填 `unknown`。
+- `reviewer_independence`: `independent-review`（独立 evaluator 且会话与作者不同）| `self-review` | `unknown`。优先使用独立 evaluator；不可用时继续检查但标 `self-review` 或 `unknown`，报告中 Q3 为 `provisional`。
 - `categories`: 至少包含 `completeness`、`consistency`、`executability`。
 - `task_completion`: 从 `tasks-status` 输出整理而来；未进入 apply 时 `checked_for_archive_readiness=false`。
 
 在终端执行（必须成功）：
 ```bash
-node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" record --type=check_result --command=check --project=. --change=<变更名称> --capability=<可选capability-name> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID> --result=success/partial/failure --summary="检查结果摘要" --details-json="{\"check_results\":{\"total\":0,\"errors\":0,\"warnings\":0,\"warning_items\":[],\"suggestions\":0,\"fixed_before_apply\":0,\"consistency_score\":null,\"categories\":{\"completeness\":{\"passed\":0,\"total\":0},\"consistency\":{\"passed\":0,\"total\":0},\"executability\":{\"passed\":0,\"total\":0},\"tdd_compliance\":{\"passed\":0,\"total\":0}},\"task_completion\":{\"completed\":0,\"incomplete\":0,\"total\":0,\"has_incomplete\":false,\"checked_for_archive_readiness\":false}}}"
+node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" record --type=check_result --command=check --project=. --change=<变更名称> --capability=<可选capability-name> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID> --result=success/partial/failure --summary="检查结果摘要" --details-json="{\"check_results\":{\"total\":0,\"errors\":0,\"warnings\":0,\"warning_items\":[],\"suggestions\":0,\"fixed_before_apply\":0,\"consistency_score\":null,\"reviewer\":\"<reviewer-identifier>\",\"review_session_id\":\"<当前check会话ID>\",\"author_session_id\":\"<文档作者/apply会话ID或unknown>\",\"reviewer_independence\":\"independent-review|self-review|unknown\",\"categories\":{\"completeness\":{\"passed\":0,\"total\":0},\"consistency\":{\"passed\":0,\"total\":0},\"executability\":{\"passed\":0,\"total\":0},\"tdd_compliance\":{\"passed\":0,\"total\":0}},\"task_completion\":{\"completed\":0,\"incomplete\":0,\"total\":0,\"has_incomplete\":false,\"checked_for_archive_readiness\":false}}}"
 ```
 
-> **⚠️ P1-1 check_result details 不得为空**：`--details-json` 必须含 `consistency_score` / `categories` / `task_completion` 等字段，**禁止传空对象 `{}`**。空 details 会导致 report 的 Q5 跨文档一致性得分、P4b 修复率为 null（工具侧虽有 state fallback 兜底，但事件 details 是主数据源）。
+> **⚠️ P1-1 check_result details 不得为空**：`--details-json` 必须含 `categories` / `task_completion` / reviewer 独立性字段等，**禁止传空对象 `{}`**。空 details 导致 Q3 不可计算（工具侧虽有 state fallback 兜底，但事件 details 是主数据源）。
 
 > **⚠️ P2-3 check 纳入 task_completion 判定**：执行 `tasks-status` 后，若 `has_incomplete=true`，`check_result` 的 `--result` 应标 `partial` 并在 `warning_items` 记录未勾选项（`{category:"task_completion", description:"N 项验收未勾选", target:"tasks.md:行号"}`）。不阻断 apply（P4 已与 fixRate 解耦），但反映真实完成度。
 
@@ -270,7 +274,11 @@ node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" record --type=conformance_revie
 > - `assertions[].judge_status` 枚举：`matched` / `partial` / `missed`
 > - `assertions[].human_status` 枚举：`matched` / `partial` / `missed` / 省略（默认跟随 judge_status）
 
-> **reviewer 与 reviewer_independence 说明**：`reviewer` 用于标识实际执行本次符合度评审的代理或会话（例如 agent 名称、会话 ID）。渲染报告时会比较 `reviewer` 与 apply 阶段记录的 `apply_agent`：若两者相同，则 `reviewer_independence` 显示为 `self-review`；否则显示为 `independent-review`。建议尽可能由独立评审方执行 check，以提升结果可信度。
+> **reviewer 与 reviewer_independence 说明（check_result）**：执行 check 前先读取文档作者/阶段会话信息；**能使用独立 evaluator 时必须使用**。`reviewer_independence=independent-review` 且 `review_session_id` 与 `author_session_id` 不同时，Q3 为 `verified`；自评或无法确认时为 `self-review` 或 `unknown`，Q3 标 `provisional` 但仍可计算分数。
+
+> **报告用语**：`verified` 展示为“已验证”，表示有独立复核；`provisional` 展示为“临时”，表示已有数值但仍需独立复核。不得仅用颜色区分，也不得把临时结果写成最终可信结论。
+
+> **reviewer 与 reviewer_independence 说明（conformance_review）**：`reviewer` 用于标识实际执行本次符合度评审的代理或会话（例如 agent 名称、会话 ID）。渲染报告时会比较 `reviewer` 与 apply 阶段记录的 `apply_agent`：若两者相同，则 `reviewer_independence` 显示为 `self-review`；否则显示为 `independent-review`。建议尽可能由独立评审方执行 check，以提升结果可信度。
 
 ### 6. 【交互引导】根据结果引导下一步
 
@@ -288,7 +296,7 @@ node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" record --type=conformance_revie
 > - A. 逐个修复（引导到对应命令）
 > - B. 忽略警告继续"
 
-> **📊 过程记录（U3）**：若用户选择 A 逐个修复，或在 check 后、归档前补充修复（补 README/CHANGELOG、勾 checkbox 等），每个修复动作**必须**记 `process_note` 事件（`kind=fix`，`command=check`），归档前修补不再黑箱。**若本阶段存在失败/门禁拦截但无对应 `process_note`，`sdd-apply-test-gate` 会记 `telemetry_warning(process_note_missing)`（不阻断，但报告过程质量信号会标红）。** 必记节点清单见 `opsx-apply/reference.md`「process_note」。
+> **📊 过程记录（U3）**：若用户选择 A 逐个修复，或在 check 后、归档前补充修复（补 README/CHANGELOG、勾 checkbox 等），每个修复动作**必须**记 `process_note` 事件（`kind=recovery`，`command=check`），归档前修补不再黑箱。**若本阶段存在失败/门禁拦截但无对应 `process_note`，`sdd-apply-test-gate` 会记 `telemetry_warning(process_note_missing)`（不阻断，但报告过程质量信号会标红）。** 必记节点清单见 `opsx-apply/reference.md`「process_note」。
 
 ---
 

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

@@ -20,10 +20,11 @@ description: "opsx-check 阶段日志自检清单 — 仅在 check 自检时读
 - [ ] `warnings`: 建议修复的问题数
 - [ ] `suggestions`: 可选优化建议数
 - [ ] `fixed_before_apply`: 进入 apply 前已通过/已确认满足门禁的检查项数
-- [ ] `consistency_score`: 跨文档一致性评分 0-1；无法评分填 `null`
+- [ ] `consistency_score`: legacy 兼容字段；跨文档一致性评分 0-1，无法评分填 `null`
+- [ ] `reviewer` / `review_session_id` / `author_session_id` / `reviewer_independence`: Q3 独立性元数据已填写；优先独立 evaluator，不可用时标 `self-review` 或 `unknown`（Q3 provisional）
 - [ ] `categories`: 至少含 `completeness` / `consistency` / `executability`
 - [ ] `task_completion`: 从 `tasks-status` 整理；未进入 apply 时 `checked_for_archive_readiness=false`
-- [ ] **P1-1**：`check_result` 事件 `details` 非空且含 `consistency_score` 键（禁止空 `{}`，否则 Q5 为 null）
+- [ ] **P1-1**：`check_result` 事件 `details` 非空且含 `categories` 等必填键（禁止空 `{}`，否则 Q3 不可计算）
 - [ ] **P2-3**：`has_incomplete=true` 时 `check_result.result=partial` 且 `warning_items` 含 task_completion 项
 
 ## C. execution-log 状态标记
@@ -40,15 +41,15 @@ description: "opsx-check 阶段日志自检清单 — 仅在 check 自检时读
 
 - [ ] **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`）
+- [ ] **AC 变体覆盖**：spec.md 中含"或"条件的 AC 场景，其 RED 任务验收标准列出所有变体的测试方法（引用 `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 项）逐项检查。
+⛔ 执行 `tdd-core/checklist.md` §B（11 项）逐项检查。
 
-> 不在此内联复制，以 opsx-tdd-core/checklist.md §B 为唯一真相源。
-> 额外补充：还需检查 `opsx-tdd-rules/rules/exception-path-coverage.md`（异常路径覆盖门禁）。
+> 不在此内联复制，以 tdd-core/checklist.md §B 为唯一真相源。
+> 额外补充：还需检查 `tdd-rules/rules/exception-path-coverage.md`（异常路径覆盖门禁）。
 
 **检查项适用阶段**：
 - **apply 前可验证**（文档级）：§B 中除"GREEN 任务输出不含未测试的 Controller/Filter/Config"外的所有检查项（含 Controller 策略声明和测试任务生成）

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

@@ -141,7 +141,7 @@ openspec list
 
 **输出路径**：`changes/<name>/specs/<capability>/design.md`
 
-**⛔ DES 步骤级标注（TDD 模式强制）**：当 `test-strategy=tdd` 时，被多个 RED/GREEN 对映射的 DES 元素必须标注步骤级任务归属。规则详见 `opsx-tdd-rules/rules/des-step-annotation.md`
+**⛔ DES 步骤级标注（TDD 模式强制）**：当 `test-strategy=tdd` 时，被多个 RED/GREEN 对映射的 DES 元素必须标注步骤级任务归属。规则详见 `tdd-rules/rules/des-step-annotation.md`
 
 ### 6.5 【version 正则注释】允许前导零
 

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

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

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

@@ -41,6 +41,7 @@ allowed-tools:
 > - ${SHELL_GUIDANCE}
 > - 不要省略 `--source=opsx-command` 与 `--session-id=<会话ID>`。
 > **📊 Telemetry（必做，不得跳过）** — 阶段开始 / 阶段结束**命令模板**见 `./reference.md`「📊 Telemetry 命令模板」。
+> - 用户确认变更范围、`mode`、`test-strategy` 或方案 A/B/C 时，记录严格 `process_note`：`kind=user_decision`，并分别填写 `decision_type=scope|mode|test_strategy|other`。同一决定只记录一次，后续改变范围时改用 `kind=scope_change`。
 
 ---
 
@@ -267,6 +268,12 @@ Read openspec/changes/archive/*/ontology-identities.json
 
 **❗ 必须主动询问用户，不得默认选择**。Full / Simple / Auto 三种模式的目录结构、适用场景与 AskUserQuestion 文案见 `./reference.md`「§7 文档拆分模式选择」。根据用户选择设置 `mode: full | simple`（Auto 按能力域数量判断），记录到 proposal.md 的 YAML frontmatter。
 
+### 7.5 【交互引导】变更类型确认
+
+**❗ 必须主动询问用户，不得默认选择**。在模式与测试策略选择附近，基于需求给出 `change-type` **推荐**并让用户确认；Auto 只能推荐，**禁止无提示静默写入**。
+
+允许值固定为：`config | document | report | composite | other`（写入 proposal.md YAML frontmatter 的 `change-type` 字段）。AskUserQuestion 文案与类型说明见 `./reference.md`「§7.5 变更类型选择」。
+
 ### 8. 【交互引导】测试策略选择
 
 **❗ 必须主动询问用户，不得默认选择**。TDD / Impl-First / None 三种策略的 DAG 结构、适用场景与 AskUserQuestion 文案见 `./reference.md`「§8 测试策略选择」。根据用户选择设置 `test-strategy: tdd | impl-first | none`，记录到 proposal.md 的 YAML frontmatter。
@@ -333,10 +340,11 @@ Read openspec/changes/archive/*/ontology-identities.json
 - **⛔ 阶段边界**：本阶段禁止执行任何代码创建/修改操作。若用户要求处理代码，回复：「当前处于 Propose 阶段，代码操作请在完成文档后使用 `/opsx-apply` 执行。」
 - **⛔ 单阶段原则**：完成 proposal.md 后必须立即停止。仅提示用户下一步可运行 `/opsx-spec`，绝对禁止自动执行 spec/design/task 等后续阶段。每个阶段必须由用户主动触发。
 - **⛔ Frontmatter 规范（L7）**：YAML frontmatter 中禁止写 `#` 注释（YAML 注释在 frontmatter 中可能导致解析问题）。如需说明，在 frontmatter 之前或之后用正文描述。
+- **⛔ change-type 必采**：frontmatter 必须含 `change-type`，取值仅限 `config | document | report | composite | other`；Agent 可推荐但须经用户确认后写入，禁止静默默认。
 
 ---
 
 ## 渐进披露
 
 - Read `checklist.md` 仅在执行 propose 需要校验时 — 含阶段边界⛔（Propose 阶段约束）、§6 需求完整性检查、Guardrails ⛔ 强制项勾选表。
-- Read `reference.md` 仅在需要参考详细模板时 — 含 📊 Telemetry 命令模板（start/end）、§7 文档拆分模式（Full/Simple/Auto）、§8 测试策略（TDD/Impl-First/None）、§10 质量红线自检清单（8 项）。
+- Read `reference.md` 仅在需要参考详细模板时 — 含 📊 Telemetry 命令模板（start/end）、§7 文档拆分模式（Full/Simple/Auto）、§7.5 变更类型（config/document/report/composite/other）、§8 测试策略（TDD/Impl-First/None）、§10 质量红线自检清单（8 项）。

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

@@ -4,7 +4,7 @@ description: opsx-propose 的详细模板：telemetry 命令、文档拆分模
 
 # opsx-propose — 详细参考（reference）
 
-> 本文件承载 opsx-propose 的重细节模板：telemetry 命令、§7 文档拆分模式说明、§8 测试策略说明、§10 质量红线自检清单。
+> 本文件承载 opsx-propose 的重细节模板：telemetry 命令、§7 文档拆分模式说明、§7.5 变更类型说明、§8 测试策略说明、§10 质量红线自检清单。
 > SKILL.md 保留入口骨架与指针；本文件为详细模板来源。
 
 ---
@@ -48,6 +48,31 @@ description: opsx-propose 的详细模板：telemetry 命令、文档拆分模
 
 ---
 
+## §7.5 变更类型选择
+
+**❗ 必须主动询问用户，不得默认选择；Auto 仅给推荐，禁止无提示写入**
+
+分析需求后，Agent 先给出推荐类型，再使用 **AskUserQuestion** 让用户确认：
+
+> "📊 **变更类型（用于 V3 指标分层统计）**
+>
+> 根据本次需求，推荐类型：**[config | document | report | composite | other]** — [一句话理由]
+>
+> 请选择或确认：
+> - **config** — 配置/开关/环境/依赖调整，几乎不改业务逻辑
+> - **document** — 文档、规范、模板、注释类变更
+> - **report** — 报告、度量、仪表盘、采集契约类变更
+> - **composite** — 跨多类能力的组合变更
+> - **other** — 以上均不合适时使用
+>
+> A) 采用推荐  B) 手动选择其他类型"
+
+根据用户确认，在 proposal.md YAML frontmatter 写入 `change-type: <值>`。允许值固定：`config | document | report | composite | other`。
+
+> 历史 proposal 缺该字段时，报告侧归为 `unknown`；本阶段不得替用户猜测补写。
+
+---
+
 ## §8 测试策略选择
 
 **❗ 必须主动询问用户，不得默认选择**
@@ -66,8 +91,8 @@ description: opsx-propose 的详细模板：telemetry 命令、文档拆分模
 
 **将用户选择记录到 proposal.md 的 YAML frontmatter 中。**
 
-> 完整策略定义见 opsx-tdd-core/SKILL.md §5
-> 交互引导文案见 opsx-tdd-rules/rules/tdd-strategy-selection.md
+> 完整策略定义见 tdd-core/SKILL.md §5
+> 交互引导文案见 tdd-rules/rules/tdd-strategy-selection.md
 
 ---
 
@@ -82,5 +107,6 @@ description: opsx-propose 的详细模板：telemetry 命令、文档拆分模
 - [ ] 前置依赖使用 checkbox 格式
 - [ ] 文档末尾包含质量红线检查清单
 - [ ] 能力分解章节已明确（决定后续 specs 文件夹结构）
+- [ ] frontmatter 含 `change-type`，取值为 `config | document | report | composite | other` 之一且经用户确认
 
 **如有任意一项未满足，重新生成对应章节，直至全部通过。**

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

@@ -1,6 +1,8 @@
 # opsx-rules 参考 — 落位矩阵与格式模板
 
 > **权威源说明**：本文件是 skill **运行时**的落位矩阵真相源（部署到目标项目后无法 `require` kld-sdd 的 `lib/`）。`lib/tool-profiles.js` 中的 `rulesDir` / `rulesFormat` / `rulesWiring` 为 **init 契约与测试断言**；变更时须与本表同步，以本表为准写入规则文件。
+>
+> **边界**：SkyWalk Telemetry 的事件 schema、`run_id`、`test_event_id` 等属于 SDD 工具协议，不属于业务项目规则。生成或 review 五类项目规则时，不把 telemetry 命令或事件字段写入规则正文。
 
 ## 落位矩阵
 
@@ -80,7 +82,7 @@ trigger: always_on
 |------|--------|----------|----------|
 | 架构规范 | `architecture` | 目录分层、模块边界、入口 | 分层约定、禁止循环依赖、新代码落位 |
 | 编码规范 | `coding-style` | 语言、lint、缩进 | 命名、缩进、注释语言、CommonJS/ESM |
-| 测试约定 | `testing` | test 目录、框架 | 测试命令、命名、TDD 期望（见 opsx-tdd-core/SKILL.md §5） |
+| 测试约定 | `testing` | test 目录、框架 | 测试命令、命名、TDD 期望（见 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

@@ -214,7 +214,7 @@ node "$(cat .sdd-spec-root)/skywalk-sdd/context-client.cjs" \
 - 需求项使用 `####`（4个#）
 - 场景使用 `#####`（5个#）
 
-**⛔ 多校验拆分规则（TDD 关键）**：当单个 STMT 包含多个"必须校验"条件时，每个校验条件必须有对应的独立 AC 场景。规则详见 `opsx-tdd-rules/rules/multi-validation-split.md`
+**⛔ 多校验拆分规则（TDD 关键）**：当单个 STMT 包含多个"必须校验"条件时，每个校验条件必须有对应的独立 AC 场景。规则详见 `tdd-rules/rules/multi-validation-split.md`
 
 ### 6.5 【Node 版本约束来源校验】
 

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

@@ -34,7 +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`）
+- [ ] ⛔ **多校验拆分（TDD 模式）**：当 test-strategy=tdd 时，单个 STMT 包含多个"必须校验"条件时，每个校验条件有对应的独立 AC 场景（规则见 `tdd-rules/rules/multi-validation-split.md`）
 
 **如有任意一项未满足，重新生成对应章节，直至全部通过。** 自检完成后必须输出结构化自检报告（模板见 `./reference.md`「§7 质量自检报告模板」），未通过项自动修复后重新输出。
 

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

@@ -150,8 +150,8 @@ Simple 模式或单文件能力域下，**不要拆成多个同文件任务**。
 
 **若未设置**：使用 **AskUserQuestion** 工具询问（A/B/C 三选一）
 
-> 完整策略定义见 opsx-tdd-core/SKILL.md §5
-> 交互引导文案见 opsx-tdd-rules/rules/tdd-strategy-selection.md
+> 完整策略定义见 tdd-core/SKILL.md §5
+> 交互引导文案见 tdd-rules/rules/tdd-strategy-selection.md
 
 ### 6. 【交互引导】确认任务拆解策略
 
@@ -185,19 +185,19 @@ Simple 模式或单文件能力域下，**不要拆成多个同文件任务**。
 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`
+7. ⛔ **GREEN 任务 YAGNI 围栏**：每个 GREEN-N 任务描述末尾必须包含"不提前实现 [后续 RED 行为]"围栏声明。规则详见 `tdd-rules/rules/green-yagni-fence.md`
 8. ⛔ **TDD 模式 DAG 并行标注**：当 `test-strategy=tdd` 时，DAG 拓扑图中每个 RED→GREEN 对必须标注 `⛔ 串行：不可同层并行`。同层存在多个 RED→GREEN 对时，必须在拓扑图中显式注明"本层 RED→GREEN 对须逐对串行执行，禁止并行派发"。非 TDD 模块的同层任务（如 UI/配置/SQL DDL）仍可并行。
 
 ⛔ 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（异常路径测试覆盖门禁）
+1. tdd-core/reference.md §6（DAG 生成规则表）
+2. tdd-rules/rules/dag-generation-rules.md（DAG 规则文件）
+3. tdd-rules/rules/controller-strategy.md（Controller 策略 A/B）
+4. 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
+> 完整 TDD 拆分示例见 tdd-core/reference.md §4
+> 非 TDD 模块定义见 tdd-rules/rules/non-tdd-modules.md
+> 任务类型定义见 tdd-rules/rules/task-type-definitions.md
 
 ### 8. 质量红线自检
 

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

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

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

@@ -18,7 +18,7 @@ description: opsx-task 的详细模板：telemetry 命令、DAG 生成规则表
 
 ## §6 DAG 生成规则表
 
-> 完整规则见 `opsx-tdd-rules/rules/dag-generation-rules.md`，此处仅保留快速参考。
+> 完整规则见 `tdd-rules/rules/dag-generation-rules.md`，此处仅保留快速参考。
 
 **根据 test-strategy 调整 DAG 生成规则：**
 
@@ -52,7 +52,7 @@ spec.md user-auth 定义了 7 个场景，拆为 7 对 RED+GREEN + 1 个 REFACTO
 | 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`
+> GREEN 任务的 YAGNI 围栏生成规则详见 `tdd-rules/rules/green-yagni-fence.md`
 
 **关键区别**：
 - 每个 RED 任务都带**真实断言**，跑起来确实失败
@@ -86,7 +86,7 @@ spec.md user-auth 定义了 7 个场景，拆为 7 对 RED+GREEN + 1 个 REFACTO
 
 ## §6.2 非 TDD 模块处理规则
 
-> 完整规则见 `opsx-tdd-rules/rules/non-tdd-modules.md`，此处仅保留快速参考。
+> 完整规则见 `tdd-rules/rules/non-tdd-modules.md`，此处仅保留快速参考。
 
 以下模块不需要红绿循环，按常规任务处理：
 - 前端 UI 页面（Vue 组件）→ UI层任务

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

@@ -105,13 +105,15 @@ allowed-tools:
 
 ### 4a. 【M3 Telemetry】记录测试结果
 
-测试执行完成后，在 stage_end 之前记录 `test_result` 事件：
+每一次真实测试执行只记录一条 `test_result`，不得把同一次命令的结果复制到多个任务，也不得用估算值补齐用例数。测试执行完成后，在 stage_end 之前记录：
 
 ```bash
-node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" record --type=test_result --command=test --project=. --change=<变更名称> --capability=<可选capability-name> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID> --result=success/failure --summary="[passed]/[total] passed" --details-json="{\"test_results\":{\"command\":\"<实际测试命令>\",\"passed\":<passed>,\"failed\":<failed>,\"skipped\":<skipped>,\"coverage\":<coverage>,\"duration_ms\":<duration_ms>}}"
+node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" record --strict --type=test_result --command=test --project=. --change=<变更名称> --capability=<可选capability-name> --task-id=<首个TASK-ID> --run-id=<本次真实执行的稳定ID> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID> --result=success/failure --summary="<人能看懂的测试结论>" --details-json="{\"test_results\":{\"snapshot_kind\":\"final\",\"verified_task_ids\":[\"<TASK-ID-1>\",\"<TASK-ID-2>\"],\"tdd_phase\":\"<red|green|refactor|regression|not-applicable>\",\"command\":\"<实际测试命令>\",\"exit_code\":<退出码>,\"counts_known\":<true|false>,\"passed\":<counts_known=true时填写>,\"failed\":<counts_known=true时填写>,\"skipped\":<counts_known=true时填写>,\"duration_ms\":<实测毫秒>,\"failure_type\":\"<assertion|contract|compile|infrastructure|timeout|none>\",\"expected_failure\":<仅RED预期失败时true>}}"
 ```
 
-此事件供 report 的 `test_pass_summary` 采集（M3），确保报告能显示真实测试通过率。
+`run_id` 在同一次执行重试写入时必须保持不变：相同内容会幂等跳过，不同内容会被判为冲突。`counts_known=false` 时省略 `passed/failed/skipped`，绝不写虚构的 `0`。RED 只有在 `expected_failure=true`、退出码非 0 且失败类型为 `assertion` 或 `contract` 时才是有效 RED；基础设施或编译错误不算。
+
+此事件供任务完成证据和最终报告采集。最终回归必须写 `snapshot_kind:"final"`；一次执行覆盖多个任务时用去重的 `verified_task_ids`，仍只写一条事件。后续 `task_update` 只引用本事件返回的 `event_id`，不再内嵌或复制测试计数。
 
 > **⚠️ P1-4 coverage 不得为 null**：`test_results.coverage` 必须填实测覆盖率数值（跑了 `--coverage` 就填数值，如 `86.5`）；未跑 `--coverage` 时填字符串 `"not-run"` 并在 summary 说明原因。**禁止填 `null`**。若 `proposal.md` 含"覆盖率 ≥ X%"验收标准，强制使用 `--coverage` 运行测试。
 
@@ -148,8 +150,8 @@ node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" record --type=test_result --com
 - [ ] 无"生产类中加测试专用方法"
 - [ ] 无"不理解依赖就 mock"
 
-> 完整 12 项反模式检测见 opsx-tdd-anti-patterns/SKILL.md §4
-> TDD 报告模式见 opsx-tdd-review/SKILL.md §3
+> 完整 12 项反模式检测见 tdd-anti-patterns/SKILL.md §4
+> TDD 报告模式见 tdd-review/SKILL.md §3
 
 ### 6. 【交互引导】根据结果引导下一步
 

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

@@ -1,9 +1,9 @@
 ---
-name: opsx-tdd-anti-patterns
+name: tdd-anti-patterns
 description: "测试反模式防护层 — 16 种反模式检测（RED 阶段 3 种 + GREEN 后 13 种），每种带门禁函数和修复方案。当编写或审查测试代码时引用本技能。"
 ---
 
-# opsx-tdd-anti-patterns — 反模式防护层
+# tdd-anti-patterns — 反模式防护层
 
 > **定位**：测试反模式的系统化检测，RED 阶段 + GREEN 后双重检查。
 > **参考来源**：Superpowers `testing-anti-patterns.md`
@@ -47,8 +47,8 @@ description: "测试反模式防护层 — 16 种反模式检测（RED 阶段 3
 | 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`） |
-| 16 | **AC 变体覆盖不足** | AC 场景描述含"或"条件（如"缺少 A 或 B 或为空"），但测试只覆盖部分变体 | AC 中每个"或"条件变体必须有对应测试方法（规则见 `opsx-tdd-rules/rules/multi-validation-split.md` §AC 内"或"条件变体覆盖） |
+| 15 | **缺少负面测试** | 只测试正常路径，不测试错误条件 | 每个方法至少有一个异常路径测试（见 `tdd-rules/rules/exception-path-coverage.md`） |
+| 16 | **AC 变体覆盖不足** | AC 场景描述含"或"条件（如"缺少 A 或 B 或为空"），但测试只覆盖部分变体 | AC 中每个"或"条件变体必须有对应测试方法（规则见 `tdd-rules/rules/multi-validation-split.md` §AC 内"或"条件变体覆盖） |
 
 ## §5 门禁函数
 

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

@@ -1,8 +1,8 @@
 ---
-description: "opsx-tdd-anti-patterns 详细参考 — 9 种反模式完整详表 + 修复方案代码示例。仅在需要详细反模式检查时读取。"
+description: "tdd-anti-patterns 详细参考 — 9 种反模式完整详表 + 修复方案代码示例。仅在需要详细反模式检查时读取。"
 ---
 
-# opsx-tdd-anti-patterns — 详细参考
+# tdd-anti-patterns — 详细参考
 
 > 仅在需要详细反模式检查时读取。日常检查见 `SKILL.md`。
 
@@ -193,7 +193,7 @@ assertEquals("user-001", result.getUserId());
 
 **问题**：只测试正常路径，不测试错误条件。
 
-**修复**：每个方法至少有一个异常路径测试。规则见 `opsx-tdd-rules/rules/exception-path-coverage.md`。
+**修复**：每个方法至少有一个异常路径测试。规则见 `tdd-rules/rules/exception-path-coverage.md`。
 
 ## 反模式 16：AC 变体覆盖不足
 
@@ -222,7 +222,7 @@ void login_withMissingParams_returns1001() {
 @Test void login_withBothMissing_returns1001() { ... }
 ```
 
-**修复**：AC 中每个"或"条件变体必须有对应测试方法。规则见 `opsx-tdd-rules/rules/multi-validation-split.md` §AC 内"或"条件变体覆盖。
+**修复**：AC 中每个"或"条件变体必须有对应测试方法。规则见 `tdd-rules/rules/multi-validation-split.md` §AC 内"或"条件变体覆盖。
 
 ## TDD 如何防止这些反模式
 

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

@@ -1,9 +1,9 @@
 ---
-name: opsx-tdd-core
+name: tdd-core
 description: "TDD 流程纪律层 — 铁律、红绿重构循环、执行门禁、合规自检。当 test-strategy=tdd 时，所有 SDD 阶段引用本技能获取 TDD 流程规则。"
 ---
 
-# opsx-tdd-core — TDD 流程纪律层
+# tdd-core — TDD 流程纪律层
 
 > **定位**：TDD 铁律、红绿重构循环定义、执行门禁的唯一真相源。
 > **参考来源**：Superpowers `test-driven-development`
@@ -81,7 +81,7 @@ RED → Verify RED → 🔴中断声明 → GREEN → Verify GREEN → GREEN Sco
   - 此声明强制 agent 在 RED 和 GREEN 之间产生节奏断点，防止从 RED 滑入 GREEN 再滑入下一个行为点
 - **GREEN**：写最简单的代码通过测试
   - 不添加功能、不重构其他代码、不"改进"超出测试范围的内容
-  - ⛔ **执行 GREEN Scope 声明**（见 `opsx-tdd-rules/rules/green-scope-declaration.md`）：
+  - ⛔ **执行 GREEN Scope 声明**（见 `tdd-rules/rules/green-scope-declaration.md`）：
     1. 列出当前 RED 测试的断言清单
     2. 列出 design.md 中本 DES 元素的完整流程步骤
     3. 标记步骤归属（✅ 属于当前 RED / ⛔ 属于后续 RED）
@@ -126,12 +126,12 @@ RED → Verify RED → 🔴中断声明 → GREEN → Verify GREEN → GREEN Sco
 - **REFACTOR**：仅在绿色之后
   - 移除重复、改善命名、提取辅助函数
   - 保持测试绿色，不添加行为
-  - ⛔ 执行 `opsx-tdd-rules/rules/refactor-checklist.md`（7 项重构检查点）
+  - ⛔ 执行 `tdd-rules/rules/refactor-checklist.md`（7 项重构检查点）
 - **Repeat**：下一个失败测试，下一个功能
 
 ## §4 执行门禁
 
-> 完整规则见 `opsx-tdd-rules/rules/test-execution-gate.md`，此处仅保留快速参考。
+> 完整规则见 `tdd-rules/rules/test-execution-gate.md`，此处仅保留快速参考。
 
 | test-strategy | 行为 |
 |---------------|------|
@@ -141,7 +141,7 @@ RED → Verify RED → 🔴中断声明 → GREEN → Verify GREEN → GREEN Sco
 
 ## §5 TDD 策略定义
 
-> 完整规则见 `opsx-tdd-rules/rules/tdd-strategy-selection.md`，此处仅保留快速参考。
+> 完整规则见 `tdd-rules/rules/tdd-strategy-selection.md`，此处仅保留快速参考。
 
 三种策略（tdd/impl-first/none）的定义与适用场景：
 
@@ -151,7 +151,7 @@ RED → Verify RED → 🔴中断声明 → GREEN → Verify GREEN → GREEN Sco
 
 ## §6 Controller 层策略
 
-> 完整规则见 `opsx-tdd-rules/rules/controller-strategy.md`，此处仅保留快速参考。
+> 完整规则见 `tdd-rules/rules/controller-strategy.md`，此处仅保留快速参考。
 
 ⛔ Controller 层**必须**有测试。两种策略的区别在于测试方式，而非"有无测试"。
 
@@ -214,14 +214,14 @@ RED → Verify RED → 🔴中断声明 → GREEN → Verify GREEN → GREEN Sco
 
 ## §10 跨技能引用
 
-- → `opsx-tdd-quality`：单测代码质量标准（Mock 边界矩阵、命名规范、Java 规则等）
-- → `opsx-tdd-anti-patterns`：测试反模式检测（15 种反模式 + 门禁函数）
-- → `opsx-tdd-review`：测试审查（8 项质量检查 + 缺失测试检测）
-- → `opsx-tdd-metrics`：度量分析（隔离评分、命名评分、覆盖率缺口）
-- → `opsx-tdd-rules`：规则库（DAG 规则、Controller 策略、telemetry 模板等）
+- → `tdd-quality`：单测代码质量标准（Mock 边界矩阵、命名规范、Java 规则等）
+- → `tdd-anti-patterns`：测试反模式检测（15 种反模式 + 门禁函数）
+- → `tdd-review`：测试审查（8 项质量检查 + 缺失测试检测）
+- → `tdd-metrics`：度量分析（隔离评分、命名评分、覆盖率缺口）
+- → `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）
+  - `rules/refactor-checklist.md`：REFACTOR 阶段检查点（引用方：opsx-apply, tdd-core）

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

@@ -1,8 +1,8 @@
 ---
-description: "opsx-tdd-core 自检清单 — TDD 执行合规自检、合规性检查、完成验证。仅在执行 TDD 任务自检时读取。"
+description: "tdd-core 自检清单 — TDD 执行合规自检、合规性检查、完成验证。仅在执行 TDD 任务自检时读取。"
 ---
 
-# opsx-tdd-core — 自检清单
+# tdd-core — 自检清单
 
 > 仅在执行 TDD 任务自检时读取。日常流程见 `SKILL.md`。
 
@@ -18,7 +18,7 @@ description: "opsx-tdd-core 自检清单 — TDD 执行合规自检、合规性
 - [ ] ⛔ **RED→GREEN 中断声明已执行**：RED 确认失败后，显式声明了"🔴 RED-N 确认失败，现在进入 GREEN-N"
 - [ ] GREEN 任务已运行测试确认通过
 - [ ] GREEN 未提前实现没有测试要求的功能
-- [ ] ⛔ **GREEN Scope 越界检测**：GREEN 实现后检查生产代码是否包含未被当前 RED 断言覆盖的逻辑分支（规则见 `opsx-tdd-rules/rules/green-scope-declaration.md` §Scope 自检）
+- [ ] ⛔ **GREEN Scope 越界检测**：GREEN 实现后检查生产代码是否包含未被当前 RED 断言覆盖的逻辑分支（规则见 `tdd-rules/rules/green-scope-declaration.md` §Scope 自检）
 - [ ] ⛔ **GREEN YAGNI 围栏逐条确认**：读取 tasks.md 中本 GREEN 任务的 YAGNI 围栏声明，逐条确认"未实现 [后续 RED 的行为]：✅"
 - [ ] ⛔ **GREEN Scope 门禁已执行**：Verify GREEN 之后，检查生产代码无越界逻辑分支
 - [ ] REFACTOR 后全部测试仍绿
@@ -42,7 +42,7 @@ description: "opsx-tdd-core 自检清单 — TDD 执行合规自检、合规性
 - [ ] 每个 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`）
+- [ ] ⛔ **AC 变体覆盖**：spec.md 中含"或"条件的 AC 场景，其 RED 任务验收标准列出所有变体的测试方法（引用 `tdd-rules/rules/multi-validation-split.md`）
 
 ## §C 完成验证清单（8 项）
 
@@ -56,6 +56,6 @@ description: "opsx-tdd-core 自检清单 — TDD 执行合规自检、合规性
 - [ ] 输出纯净（无错误/警告）
 - [ ] 测试使用真实代码（仅在不可避免时使用 mock）
 - [ ] 边界情况和错误已覆盖
-- [ ] ⛔ **AC "或"条件变体全覆盖**：AC 场景描述含"或"条件时，每个变体都有对应测试方法（引用 `opsx-tdd-rules/rules/multi-validation-split.md`）
+- [ ] ⛔ **AC "或"条件变体全覆盖**：AC 场景描述含"或"条件时，每个变体都有对应测试方法（引用 `tdd-rules/rules/multi-validation-split.md`）
 
 > Can't check all boxes? You skipped TDD. Start over.