kld-sdd 2.4.14 → 2.4.16

package/templates/opsx-commands/design.md

@@ -1,570 +0,0 @@
----
-name: OPSX: Design
-description: "创建局部技术实现方案 - 针对单一 Capability 的设计文档"
-argument-hint: "[change-name] [capability-name] [上下文文件...]"
----
-
-创建 **design.md** - 针对单一 Capability 的局部技术实现方案（渐进式上下文加载）。
-
-> **🖥️ 跨平台执行规则**
-> - 先确认当前终端工作目录是项目根目录；若不是，先 `cd` 到项目根目录。
-> - Telemetry 命令默认使用 `--project=.`，兼容 Windows、macOS、Linux。
-> - 在 Windows Bash / Git Bash / Claude Bash 中，禁止裸写 Windows 反斜杠绝对路径（如 `D:\project\demo`）；如必须使用绝对路径，请写成正斜杠路径或加引号。
-> - 不要省略 `--source=opsx-command` 与 `--session-id=<会话ID>`。
-> **📊 Telemetry（必做，不得跳过）**
-> 在终端执行（必须成功）：`node skywalk-sdd/log.cjs start --command=design --project=. --change=<变更名称> --capability=<capability-name> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID>`，记录返回的 event_id。
-
-> **⚠️ 阶段边界提示**
->
-> 当前处于 **Design（设计）阶段**，此阶段：
-> - ✅ **允许**：创建/编辑 design.md 文档、读取代码/文档作为上下文分析
-> - ❌ **禁止**：创建/修改任何代码文件、执行代码生成、运行测试
-> - ⛔ **单阶段原则**：完成 design.md 后**必须立即停止**，等待用户主动触发下一阶段
->
-> 代码实现将在 `/opsx:apply` 阶段进行。
-> **完成本阶段后，绝对禁止自动继续执行 task 等后续阶段。**
-
-> **⚠️ 渐进式上下文加载原则**
->
-> - 本命令针对**单一 Capability** 执行设计
-> - **输入路径**：`changes/<name>/specs/<capability>/spec.md`
-> - **输出路径**：`changes/<name>/specs/<capability>/design.md`
-> - ⛔ **隔离红线**：绝对禁止跨目录读取同级其他 Capability 的 spec 或 design
-
----
-
-**前置要求**: 已运行 `/opsx:spec` 或对应 capability 的 spec.md 已存在
-
-**执行步骤**
-
-0. **【Telemetry 必做】记录阶段开始**
-
-   在终端执行（若命令失败必须中止本阶段，不得跳过）：
-   ```bash
-   node skywalk-sdd/log.cjs start --command=design --project=. --change=<变更名称> --capability=<capability-name> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID>
-   ```
-   保存输出 JSON 中的 `event_id`，供阶段结束使用。
-
-1. **【交互引导】确认变更名称和 Capability**
-
-   **步骤 1a - 确认变更名称**：
-   若未提供 change-name，列出当前所有变更供用户选择：
-   ```bash
-   openspec list
-   ```
-
-   **步骤 1b - 确认 Capability**：
-   若未提供 capability-name，读取 `proposal.md` 中定义的 Capabilities 列表：
-   ```bash
-   # 读取 changes/<name>/proposal.md，解析其中的 Capabilities 章节
-   ```
-   
-   使用 **AskUserQuestion** 让用户选择要设计的 Capability：
-   > "请选择要设计的 Capability：
-   > - A. user-auth（用户认证）
-   > - B. user-profile（用户资料）
-   > - C. data-export（数据导出）
-   > - D. 全部（将依次执行每个 Capability 的设计）"
-
-   **【路径确认】**：
-   > "📍 当前操作目标：
-   > - **变更**：`<change-name>`
-   > - **Capability**：`<capability-name>`
-   > - **输入**：`changes/<name>/specs/<capability>/spec.md`
-   > - **输出**：`changes/<name>/specs/<capability>/design.md`"
-
-2. **【渐进式上下文加载】严格按顺序读取文档**
-
-   > **⛔ 上下文加载红线**：必须严格按以下顺序加载，禁止一次性加载所有 Capability！
-
-   **加载顺序**（由全局到局部）：
-
-   ```
-   ┌─────────────────────────────────────────────────────────┐
-   │ 第 1 层：全局基线（必读）                                  │
-   │   → openspec/specs/overview.md                          │
-   │   （全局数据字典、接口规范、共享实体）                       │
-   └─────────────────────────────────────────────────────────┘
-                              ↓
-   ┌─────────────────────────────────────────────────────────┐
-   │ 第 2 层：宏观背景（必读）                                  │
-   │   → changes/<name>/proposal.md                          │
-   │   （业务意图、影响范围、依赖关系）                          │
-   └─────────────────────────────────────────────────────────┘
-                              ↓
-   ┌─────────────────────────────────────────────────────────┐
-   │ 第 3 层：精准打击（仅读当前 Capability）                    │
-   │   → changes/<name>/specs/<capability>/spec.md           │
-   │   （当前能力的技术契约）                                   │
-   │                                                         │
-   │ ⛔ 隔离红线：禁止读取其他 Capability 的 spec.md！          │
-   └─────────────────────────────────────────────────────────┘
-   ```
-
-   **执行加载**：
-   ```
-   使用 Read 工具依次读取：
-   1. openspec/specs/overview.md（若不存在则跳过，记录警告）
-   2. changes/<name>/proposal.md
-   3. changes/<name>/specs/<capability>/spec.md（必须存在）
-   ```
-
-   **若 spec.md 不存在**：
-   > "❌ 当前 Capability 的 spec.md 不存在，请先运行：
-   > `/opsx:spec <change-name> <capability-name>`"
-
-3. **【上下文加载】识别并读取用户提供的文件**
-
-   **自动识别上下文文件**：
-   若用户在命令中指定了文件路径（如 `/opsx:design atp-calc ./算法.md ./src/`），
-   或在对话中附加/引用了文件，**必须自动读取这些文件**。
-
-   **文件识别规则**：
-   - 以 `.md`、`.java`、`.ts`、`.py` 等扩展名结尾 → 识别为文件路径
-   - 以 `/` 或 `./` 开头 → 识别为路径
-   - 目录路径 → 递归读取目录下的文件
-
-   **上下文类型与用途**：
-   | 文件类型 | 用途 | 用法 |
-   |---------|------|------|
-   | 算法文档 (.md) | 提取算法逻辑、伪代码 | 生成 Internal Logic |
-   | 代码文件 (.java/.ts) | 理解现有实现 | 提取方法签名/逻辑 |
-   | 测试数据 (.xml/.json) | 理解边界条件 | 补充边界处理逻辑 |
-
-   **示例**：
-   ```
-   /opsx:design atp-calc atp-calculation ./ATP引擎算法逻辑.md
-   /opsx:design atp-calc atp-calculation ./erp-algorithm-atp/src/main/java/
-   ```
-
-4. **【交互引导】上下文补充提示**
-
-   **若用户未提供任何上下文文件**，AI 分析 spec.md 后，**主动提示用户补充**：
-
-   **【关键】具体化建议**：
-   AI 必须**引用 spec.md 中的具体内容**给出建议：
-   ```
-   ❌ 错误："建议提供算法说明"
-   ✅ 正确："spec.md 包含《正差反差计算》场景，建议提供该算法的详细逻辑说明"
-   ✅ 正确："spec.md 提到要迁移 erp-algorithm-atp，建议提供该项目的源代码"
-   ```
-
-   **主动提示模板**：
-   > "📌 **建议提供更丰富的上下文信息**：
-   > 
-   > spec.md 中包含：
-   > - **《[XX算法/场景]》** - 建议提供详细算法逻辑说明
-   > - **《[XX现有项目]》** - 建议提供参考实现代码
-   >
-   > 您可以：
-   > - **在命令后追加文件路径**：`/opsx:design atp-calc ./算法.md ./src/`
-   > - **在对话中上传文件**或粘贴内容
-   > - **告诉我文件位置**，我会自动读取
-   >
-   > 或者选择：
-   > - A. 基于现有信息继续（伪代码可能不完整）
-   > - B. 已提供全部信息"
-
-5. **【关键】开发规范与技术架构上下文检测**
-
-   > **⚠️ 技术栈无关化原则**
-   >
-   > Design 阶段生成的技术方案需要明确的开发规范和技术架构指导，否则可能产出与项目实际不符的设计。
-
-   **AI 必须检测上下文中是否包含以下信息**：
-
-   | 检测维度 | 典型内容 | 检测信号 |
-   |---------|----------|----------|
-   | **技术架构** | 分层架构、微服务边界、模块划分 | 是否提及 Controller/Service/Repository、API Gateway 等 |
-   | **开发规范** | 代码规范、命名约定、设计模式 | 是否有编码规范文档、架构规范 |
-   | **技术选型** | 框架、数据库、中间件 | 是否明确 Spring Boot / React / MySQL 等技术栈 |
-   | **项目约束** | 性能要求、安全规范、兼容性 | 是否有非功能性需求说明 |
-
-   **检测来源**：
-   - `overview.md` 中的技术架构章节
-   - `proposal.md` 中的技术约束
-   - 用户提供的上下文文件
-   - 对话中附加的内容
-
-   **【交互引导】若检测到开发规范/技术架构缺失**：
-
-   > "⚠️ **开发规范与技术架构上下文检测**
-   >
-   > 当前上下文中**未检测到**以下关键信息：
-   > - [ ] **技术架构**：未发现分层架构、模块边界等描述
-   > - [ ] **开发规范**：未发现代码规范、设计模式约定
-   > - [ ] **技术选型**：未明确使用的框架、数据库等技术栈
-   >
-   > 缺少这些信息可能导致设计方案与项目实际架构不符。
-   >
-   > 请选择：
-   > - A. **补充规范文档** - 提供架构设计文档、开发规范等
-   > - B. **口头说明** - 简要描述项目技术栈和架构风格
-   > - C. **确认缺失无影响** - 当前设计不涉及技术选型细节，可继续
-   > - D. **记录到 `overview.md`** - 我来协助补充全局技术架构"
-
-6. **【关键步骤】读取本地模板文件**
-
-   **必须先读取** `openspec-templates/design.md` 作为文档结构模板：
-   ```
-   使用 Read 工具读取：openspec-templates/design.md
-   ```
-
-   此模板定义了局部设计文档的完整结构：
-   - **字段完整性追溯表**（防止字段丢失）
-   - 局部前端设计
-   - 局部后端接口设计
-   - 局部数据模型
-   - 质量红线检查清单
-
-7. **获取项目上下文（可选）**
-   ```bash
-   openspec instructions design --change "<name>" --json
-   ```
-   解析返回的 JSON，仅获取：
-   - `context`：项目背景约束（**仅供参考，不要写入文档**）
-   - `rules`：文档编写规则（**仅供参考，不要写入文档**）
-
-   **注意**：忽略返回的 `template` 和 `outputPath`，使用本命令指定的路径。
-
-8. **【交互引导】确认设计范围和类型**
-
-   **首先确认设计类型**（使用 AskUserQuestion）：
-   > "请选择本次设计的范围：
-   > - A. **仅前端**：UI 组件、状态管理、路由、交互
-   > - B. **仅后端**：模块设计、接口、数据模型
-   > - C. **前后端全栈**：完整的前后端设计
-   > - D. **根据 spec.md 自动判断**"
-
-   **然后确认设计边界**：
-   > "基于 spec.md 和您的选择，本次 design.md 将设计：
-   > - **Capability**：`<capability-name>`
-   > - **设计类型**：[前端/后端/全栈]
-   > - **前端**：[X] 个页面/组件、[X] 个状态（如适用）
-   > - **后端**：[X] 个模块、[X] 个接口（如适用）
-   > - **数据模型**：[X] 个实体
-   >
-   > 请确认：
-   > - A. 确认范围，开始设计
-   > - B. 调整设计类型或模块划分
-   > - C. 补充业务约束"
-
-9. **【AI 分析澄清】识别设计风险点和上下文缺失**
-
-   分析 spec.md 内容，识别需要重点设计或澄清的点：
-
-   **常见风险点**：
-   - 高性能要求下的数据一致性保障
-   - 复杂业务规则的状态机设计
-   - 第三方依赖的降级策略
-
-   **上下文缺失检测**：
-   - 依赖模块的接口定义是否完整？
-   - 复用模块的约束条件是否明确？
-   - overview.md 中的全局规范是否已遵守？
-
-   **【主动询问机制】**：
-   发现潜在风险或上下文缺失时：
-   > "spec.md 要求 '[约束]'，但以下信息不完整：
-   > - [缺失1]：需要补充 [具体内容]
-   > - [缺失2]：需要确认 [具体问题]
-   > 
-   > 请选择：
-   > - A. 现在补充信息
-   > - B. 记录到 `clarifications.md` 待后续处理
-   > - C. 基于假设继续设计（将在文档中标注假设）"
-
-10. **创建局部 design.md**
-
-   **输出路径**：`changes/<name>/specs/<capability>/design.md`
-
-   **以 `openspec-templates/design.md` 的结构为骨架**，填充内容：
-
-   **【质量红线】生成的 design.md 必须：**
-   - 标题包含 Capability 名称
-   - 包含**字段完整性追溯表**（用户输入字段 vs 设计输出字段）
-   - 遵循 overview.md 的全局规范
-   - 仅设计当前 Capability，不越权设计其他模块
-
-   ```markdown
-   # 局部技术实现方案 - [Capability 名称]
-   
-   > **⚠️ 边界声明**：本设计仅服务于当前 Capability，严禁越权设计。
-   
-   ## 1. 字段完整性追溯表
-   > **⛔ 核心红线**：用户在 Spec 中输入的所有字段必须在此表中体现，严禁无故丢弃！
-   
-   ### 1.1 字段映射表
-   
-   | 序号 | 用户输入字段 | 设计输出字段 | 字段类型 | 状态 | 理由说明 |
-   |-----|-------------|-------------|---------|------|--------|
-   | | | | | ✅ 保留 | |
-   
-   **状态说明**：
-   - ✅ 保留：字段名和类型与用户输入一致
-   - ⚠️ 重命名：字段重命名（必须说明理由）
-   - 🔀 合并：多字段合并为一个（必须说明理由）
-   - ❌ 移除：字段被移除（必须有充分理由且经用户确认）
-   
-   ### 1.2 完整性自检
-   - **用户输入字段总数**：[X] 个
-   - **设计输出字段总数**：[X] 个
-   - **差异说明**：[如有差异必须详细说明]
-   
-   ---
-   
-   ## 2. 现有代码锚点
-   > AI 无法知道“要改哪里”，如果涉及对现有代码的修改，**请用户补充完整**。
-   
-   ### 2.1 需修改的现有文件
-   | 文件路径 | 类/模块名 | 需修改的方法/函数 | 修改类型 | 说明 |
-   |---------|----------|----------------|---------|------|
-   | | | | 扩展逻辑/新增参数/重构抽取/替换实现 | |
-   
-   ### 2.2 需新建的文件
-   | 文件路径（建议） | 类/模块名 | 职责 | 继承/实现 | 说明 |
-   |------------|----------|------|---------|------|
-   | | | | | |
-   
-   ### 2.3 现有逻辑约束
-   | 约束项 | 当前现状 | 对本设计的影响 | 应对策略 |
-   |-------|---------|-------------|--------|
-   | | | | 遵循/适配/协商修改 |
-   
-   ---
-   
-   ## 3. 局部前端设计
-   ### 3.1 页面/组件结构
-   | 组件名 | 类型 | 职责 | 依赖组件 |
-   |-------|------|------|--------|
-   | | 页面/容器/展示 | | |
-   
-   ### 3.2 状态管理
-   | 状态名 | 数据类型 | 初始值 | 更新时机 |
-   |-------|---------|-------|--------|
-   
-   ### 3.3 路由设计
-   | 路由路径 | 页面组件 | 权限要求 | 说明 |
-   |---------|---------|---------|------|
-   
-   ### 3.4 前后端交互
-   | 前端操作 | 调用接口 | 请求参数 | 响应处理 |
-   |---------|---------|---------|--------|
-   
-   ---
-   
-   ## 4. 局部后端接口设计
-   ### 4.1 接口清单
-   | 接口名称 | 路径 | 方法 | 说明 |
-   |---------|------|------|------|
-   
-   ### 4.2 接口详细设计
-   #### 接口 1：[接口名称]
-   - 路径：`/api/v1/xxx`
-   - 方法：GET/POST
-   **请求参数**：
-   | 参数名 | 类型 | 必填 | 说明 | 约束 |
-   |-------|------|------|------|------|
-   **业务逻辑**：1. ... 2. ... 3. ...
-   
-   ---
-   
-   ## 5. 局部数据模型
-   ### 5.1 数据表设计
-   #### 表名：[table_name]
-   | 字段名 | 数据类型 | 必填 | 默认值 | 说明 | 索引 |
-   |-------|---------|------|--------|------|------|
-   
-   ### 5.2 缓存设计
-   | 缓存 Key 模式 | 数据类型 | 过期时间 | 更新策略 |
-   |--------------|---------|---------|--------|
-   
-   ### 5.3 数据流转图
-   ```
-   [输入] --> [处理] --> [存储] --> [输出]
-   ```
-   
-   ---
-   
-   ## 6. 模块内部逻辑
-   ### 6.1 核心流程
-   ```
-   [步骤1] --> [步骤2] --> [步骤3]
-   ```
-   ### 6.2 状态机（如有）
-   ### 6.3 关键算法（如有）
-   
-   ---
-   
-   ## 7. 外部依赖与集成
-   > AI 无法自动推断项目的外部依赖，**请用户补充完整**。
-   
-   ### 7.1 外部服务依赖
-   | 依赖服务 | 用途 | 调用方式 | 超时设置 | 失败影响 | 降级方案 |
-   |---------|------|---------|---------|---------|--------|
-   
-   ### 7.2 第三方 API / SDK
-   | 名称 | 版本/文档链接 | 用途 | 鉴权方式 | 费用/限流 | 备注 |
-   |------|-------------|------|---------|----------|------|
-   
-   ### 7.3 中间件 & 基础设施
-   | 组件 | 用途 | 使用方式 | 关键配置 | 备注 |
-   |------|------|---------|--------|------|
-   
-   ### 7.4 内部跨模块依赖
-   | 依赖模块 | 调用接口/方法 | 输入 | 预期输出 | 当前状态 |
-   |---------|-------------|------|---------|--------|
-   
-   ### 7.5 环境 & 权限要求
-   | 依赖项 | 说明 | 获取方式 |
-   |-------|------|--------|
-   
-   ---
-   
-   ## 8. 异常处理
-   ### 8.1 异常分类
-   | 异常类型 | 触发条件 | 处理策略 | 用户感知 |
-   |---------|---------|---------|--------|
-   
-   ### 8.2 重试与降级
-   - 重试次数：
-   - 降级策略：
-   
-   ---
-   
-   ## 9. 局部配置
-   ### 9.1 业务配置
-   | 配置项 | 配置 Key | 默认值 | 说明 |
-   |-------|---------|-------|------|
-   
-   ### 9.2 开关配置
-   | 开关 | 用途 | 默认状态 |
-   |-----|------|--------|
-   
-   ---
-   
-   > **质量红线检查清单**
-   > - [ ] **现有代码锚点已标注**：需修改的文件、类、方法已明确（或确认为纯新建）
-   > - [ ] **现有约束已识别**：影响设计的现有系统约束已列出并有应对策略
-   > - [ ] **字段完整性**：字段追溯表已完成，无无故丢弃字段
-   > - [ ] **边界遵守**：无越权设计其他 Capability 的逻辑
-   > - [ ] **全局遵守**：遵循 overview.md 的数据字典和接口规范
-   > - [ ] 前端设计已完成（组件、状态、路由、交互）
-   > - [ ] 后端接口已完成（路径、参数、响应、逻辑）
-   > - [ ] 数据模型已完成（表结构、索引、缓存）
-   > - [ ] **外部依赖已明确**：所有外部服务、第三方 API、中间件、跨模块依赖已列出
-   > - [ ] **环境权限已确认**：所需环境变量、密钥、网络策略已说明
-   > - [ ] 异常处理策略已定义（含外部依赖失败的降级方案）
-   > - [ ] 包含足够的局部细节支持任务拆解
-   ```
-
-11. **质量红线自检**
-
-   写入文档前，逐项确认：
-   - [ ] 文档结构完全符合 `openspec-templates/design.md` 模板
-   - [ ] **字段完整性**：追溯表已完成，无无故丢弃字段
-   - [ ] **边界遵守**：无越权设计其他 Capability 的逻辑
-   - [ ] **全局遵守**：遵循 overview.md 的数据字典和接口规范
-   - [ ] 前端设计已完成（组件、状态、路由、交互）
-   - [ ] 后端接口已完成（路径、参数、响应、逻辑）
-   - [ ] 数据模型已完成（表结构、索引、缓存）
-
-12. **【新增】算法正确性预检查**
-
-   **❗ 此步骤是防止伪代码错误的关键门禁**
-
-   #### 9.1 伪代码自洽性检查
-   
-   | 检查项 | 要求 | 未通过处理 |
-   |---------|------|------------|
-   | 变量声明 | 伪代码中的变量在使用前已赋值 | ❌ 拒绝通过 |
-   | 循环边界 | for 循环的起始/结束条件明确 | ❌ 拒绝通过 |
-   | 分支覆盖 | switch 有 default，if 有 else | ❗ 警告 |
-   | 数据来源 | 关键变量有来源说明 | ❗ 警告 |
-
-   #### 9.2 与 spec.md 的一致性检查
-   
-   - [ ] 伪代码中的参数类型与 spec.md 一致
-   - [ ] 伪代码中的返回值与 spec.md 响应结构一致
-   - [ ] 伪代码中的业务逻辑覆盖所有 Scenario
-
-   #### 9.3 算法完整性检查（针对计算类方法）
-   
-   - [ ] 伪代码是否说明了数据的**来源**（入参、成员变量、外部调用）
-   - [ ] 伪代码是否说明了数据的**去脉**（返回值、写回、副作用）
-   - [ ] 伪代码是否说明了**边界情况**的处理（空列表、零值、极值）
-
-   **【模糊伪代码示例】**：
-   ```markdown
-   ❌ 模糊: "累加计算数量（需求取负数）"
-   
-   ✅ 清晰: "remaining = remaining + data.getCalcQuantity()
-            // 注意：calcQuantity 对需求数据已是负数（由 setCalcQuantity 设置）无需再取反"
-   ```
-
-   **【检查报告格式】**：
-   ```markdown
-   ### 算法正确性预检查结果
-   
-   | 检查项 | 状态 | 说明 |
-   |---------|------|------|
-   | 变量声明 | ✅ 通过 | - |
-   | 循环边界 | ✅ 通过 | - |
-   | 分支覆盖 | ⚠️ 警告 | setCalcQuantity 缺少 default 分支 |
-   | 数据来源 | ❌ 未通过 | calcZhengchaFucha 未说明 calcQuantity 已为负数 |
-   ```
-
-   **【未通过处理】**：
-   > "⚠️ **算法正确性预检查发现以下问题**：
-   > - calcZhengchaFucha 伪代码未说明 calcQuantity 已为负数，可能导致实现时重复取负
-   >
-   > 请选择：
-   > - A. 补充伪代码注释后继续
-   > - B. 提供更详细的上下文文档
-   > - C. 标记为 '已知风险' 继续"
-
-   **如有任意一项未满足，重新生成对应章节，直至全部通过。**
-
-13. **【交互引导】确认设计并输出结果**
-
-    生成文档后，向用户展示概要：
-    > "已生成 `<capability>` 的 design.md，概要如下：
-    > - **Capability**：`<capability-name>`
-    > - **输出路径**：`changes/<name>/specs/<capability>/design.md`
-    > - **字段完整性**：[X] 个输入字段 → [X] 个输出字段（✅ 完整 / ⚠️ 有差异）
-    > - **设计类型**：[前端/后端/全栈]
-    > - **前端**：[X] 个页面/组件（如适用）
-    > - **后端**：[X] 个接口（如适用）
-    >
-    > 请确认：
-    > - A. 确认无误，继续创建 tasks.md
-    > - B. 需要调整设计
-    > - C. 继续设计下一个 Capability"
-
-    **下一步提示**：
-    - 若还有其他 Capability 未设计：
-      > "运行 `/opsx:design <name> <next-capability>` 继续设计下一个 Capability"
-    - 若所有 Capability 已设计完成：
-      > "运行 `/opsx:task <name> <capability>` 拆解实现任务"
-
----
-
-**护栏规则**
-
-- **必须以 `openspec-templates/design.md` 为模板基准**
-- **⛔ 渐进式加载**：严格按 overview.md → proposal.md → 当前 spec.md 顺序加载
-- **⛔ 隔离红线**：绝对禁止读取同级其他 Capability 的 spec.md 或 design.md
-- **⛔ 字段完整性**：必须完成字段追溯表，禁止无故丢弃用户输入字段
-- **⛔ 边界遵守**：本设计仅服务于当前 Capability，不越权设计其他模块
-- `context` 和 `rules` 是你的约束条件，**不得出现在生成的文档中**
-- 文档写入后验证文件确实存在于输出路径
-- **⛔ 阶段边界**：本阶段禁止执行任何代码创建/修改操作
-- **⛔ 单阶段原则：完成 design.md 后必须立即停止**。仅提示用户下一步可运行 `/opsx:task`，**绝对禁止自动执行 task/apply 等后续阶段**。每个阶段必须由用户主动触发。
-
-> **🖥️ 跨平台执行规则**
-> - 先确认当前终端工作目录是项目根目录；若不是，先 `cd` 到项目根目录。
-> - Telemetry 命令默认使用 `--project=.`，兼容 Windows、macOS、Linux。
-> - 在 Windows Bash / Git Bash / Claude Bash 中，禁止裸写 Windows 反斜杠绝对路径（如 `D:\project\demo`）；如必须使用绝对路径，请写成正斜杠路径或加引号。
-> - 不要省略 `--source=opsx-command` 与 `--session-id=<会话ID>`。
-> **📊 Telemetry（必做，不得跳过）**
-> 在终端执行（必须成功）：`node skywalk-sdd/log.cjs end --event-id=<开头记录的event_id> --command=design --project=. --change=<变更名称> --capability=<capability-name> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID> --result=success/failure --summary="一句话摘要"`

package/templates/opsx-commands/explore.md

@@ -1,99 +0,0 @@
----
-name: OPSX: Explore
-description: "浏览变更 - 查看所有变更状态和 SDD 文档完整性概览"
-argument-hint: "[change-name]"
----
-
-浏览变更状态和文档链进度 - 快速掌握项目中所有变更的 SDD 文档完整性，并引导下一步操作。
-
-> **🖥️ 跨平台执行规则**
-> - 先确认当前终端工作目录是项目根目录；若不是，先 `cd` 到项目根目录。
-> - Telemetry 命令默认使用 `--project=.`，兼容 Windows、macOS、Linux。
-> - 在 Windows Bash / Git Bash / Claude Bash 中，禁止裸写 Windows 反斜杠绝对路径（如 `D:\project\demo`）；如必须使用绝对路径，请写成正斜杠路径或加引号。
-> - 不要省略 `--source=opsx-command` 与 `--session-id=<会话ID>`。
-> **📊 Telemetry（必做，不得跳过）**
-> 在终端执行（必须成功）：`node skywalk-sdd/log.cjs start --command=explore --project=. --change=<变更名称> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID>`，记录返回的 event_id。
-
----
-
-**输入**: `/opsx:explore`（可选：后跟变更名称查看详情）
-
-**执行步骤**
-
-0. **【Telemetry 必做】记录阶段开始**
-
-   在终端执行（若命令失败必须中止本阶段，不得跳过）：
-   ```bash
-   node skywalk-sdd/log.cjs start --command=explore --project=. --change=<变更名称> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID>
-   ```
-   保存输出 JSON 中的 `event_id`，供阶段结束使用。
-
-1. **获取所有变更列表**
-
-   ```bash
-   openspec list
-   ```
-
-   若没有任何变更，提示：
-   > "当前项目还没有任何变更。运行 `/opsx:propose <变更描述>` 开始第一个变更。"
-
-2. **检查每个变更的 SDD 文档完整性**
-
-   对每个变更，检查以下文件是否存在：
-   - `openspec/changes/<name>/propose.md` 或 `proposal.md`（P）
-   - `openspec/changes/<name>/spec.md` 或 `specs.md`（S）
-   - `openspec/changes/<name>/design.md`（D）
-   - `openspec/changes/<name>/task.md` 或 `tasks.md`（T）
-
-   同时获取每个变更状态：
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-
-3. **展示变更概览表**
-
-   > "📋 项目变更概览（P=提案 S=规格 D=设计 T=任务）：
-   >
-   > | 变更名称 | P | S | D | T | openspec状态 | 建议下一步 |
-   > |---------|---|---|---|---|------------|---------|
-   > | add-user-auth | ✅ | ✅ | ✅ | ❌ | PENDING | `/opsx:task add-user-auth` |
-   > | payment-refund | ✅ | ❌ | ❌ | ❌ | PENDING | `/opsx:spec payment-refund` |
-   > | points-exchange | ✅ | ✅ | ✅ | ✅ | IMPLEMENTING | `/opsx:check points-exchange` |"
-
-4. **【交互引导】选择操作**
-
-   > "请选择操作：
-   > - A. 查看变更详情：输入变更名称
-   > - B. 创建新变更：运行 `/opsx:propose`
-   > - C. 执行质量检查：运行 `/opsx:check <name>`
-   > - D. 申请实施：运行 `/opsx:apply <name>`
-   > - E. 退出浏览"
-
-5. **若用户选择查看详情（选 A）**
-
-   展示选定变更的详细信息：
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-
-   展示：
-   - 变更描述和创建时间
-   - 各文档状态（存在/缺失/文件大小）
-   - openspec 内部状态（`applyRequires` 列表）
-   - 建议下一步操作和对应命令
-
----
-
-**护栏规则**
-
-- explore 是只读操作，不修改任何文件
-- 发现文档缺失时，推荐对应命令但不自动执行
-- 若某变更 applyRequires 中有未完成项，在概览表中以 ⚠️ 标注
-
-> **🖥️ 跨平台执行规则**
-> - 先确认当前终端工作目录是项目根目录；若不是，先 `cd` 到项目根目录。
-> - Telemetry 命令默认使用 `--project=.`，兼容 Windows、macOS、Linux。
-> - 在 Windows Bash / Git Bash / Claude Bash 中，禁止裸写 Windows 反斜杠绝对路径（如 `D:\project\demo`）；如必须使用绝对路径，请写成正斜杠路径或加引号。
-> - 不要省略 `--source=opsx-command` 与 `--session-id=<会话ID>`。
-> **📊 Telemetry（必做，不得跳过）**
-> 在终端执行（必须成功）：`node skywalk-sdd/log.cjs end --event-id=<开头记录的event_id> --command=explore --project=. --change=<变更名称> --agent=<Agent类型> --source=opsx-command --session-id=<会话ID> --result=success --summary="浏览结果摘要"`