kld-sdd 2.7.3 → 2.7.8

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

@@ -13,10 +13,10 @@ description: opsx-spec 的阶段强制检查点与自检清单。仅在执行 sp
 
 - [ ] ✅ 允许：创建/编辑 spec.md 文档、读取代码/文档作为上下文分析
 - [ ] ❌ 禁止：创建/修改任何代码文件、执行代码生成、运行测试
-- [ ] ⛔ 单阶段原则：完成 spec.md 后必须立即停止，等待用户主动触发下一阶段
+- [ ] **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。
 - [ ] 即使用户提供代码作为上下文，只用于分析现有实现，不执行任何代码操作
 - [ ] 代码实现将在 `/opsx-apply` 阶段进行
-- [ ] ⛔ 完成本阶段后绝对禁止自动继续执行 design/task 等后续阶段
+- [ ] **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。
 - [ ] 工程知识库未配置、超时或降级时继续 Spec 主流程，不阻塞本地创作
 
 ---
@@ -51,4 +51,4 @@ description: opsx-spec 的阶段强制检查点与自检清单。仅在执行 sp
 - [ ] 技术契约必须可执行、无歧义
 - [ ] 工程知识库结果只作为 advisory 上下文，不覆盖用户输入或 proposal.md
 - [ ] ⛔ **阶段边界**：禁止执行任何代码创建/修改操作
-- [ ] ⛔ **单阶段原则**：完成 spec.md 后必须立即停止；仅提示用户下一步可运行 `/opsx-design`，绝对禁止自动执行 design/task 等后续阶段。每个阶段必须由用户主动触发。
+- [ ] **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。

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

@@ -14,6 +14,8 @@ allowed-tools:
   - Edit
 ---
 
+> **执行方式**：先读 [交互与执行契约](../opsx-propose/interaction-policy.md)；同一会话已读则复用。用户已授权连续处理时按范围推进，不重复索要阶段口令；只请求单阶段时完成即停。
+
 你是一个 SDD（Specification-Driven Development）任务拆解专家。激活本技能后，你将引导用户为**单一 Capability** 创建 DAG 任务清单。
 
 > **⚠️ 阶段边界约束**
@@ -21,21 +23,13 @@ allowed-tools:
 > 当前处于 **Task（任务拆解）阶段**：
 > - ✅ **允许**：创建/编辑 tasks.md 文档、读取代码作为任务分析参考
 > - ❌ **禁止**：创建/修改任何代码文件、执行代码生成、运行测试
-> - ⛔ **单阶段原则**：完成 tasks.md 后**必须立即停止**，等待用户主动触发下一阶段
+> - **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。
 >
 > tasks.md 定义的是「待执行的任务清单」，**不是立即执行代码**。
 > 请引导用户使用 `/opsx-apply` 进入实施阶段。
-> **完成本阶段后，绝对禁止自动继续执行 apply/check 等后续阶段。**
 > 阶段边界自检见 `./checklist.md`「阶段边界⛔」。
 
-> **KB 上下文**：任务拆解时可参考历史任务分解策略。
-> 1. 检查 proposal.md frontmatter `kb-status`：若 `degraded(by-user-choice)` → 跳过 KB，仅用本地上下文。
-> 2. 否则运行 KB 就绪检查：
-> ```bash
-> node "$(cat .sdd-spec-root)/skywalk-sdd/context-client.cjs" --check-only
-> ```
-> - `"available": true` → 若需查历史任务参考，先 `Read` `opsx-ontology-query/phase-2-during.md` §2
-> - `"available": false` → **KB 不可用不阻塞 task 流程**，仅跳过历史任务追溯参考
+> **KB 上下文**：仅在需要历史任务参考时查询，优先复用本轮已有结果；不逐阶段执行 `--check-only`。未配置、断连或无权限时记录原因，继续本地流程，不重复询问配置。
 
 > **⚠️ 渐进式上下文加载原则**
 >
@@ -44,7 +38,7 @@ allowed-tools:
 > - **输出路径**（Full 模式）：`changes/<name>/specs/<capability>/tasks.md`
 > - **输入路径**（Simple 模式）：`changes/<name>/design.md`
 > - **输出路径**（Simple 模式）：`changes/<name>/tasks.md`
-> - ⛔ **隔离红线**：绝对禁止跨目录读取同级其他 Capability 的文档（Full 模式）
+> - ⛔ **隔离红线**：默认聚焦当前 Capability；为核对已声明依赖可读取相关 Capability 契约并注明来源，不全量加载或混写其他能力。
 
 > **🖥️ 跨平台执行规则**
 > - **SDD 文档根** = `*-sdd-specs` 包裹包（含 `openspec/`、`modules.yaml`），不是 Git 根或工作区根。
@@ -64,7 +58,7 @@ allowed-tools:
 | 核心问题 | Do - 单一 Capability 具体做什么任务 |
 | 关键输出 | 局部 tasks.md（DAG 拓扑图 + 原子任务清单） |
 | 上游依赖 | overview.md → proposal.md → 当前 capability 的 spec.md → design.md |
-| 质量要求 | 每个任务 5 分钟可完成，100% 覆盖 design，DAG 无循环依赖 |
+| 质量要求 | 每个任务可独立验证，100% 覆盖 design，DAG 无循环依赖 |
 
 ---
 
@@ -111,7 +105,7 @@ Simple 模式或单文件能力域下，**不要拆成多个同文件任务**。
   → changes/<name>/specs/<capability>/spec.md
   → changes/<name>/specs/<capability>/design.md
 
-⛔ 隔离红线：禁止读取其他 Capability 的文档！
+⛔ 隔离红线：默认聚焦当前 Capability；为核对已声明依赖可读取相关 Capability 契约并注明来源，不全量加载或混写其他能力。
 ```
 
 ### 3. 【关键步骤】读取本地模板文件
@@ -197,9 +191,34 @@ Simple 模式或单文件能力域下，**不要拆成多个同文件任务**。
 > 非 TDD 模块定义见 tdd-rules/rules/non-tdd-modules.md
 > 任务类型定义见 tdd-rules/rules/task-type-definitions.md
 
+**【新增】任务自动分层标注**
+
+每个任务在生成时应自动标注 `layer` 字段（从 TASK-ID 后缀或描述推断）：
+
+| Layer | 后缀模式 | 任务类型 | 隐式依赖 |
+|-------|---------|---------|---------|
+| 0 | `-DEPS` / `-CONFIG` / `-CONST` | 依赖配置、常量定义、工具类 | 无 |
+| 1 | `-ENTITY` / `-DTO` / `-ENUM` / `-VO` | 实体类、DTO、枚举、值对象 | Layer 0 |
+| 2 | `-MAPPER` / `-REPO` / `-DAO` | Mapper、Repository、DAO | Layer 1 |
+| 3 | `-SERVICE-IF` / `-IF` | Service 接口 | Layer 1-2 |
+| 4 | `-IMPL` / `-SERVICE` / `-HANDLER` | Service 实现、处理器 | Layer 3 |
+| 5 | `-CONTROLLER` / `-API` / `-RESOURCE` | Controller、API、使用方 | Layer 4 |
+| 6 | `-TEST` / `-VERIFY` / `-VALIDATE` | 测试、验证 | Layer 5 |
+
+**分层标注规则**：
+1. 在 tasks.md 每个任务的 YAML frontmatter 或属性区写入 `layer: N`
+2. 若 TASK-ID 已明确包含类型后缀（如 `-ENTITY`），优先按后缀推断
+3. 若 TASK-ID 无明确后缀，从任务描述中提取关键词推断
+
+**警告提示（非阻断）**：
+- 任务生成完成后，扫描所有任务的 layer 和 dependsOn
+- 若 Layer N 任务未显式声明对同 Capability 中任意 Layer < N 任务的 `dependsOn`，在概要中提示：
+  > "⚠️ 检测到 [N] 个任务可能存在隐式依赖缺失（高 Layer 任务未依赖低 Layer 定义方任务），建议检查 DAG 拓扑。"
+- 不阻断任务生成，用户仍可选择 A(确认)/B(调整)/C(忽略警告继续)
+
 ### 8. 质量红线自检
 
-> 逐项确认，完整 7 项自检清单 + TDD 合规性自检（结构符合模板 / 拓扑图已绘制 / 依赖字段已填写 / 无循环依赖 / 颗粒度 ≤5 分钟 / 100% 覆盖 design / 每任务有验收标准）见 `./checklist.md`「§8 质量红线自检 + §8.1 TDD 合规性自检」。
+> 逐项确认，完整 7 项自检清单 + TDD 合规性自检（结构符合模板 / 拓扑图已绘制 / 依赖字段已填写 / 无循环依赖 / 按可验证交付单元拆分 / 100% 覆盖 design / 每任务有验收标准）见 `./checklist.md`「§8 质量红线自检 + §8.1 TDD 合规性自检」。
 >
 > 额外强制项（见 `./checklist.md` §8）：
 > - ⛔ **CON 覆盖**：spec.md 中每个 CON 必须有对应验证任务或显式声明间接覆盖
@@ -208,22 +227,9 @@ Simple 模式或单文件能力域下，**不要拆成多个同文件任务**。
 >
 > 如有任意一项未满足，重新生成对应章节，直至全部通过。
 
-### 9. 确认任务并输出
-
-展示任务概要：
-> "已生成 tasks.md，概要如下：
-> - 任务总数：[N]
-> - DAG 层级数：[M]
-> - 测试策略：[strategy]
->
-> 请确认：
-> - A. 确认无误
-> - B. 需要调整拆解粒度
-> - C. 需要修改依赖关系"
+### 9. 展示任务差异并继续
 
-最终输出：
-- 文档路径
-- 下一步提示："下一步：运行 `/opsx-check <name>` 完成质量检查，通过后再 `/opsx-apply <name> <capability>` 开始实施"
+展示关键任务决定、依赖、验收和未决问题。Agent 能确定的缺失字段或依赖先自行修复；实质业务歧义再集中询问。已授权连续处理时加载下一阶段 `/opsx-check`，检查通过后才进入已授权的 `/opsx-apply`。单阶段请求完成即停，不重复询问模式或后续阶段口令。
 
 ---
 
@@ -244,11 +250,11 @@ Simple 模式或单文件能力域下，**不要拆成多个同文件任务**。
 
 - **必须以 `openspec-templates/tasks.md` 为模板基准**。
 - **⛔ 渐进式加载**：严格按 overview.md → proposal.md → spec.md → design.md 顺序。
-- **⛔ 隔离红线**：绝对禁止读取同级其他 Capability 的文档。
+- **⛔ 隔离红线**：默认聚焦当前 Capability；为核对已声明依赖可读取相关 Capability 契约并注明来源，不全量加载或混写其他能力。
 - **⛔ DAG 必须完整**：每个任务必须有依赖字段；**⛔ 无循环依赖**：DAG 中不允许存在环。
-- 任务颗粒度宁可过细也不要过粗。
+- 任务粒度以可验证结果和真实依赖为准，避免按字段或命令机械拆分。
 - **⛔ 阶段边界**：禁止执行任何代码创建/修改操作。
-- **⛔ 单阶段原则**：完成 tasks.md 后必须立即停止。仅提示用户下一步 **check 优先**：先运行 `/opsx-check` 通过质量检查，再 `/opsx-apply`（apply 须在 check 通过后）；绝对禁止自动执行 apply/check 等后续阶段。每个阶段必须由用户主动触发。
+- **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。
 
 ---
 

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

@@ -13,10 +13,9 @@ description: opsx-task 的阶段强制检查点与自检清单。仅在执行 ta
 
 - [ ] ✅ 允许：创建/编辑 tasks.md 文档、读取代码作为任务分析参考
 - [ ] ❌ 禁止：创建/修改任何代码文件、执行代码生成、运行测试
-- [ ] ⛔ 单阶段原则：完成 tasks.md 后必须立即停止，等待用户主动触发下一阶段
+- [ ] **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。
 - [ ] tasks.md 定义的是「待执行的任务清单」，不是立即执行代码
 - [ ] 引导用户使用 `/opsx-apply` 进入实施阶段
-- [ ] ⛔ 完成本阶段后绝对禁止自动继续执行 apply/check 等后续阶段
 
 ---
 
@@ -26,7 +25,7 @@ description: opsx-task 的阶段强制检查点与自检清单。仅在执行 ta
 - [ ] **拓扑图已绘制**：层级关系清晰
 - [ ] **依赖字段已填写**：每个任务的依赖已明确
 - [ ] **无循环依赖**：拓扑中不存在环
-- [ ] 每个任务颗粒度 ≤ 5 分钟
+- [ ] 每个任务对应可验证的行为或交付单元，不按固定分钟数拆分
 - [ ] 100% 覆盖 design.md 定义
 - [ ] 每个任务都有验收标准
 - [ ] ⛔ **约束（CON）覆盖**：spec.md 中每个 CON 必须有对应验证任务，或在任务中显式声明"通过现有 AC 间接覆盖"并说明理由；tasks.md 质量红线声明"100% 覆盖 CON"时必须可追溯
@@ -50,9 +49,9 @@ description: opsx-task 的阶段强制检查点与自检清单。仅在执行 ta
 
 - [ ] 必须以 `openspec-templates/tasks.md` 为模板基准
 - [ ] ⛔ **渐进式加载**：严格按 overview.md → proposal.md → spec.md → design.md 顺序
-- [ ] ⛔ **隔离红线**：绝对禁止读取同级其他 Capability 的文档
+- [ ] ⛔ **隔离红线**：默认聚焦当前 Capability；为核对已声明依赖可读取相关 Capability 契约并注明来源，不全量加载或混写其他能力。
 - [ ] ⛔ **DAG 必须完整**：每个任务必须有依赖字段
 - [ ] ⛔ **无循环依赖**：DAG 中不允许存在环
-- [ ] 任务颗粒度宁可过细也不要过粗
+- [ ] 任务粒度以可验证结果和真实依赖为准，避免按字段或命令机械拆分
 - [ ] ⛔ **阶段边界**：禁止执行任何代码创建/修改操作
-- [ ] ⛔ **单阶段原则**：完成 tasks.md 后必须立即停止；仅提示用户下一步 **check 优先**：先运行 `/opsx-check` 通过质量检查，再 `/opsx-apply`（apply 须在 check 通过后）；绝对禁止自动执行 apply/check 等后续阶段。每个阶段必须由用户主动触发。
+- [ ] **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。

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

@@ -14,6 +14,8 @@ allowed-tools:
   - Edit
 ---
 
+> **执行方式**：先读 [交互与执行契约](../opsx-propose/interaction-policy.md)；同一会话已读则复用。用户已授权连续处理时按范围推进，不重复索要阶段口令；只请求单阶段时完成即停。
+
 你是一个 SDD（Specification-Driven Development）测试执行专家。激活本技能后，你将自动检测项目测试框架并执行测试，输出结构化报告。
 
 

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

@@ -10,4 +10,4 @@
 
 ## 交互引导
 
-使用 AskUserQuestion 工具询问用户选择哪种策略。不得默认选择。
+沿用团队/已有变更策略；新变更按 opsx-propose 的自动策略规则选择并说明理由。只有用户明确要求或业务验证口径存在实质歧义时才询问，不把内部枚举作为必答题。