kld-sdd 2.4.7

package/templates/openspec/tasks.md

@@ -0,0 +1,287 @@
+# 实施任务拆解 - [Capability 名称]
+
+> **定位**：单一 Capability 的 AI 编码引擎执行单元
+> 
+> **⚠️ 边界声明**：本任务清单仅服务于当前 Capability，严禁跨模块任务。
+> 
+> **【质量红线】颗粒度必须达到"AI能在5分钟内实现"；且拆解的任务和验证逻辑必须 100% 覆盖 spec 和 design
+
+---
+
+## 1. 任务总览
+
+### 1.1 关联文档
+
+| 文档 | 路径 | 说明 |
+|-----|------|------|
+| 全局契约 | `openspec/specs/overview.md` | 全局约束基线 |
+| 业务意图 | `proposal.md` | 变更背景 |
+| 技术契约 | `specs/[capability]/spec.md` | 当前能力规格 |
+| 技术方案 | `specs/[capability]/design.md` | 当前能力设计 |
+
+### 1.2 实现范围
+
+<!-- 本次编码要覆盖的功能范围 -->
+
+### 1.3 技术栈
+
+- 语言：
+- 框架：
+- 依赖：
+
+---
+
+## 2. 任务执行拓扑图
+
+> **⚠️ 依赖管理**：任务必须按层级执行，每层任务可并行，跨层必须等待前置完成
+
+### 2.0 测试策略
+
+<!-- 该字段从 proposal.md frontmatter 中读取，由 /opsx:propose 阶段用户选择 -->
+
+**当前测试策略**：`[测试驱动 | 实现优先 | 无测试]`
+
+| 策略 | 说明 | 拓扑结构 |
+|--------|------|------------|
+| 测试驱动 | 测试先行 | 测试骨架 → 实现代码 → 测试验证 |
+| 实现优先 | 代码先行 | 实现代码 → 测试验证 |
+| 无测试 | 仅编译检查 | 仅实现代码 |
+
+**测试驱动模式拓扑示例**：
+```
+层级 1: [TASK-01-TEST] 编写 UserService 单元测试（骨架）
+层级 2: [TASK-02-IMPL] 实现 UserService（依赖: TASK-01-TEST）
+层级 3: [TASK-03-VERIFY] 运行测试验证（依赖: TASK-02-IMPL）
+```
+
+**实现优先模式拓扑示例**：
+```
+层级 1: [TASK-01-IMPL] 实现 UserService
+层级 2: [TASK-02-TEST] 编写并运行测试（依赖: TASK-01-IMPL）
+```
+
+### 2.1 拓扑图
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│  层级 1 (无依赖，可并行)                                      │
+│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐       │
+│  │ TASK-XXX-01  │  │ TASK-XXX-02  │  │ TASK-XXX-03  │       │
+│  └──────┬───────┘  └──────┬───────┘  └──────────────┘       │
+│         │                 │                                  │
+│         v                 v                                  │
+│  ┌─────────────────────────────────────────────────────────┐ │
+│  │  层级 2 (依赖层级 1)                                 │ │
+│  │  ┌──────────────┐  ┌──────────────┐                     │ │
+│  │  │ TASK-XXX-04  │  │ TASK-XXX-05  │                     │ │
+│  │  │ 依赖: 01    │  │ 依赖: 02    │                     │ │
+│  │  └──────┬───────┘  └──────┬───────┘                     │ │
+│  │         │                 │                              │ │
+│  │         v                 v                              │ │
+│  │  ┌─────────────────────────────────────────────────────┐│ │
+│  │  │  层级 3 (依赖层级 2)                             ││ │
+│  │  │  ┌──────────────┐                                   ││ │
+│  │  │  │ TASK-XXX-06  │                                   ││ │
+│  │  │  │ 依赖: 04,05 │                                   ││ │
+│  │  │  └──────────────┘                                   ││ │
+│  │  └─────────────────────────────────────────────────────┘│ │
+│  └─────────────────────────────────────────────────────────┘ │
+└─────────────────────────────────────────────────────────────┘
+```
+
+### 2.2 层级汇总
+
+| 层级 | 任务列表 | 可并行 | 前置依赖 |
+|-----|---------|-------|--------|
+| 层级 1 | TASK-XXX-01, TASK-XXX-02 | ✅ 是 | 无 |
+| 层级 2 | TASK-XXX-03 | - | 层级 1 |
+| 层级 3 | TASK-XXX-04 | - | 层级 2 |
+
+---
+
+## 3. 原子任务清单
+
+<!-- 【质量红线】每个任务必须能在5分钟内由AI实现 -->
+
+### 3.0 任务类型说明
+
+| 类型 | 说明 | 适用场景 |
+|------|------|----------|
+| 数据层 | 实体、DTO、Mapper、数据访问 | 数据库操作相关 |
+| 接口层 | Service、Controller、API | 业务逻辑和接口 |
+| UI层 | 组件、页面、样式 | 前端展示相关 |
+| 测试-骨架 | 测试类结构、Mock设置 | 测试驱动模式下的测试前置任务 |
+| 测试-验证 | 测试用例实现、断言 | 实现后的测试验证任务 |
+| 配置 | 配置文件、依赖添加 | 项目配置相关 |
+
+---
+
+### [TASK-XXX-01] 任务名称
+
+- **类型**: 数据层 / 接口层 / UI层 / 测试
+- **依赖**: 无
+- **状态**: [ ] 未完成
+
+#### 任务描述
+<!-- 一句话描述本任务要做什么 -->
+
+#### 输入
+- 
+
+#### 输出
+- 
+
+#### 实现步骤
+1. 
+2. 
+3. 
+
+#### 验收标准
+- [ ] 验收标准 1
+- [ ] 验收标准 2
+
+#### 关联设计
+- spec.md 章节：
+- design.md 章节：
+
+---
+
+### [TASK-XXX-02] 任务名称
+
+- **类型**: 数据层 / 接口层 / UI层 / 测试
+- **依赖**: 无
+- **状态**: [ ] 未完成
+
+#### 任务描述
+
+#### 输入
+
+#### 输出
+
+#### 实现步骤
+1. 
+2. 
+3. 
+
+#### 验收标准
+- [ ] 
+- [ ] 
+
+#### 关联设计
+- spec.md 章节：
+- design.md 章节：
+
+---
+
+### [TASK-XXX-03] 任务名称
+
+- **类型**: 数据层 / 接口层 / UI层 / 测试
+- **依赖**: TASK-XXX-01, TASK-XXX-02
+- **状态**: [ ] 未完成
+
+#### 任务描述
+
+#### 输入
+
+#### 输出
+
+#### 实现步骤
+1. 
+2. 
+3. 
+
+#### 验收标准
+- [ ] 
+- [ ] 
+
+#### 关联设计
+- spec.md 章节：
+- design.md 章节：
+
+---
+
+## 4. 验证方式
+
+### 4.1 单元测试要求
+
+<!-- 【质量红线】每个任务必须有对应的单元测试 -->
+
+| 任务 ID | 测试类型 | 测试场景 | 断言内容 |
+|--------|---------|---------|---------|
+| TASK-XXX-01 | | | |
+| TASK-XXX-02 | | | |
+
+### 4.2 集成测试场景
+
+| 场景 | 前置条件 | 操作步骤 | 预期结果 |
+|-----|---------|---------|---------|
+| | | | |
+
+### 4.3 手动验证清单
+
+- [ ] 验证项 1
+- [ ] 验证项 2
+
+---
+
+## 5. 外部依赖
+
+| 依赖项 | 类型 | 提供方 | 状态 | 备注 |
+|-------|------|-------|------|------|
+| | 其他能力 / 第三方 | | ✅ 就绪 / ⏳ 等待 | |
+
+---
+
+## 6. 代码规范
+
+### 6.1 命名规范
+
+- 类名：
+- 方法名：
+- 变量名：
+
+### 6.2 代码风格
+
+- 缩进：
+- 注释：
+- 异常处理：
+
+### 6.3 日志规范
+
+- 日志级别：
+- 日志格式：
+- 敏感信息处理：
+
+---
+
+## 7. 交付物
+
+### 7.1 代码文件
+
+| 文件路径 | 说明 | 对应任务 |
+|---------|------|---------|
+| | | TASK-XXX-01 |
+
+### 7.2 测试文件
+
+| 文件路径 | 说明 | 对应任务 |
+|---------|------|---------|
+| | | TASK-XXX-01 |
+
+### 7.3 文档更新
+
+- [ ] README 更新
+- [ ] 接口文档更新
+- [ ] 变更日志更新
+
+---
+
+> **质量红线检查清单**
+> - [ ] 每个任务颗粒度符合"5分钟可实现"标准
+> - [ ] 任务清单 100% 覆盖 spec.md 定义
+> - [ ] 任务清单 100% 覆盖 design.md 定义
+> - [ ] 每个任务都有明确的验收标准
+> - [ ] 每个任务都有对应的单元测试要求
+> - [ ] **依赖拓扑已明确**（依赖字段已填写）
+> - [ ] **任务执行拓扑图已绘制**（层级关系清晰）
+> - [ ] 无循环依赖

package/templates/opsx-commands/apply.md

@@ -0,0 +1,420 @@
+---
+name: OPSX: Apply
+description: "执行变更实施 - 针对单一 Capability 按 DAG 依赖顺序实现代码"
+argument-hint: "[change-name] [capability-name] [上下文文件...]"
+---
+
+执行变更实施 - 针对单一 Capability，按 DAG 依赖顺序逐任务实现代码。
+
+> **📊 Telemetry（必做，不得跳过）**
+> 在终端执行（必须成功）：`node skywalk-sdd/log.js start --command=apply --project=<项目根目录绝对路径> --change=<变更名称> --agent=<Agent类型>`，记录返回的 event_id。
+
+> **⚠️ 渐进式上下文加载原则**
+>
+> - 本命令针对**单一 Capability** 执行实施
+> - **上下文路径**：overview.md → proposal.md → 当前 capability 的 spec/design/tasks
+> - ⛔ **隔离红线**：绝对禁止加载同级其他 Capability 的文档
+
+---
+
+**前置要求**: 已完成 `/opsx:task` 或对应 capability 的 tasks.md 已存在；建议先运行 `/opsx:check` 通过质量检查
+
+**执行步骤**
+
+0. **【Telemetry 必做】记录阶段开始**
+
+   在终端执行（若命令失败必须中止本阶段，不得跳过）：
+   ```bash
+   node skywalk-sdd/log.js start --command=apply --project=<项目根目录绝对路径> --change=<变更名称> --agent=<Agent类型>
+   ```
+   保存输出 JSON 中的 `event_id`，供阶段结束使用。
+
+1. **【交互引导】确认变更名称和 Capability**
+
+   **步骤 1a - 确认变更名称**：
+   若未提供 change-name，列出当前所有变更供用户选择：
+   ```bash
+   openspec list --json
+   ```
+
+   **步骤 1b - 确认 Capability**：
+   若未提供 capability-name，读取已存在 tasks.md 的 Capability 列表，使用 **AskUserQuestion** 让用户选择：
+   > "请选择要实施的 Capability：
+   > - A. user-auth（用户认证）- tasks.md ✅ 已就绪
+   > - B. user-profile（用户资料）- tasks.md ✅ 已就绪
+   > - C. data-export（数据导出）- tasks.md ❌ 未拆解"
+
+   **【路径确认】**：
+   > "📍 当前操作目标：
+   > - **变更**：`<change-name>`
+   > - **Capability**：`<capability-name>`
+   > - **任务文件**：`changes/<name>/specs/<capability>/tasks.md`"
+
+2. **【渐进式上下文加载】严格按顺序读取文档**
+
+   > **⛔ 上下文加载红线**：只加载当前 Capability 的四文档链，禁止加载其他 Capability！
+
+   **加载顺序**：
+
+   ```
+   ┌─────────────────────────────────────────────────────────┐
+   │ 第 1 层：全局基线（必读）                                  │
+   │   → openspec/specs/overview.md                          │
+   └─────────────────────────────────────────────────────────┘
+                              ↓
+   ┌─────────────────────────────────────────────────────────┐
+   │ 第 2 层：宏观背景（必读）                                  │
+   │   → changes/<name>/proposal.md                          │
+   └─────────────────────────────────────────────────────────┘
+                              ↓
+   ┌─────────────────────────────────────────────────────────┐
+   │ 第 3 层：当前 Capability 四文档（精准打击）                 │
+   │   → changes/<name>/specs/<capability>/spec.md           │
+   │   → changes/<name>/specs/<capability>/design.md         │
+   │   → changes/<name>/specs/<capability>/tasks.md          │
+   │                                                         │
+   │ ⛔ 隔离红线：禁止加载其他 Capability 的文档！             │
+   └─────────────────────────────────────────────────────────┘
+   ```
+
+   **执行加载**：
+   ```
+   使用 Read 工具依次读取：
+   1. openspec/specs/overview.md（若不存在则跳过）
+   2. changes/<name>/proposal.md
+   3. changes/<name>/specs/<capability>/spec.md
+   4. changes/<name>/specs/<capability>/design.md
+   5. changes/<name>/specs/<capability>/tasks.md（必须存在）
+   ```
+
+   **若 tasks.md 不存在**：
+   > "❌ 当前 Capability 的 tasks.md 不存在，请先运行：
+   > `/opsx:task <change-name> <capability-name>`"
+
+3. **【上下文加载】识别并读取用户提供的文件**
+
+   **自动识别上下文文件**：
+   若用户在命令中指定了文件路径（如 `/opsx:apply atp-calc ./算法.md`），
+   或在对话中附加/引用了文件，**必须自动读取这些文件**。
+
+   **上下文类型与用途**：
+   | 上下文类型 | 检查用途 | 用法 |
+   |------------|---------|------|
+   | 算法文档 (.md) | 算法一致性检查基线 | 对比实现与算法逻辑 |
+   | 参考实现 (.java/.ts) | 代码风格参考 | 保持代码风格一致 |
+   | 测试数据 (.xml/.json) | 测试用例设计 | 理解边界条件 |
+
+   **示例**：
+   ```
+   /opsx:apply atp-calc atp-calculation ./ATP引擎算法逻辑.md
+   /opsx:apply atp-calc atp-calculation ./erp-algorithm-atp/src/main/java/
+   ```
+
+4. **【交互引导】上下文补充提示**
+
+   **若用户未提供任何上下文文件**，AI 分析 design.md 后，**主动提示用户补充**：
+
+   **【关键】具体化建议**：
+   AI 必须**引用 design.md 中的具体内容**给出建议：
+   ```
+   ❌ 错误："建议提供算法参考"
+   ✅ 正确："design.md 包含《正差反差计算》伪代码，建议提供该算法的详细逻辑说明"
+   ```
+
+   **主动提示模板**：
+   > "📌 **建议提供更丰富的上下文信息**：
+   > 
+   > design.md 中包含：
+   > - **《[XX算法]》伪代码** - 建议提供算法参考文档进行一致性检查
+   > - **《[XX现有项目]》** - 建议提供参考实现保持代码风格一致
+   >
+   > 您可以：
+   > - **在命令后追加文件路径**：`/opsx:apply atp-calc ./算法.md ./src/`
+   > - **在对话中上传文件**或粘贴内容
+   >
+   > 或者选择：
+   > - A. 仅依据 design.md 实现（跳过额外上下文检查）
+   > - B. 已提供全部信息"
+
+5. **解析 DAG 任务拓扑**
+
+   从 tasks.md 中解析任务依赖关系：
+   - 提取所有任务的 `[TASK-ID]` 和依赖字段
+   - 构建拓扑图
+   - 计算执行层级
+
+   **拓扑解析示例**：
+   ```
+   TASK-AUTH-01 (依赖: 无)       → 层级 1
+   TASK-AUTH-02 (依赖: 无)       → 层级 1
+   TASK-AUTH-03 (依赖: 01, 02)   → 层级 2
+   TASK-AUTH-04 (依赖: 03)       → 层级 3
+   ```
+
+   **循环依赖检测**：
+   若检测到循环依赖，立即中止并报告：
+   > "❌ 检测到循环依赖：TASK-A → TASK-B → TASK-C → TASK-A
+   > 请修正 tasks.md 中的 Depends-On 字段后重试。"
+
+6. **显示当前进度和拓扑**
+
+   向用户展示：
+   > "## 实施进度
+   > **变更**: `<change-name>`
+   > **Capability**: `<capability-name>`
+   > **进度**: N/M 任务已完成
+   >
+   > ### 拓扑任务状态
+   > ```
+   > 层级 1 (可并行): [TASK-01] ✅, [TASK-02] ⏳
+   > 层级 2 (等待 L1): [TASK-03] ⏳
+   > 层级 3 (等待 L2): [TASK-04] ⏳
+   > ```
+   >
+   > ### 下一个可执行任务
+   > - [ ] [TASK-02] 创建用户表
+   >
+   > 开始实施？"
+
+7. **逐任务实施（按拓扑顺序执行）**
+
+   **⛔ 拓扑依赖拦截机制**：
+   
+   在执行每个任务前，必须检查其依赖字段：
+
+   ```
+   对于每个待处理任务：
+   
+   1. 读取任务的依赖字段
+   2. 检查所有前置任务的状态是否为 [x]（已完成）
+   3. 若前置任务未完成 → 拦截并跳过
+   4. 若前置任务已完成 → 允许执行
+   ```
+
+   **执行循环**：
+
+   a. **【拓扑依赖检查】**
+      
+      > **⛔ 在执行当前任务前，必须检查前置依赖！**
+      
+      解析当前任务的依赖字段，检查所有依赖任务是否已完成：
+      - 若依赖任务未完成，**必须暂停**并明确提示：
+        > "⏸ **依赖拦截**：任务 [TASK-XXX-03] 的前置依赖未满足
+        > - 依赖任务：[TASK-XXX-01] - ❌ 未完成
+        > - 依赖任务：[TASK-XXX-02] - ✅ 已完成
+        >
+        > 必须先完成 [TASK-XXX-01] 才能执行当前任务。
+        > 
+        > 请选择：
+        > - A. 执行 [TASK-XXX-01]
+        > - B. 查看任务详情
+        > - C. 暂停实施"
+      - 若所有依赖已完成，继续执行
+
+   b. **显示当前任务**
+      > "📍 **[N/M]** 正在处理任务: [TASK-ID] <任务描述>
+      > - **类型**: 数据层
+      > - **依赖**: [依赖列表] ✅ 已满足
+      > - **层级**: 2"
+
+   c. **实现代码**
+      - 根据 tasks.md 中的任务描述实现代码
+      - 遵循 design.md 中的设计约定
+      - 遵循 overview.md 中的全局规范
+      - 保持变更最小化、聚焦单一任务
+
+   c2. **❗【新增】算法一致性门禁**
+      
+      > **对于包含算法逻辑的 TASK-XX-IMPL 任务，必须检查实现与 design.md 伪代码的一致性**
+      
+      **触发条件**：
+      - 任务类型为 IMPL（实现任务）
+      - design.md 中包含对应的伪代码章节
+      
+      **检查内容**：
+      | 检查项 | 要求 | 未通过处理 |
+      |---------|------|------------|
+      | 方法签名 | 参数类型、返回值类型一致 | ⚠️ 警告 |
+      | 核心算法逻辑 | 循环、分支、累加顺序一致 | ❌ 拦截 |
+      | 边界条件处理 | 空值、零值、极值处理一致 | ⚠️ 警告 |
+      
+      **检查流程**：
+      1. 读取 design.md 中对应的伪代码章节
+      2. 对比实现代码与伪代码的关键逻辑
+      3. 若提供了 --context 算法文档，进一步对比原始算法
+      
+      **【拦截示例】**：
+      > "⚠️ **算法一致性检查未通过**
+      > 
+      > **问题**：calcZhengchaFucha 方法逻辑不一致
+      > 
+      > **design.md 伪代码**：
+      > ```
+      > if (direction == -1) {
+      >     remaining = remaining.subtract(data.getCalcQuantity());
+      > }
+      > ```
+      > 
+      > **实际实现**：
+      > ```
+      > remaining = remaining.add(data.getCalcQuantity());
+      > ```
+      > 
+      > **原因分析**：
+      > - 伪代码假设 calcQuantity 为正数
+      > - 实际实现中 calcQuantity 对需求已是负数
+      > 
+      > 请选择：
+      > - A. 修复 design.md 伪代码（实现正确）
+      > - B. 修复实现代码（伪代码正确）
+      > - C. 标记为 '设计变更'，继续执行"
+      
+      **【通过后显示】**：
+      > "✅ **算法一致性检查通过**
+      > - 方法签名: ✅ 一致
+      > - 核心逻辑: ✅ 一致
+      > - 边界处理: ✅ 一致"
+
+   d. **⛔【必须】编译检查门禁**
+      
+      > **⛔ 红线：每完成一个任务后，必须确保代码可以编译通过！**
+      
+      **检查流程**：
+      
+      1. **检测项目类型并执行编译**：
+         - **TypeScript/JavaScript**: `npm run build` 或 `tsc --noEmit` 或 `npx tsc --noEmit`
+         - **Java/Maven**: `mvn compile -q`
+         - **Java/Gradle**: `./gradlew compileJava --quiet`
+         - **Python**: `python -m py_compile <file>` 或 `mypy <file>`
+         - **Go**: `go build ./...`
+         - **Rust**: `cargo check`
+         - **其他**: 根据项目配置执行相应编译命令
+      
+      2. **检查编译结果**：
+         - ✅ 编译成功 → 继续下一步
+         - ❌ 编译失败 → **必须立即修复**
+      
+      3. **编译失败处理流程**：
+         ```
+         a. 分析错误信息，定位问题根因
+         b. 修复代码错误
+         c. 重新执行编译检查
+         d. 重复直到编译通过
+         ```
+      
+      4. **显示检查结果**：
+         > "🛠️ **编译检查**
+         > - 执行: `npm run build`
+         > - 结果: ✅ 编译成功 / ❌ 编译失败
+         > - 耗时: 2.3s"
+      
+      > **⚠️ 注意：编译失败的任务禁止标记为已完成！**
+
+   e. **⛔【必须】测试执行门禁**
+      
+      > **根据 proposal.md 的 `test-strategy` 字段决定测试门禁行为**
+      
+      **首先读取 proposal.md 的 YAML frontmatter 中的 `test-strategy` 字段：**
+      
+      | test-strategy | 门禁行为 |
+      |---------------|----------|
+      | `tdd` | **⛔ 强制执行**：运行相关测试，测试失败禁止继续，必须修复 |
+      | `impl-first` | **⚠️ 警告模式**：运行测试，失败时显示警告但允许继续 |
+      | `none` | **跳过**：不执行测试门禁 |
+      
+      **TDD 模式执行流程**：
+      1. 检测当前任务是否有对应的测试文件
+      2. 执行相关测试用例
+      3. 测试通过 → 继续下一步
+      4. **测试失败 → 必须修复，禁止标记为已完成！**
+      
+      **Impl-First 模式执行流程**：
+      1. 执行相关测试用例
+      2. 测试通过 → 继续下一步
+      3. 测试失败 → 显示警告信息，询问用户是否继续
+      
+      > **⚠️ 注意：TDD 模式下测试失败的任务禁止标记为已完成！**
+
+   f. **⛔【必须】立即更新任务状态**
+      
+      每完成一个任务后，必须立即：
+      
+      1. **修改 tasks.md 文件**：
+         - 将 `- **状态**: [ ] 未完成` 改为 `- **状态**: [x] 已完成`
+      2. **验证修改成功**：读取文件确认状态已更新
+      3. **显示进度提示**：
+         > "✅ **[TASK-XXX-01] 已完成** [N/M]
+         > - 编译检查: ✅ 通过
+         > - 已更新 tasks.md 状态: `[ ]` → `[x]`
+         > - 下一层任务已解锁：[TASK-XXX-03]"
+
+   g. **继续下一个可执行任务**
+      - 重新检查 DAG，找出所有依赖已满足的任务
+      - 若同层有多个可执行任务，按顺序执行
+
+   **【暂停条件】**：
+   - **拓扑依赖未满足** → 拦截并提示
+   - **⛔ 编译失败** → 必须修复后才能继续
+   - 任务描述不清晰 → 询问用户澄清
+   - 实施中发现设计问题 → 建议更新 design.md
+   - 遇到错误或阻塞 → 报告问题并等待指导
+
+8. **完成或暂停时显示状态**
+
+   **全部完成时**：
+   > "## ✅ 实施完成
+   > 
+   > **变更**: `<change-name>`
+   > **Capability**: `<capability-name>`
+   > **进度**: 7/7 任务已完成
+   >
+   > ### 拓扑执行摘要
+   > - Layer 1: [TASK-01] ✅, [TASK-02] ✅
+   > - Layer 2: [TASK-03] ✅
+   > - Layer 3: [TASK-04] ✅
+   >
+   > 当前 Capability 所有任务已完成！
+   > 
+   > **下一步**：
+   > - 若还有其他 Capability：运行 `/opsx:apply <name> <next-capability>`
+   > - 若所有 Capability 已完成：运行 `/opsx:archive` 归档变更"
+
+   **暂停时**：
+   > "## ⏸ 实施暂停
+   >
+   > **变更**: `<change-name>`
+   > **Capability**: `<capability-name>`
+   > **进度**: 4/7 任务已完成
+   >
+   > ### 暂停原因
+   > <问题描述>
+   >
+   > ### 拓扑当前状态
+   > - Layer 1: [TASK-01] ✅, [TASK-02] ✅
+   > - Layer 2: [TASK-03] ⏸ 暂停
+   > - Layer 3: [TASK-04] ⏳ 等待
+   >
+   > **选项**：
+   > 1. <选项1>
+   > 2. <选项2>
+   > 3. 其他方案"
+
+---
+
+**护栏规则**
+
+- **⛔ 渐进式加载**：只加载当前 Capability 的四文档链（overview + proposal + spec + design + tasks）
+- **⛔ 隔离红线**：绝对禁止加载同级其他 Capability 的文档
+- **⛔ 拓扑依赖拦截**：执行任务前必须检查依赖，前置未完成必须拦截
+- **⛔ 必须实时更新任务状态**：每完成一个任务，**立即**修改 tasks.md 状态，禁止批量更新
+- **⛔ 算法一致性门禁**：对于 IMPL 任务，检查实现代码与 design.md 伪代码的一致性，核心逻辑不一致时拦截
+- **⛔ 编译检查门禁**：每完成一个任务后，**必须运行编译检查**，编译失败禁止标记已完成
+- **⛔ 测试执行门禁**：根据 `test-strategy` 决定测试门禁行为（tdd=强制, impl-first=警告, none=跳过）
+- **显示进度反馈**：每完成一个任务，显示「✅ [TASK-ID] 已完成 [N/M]」
+- **保持任务聚焦**：每次只处理一个任务，完成后再继续下一个
+- **代码变更最小化**：每个任务只做必要的代码修改，不要超出任务范围
+- **遇到问题时暂停**：如果任务描述模糊、编译失败、测试失败或发现设计问题，暂停并询问
+- 若变更状态已是 `ARCHIVED`，提示用户该变更已归档，无法继续实施
+
+> **📊 Telemetry（必做，不得跳过）**
+> 在终端执行（必须成功）：`node skywalk-sdd/log.js end --event-id=<开头记录的event_id> --result=success/failure --summary="实施结果摘要" --project=<项目根目录绝对路径>`