6aspec 2.0.0-dev.10

package/.6aspec/rules/green/6A_rollback_sop.md

@@ -0,0 +1,198 @@
+# rollback: 流程回退标准操作流程 (Rollback SOP)
+
+## 目标
+将当前需求回退**一个阶段**，并删除该阶段生成的工件，以便重新执行上一阶段或修正后重做本阶段。仅允许单步回退，且**必须获得用户明确确认后**才执行删除与状态更新。
+
+## 规则
+1. **单步回退**：每次只能回退一个阶段，不允许跨多阶段回退
+2. **先提示后执行**：必须先列出将删除的文件并提示用户，**只有在用户给出明确确认指令后**才允许执行删除和状态更新
+3. **禁止从实现阶段回退**：状态为 `implementing`、`completed`、`archived` 时不允许回退；`created` 无上一阶段，也不允许
+
+## 允许回退的状态与目标
+
+| 当前状态 | 回退后状态 | 将删除的工件 |
+|----------|------------|--------------|
+| `requirement_clarified` | `created` | `6aspecdoc/green/<feature-name>/requirement.md` |
+| `modeled` | `requirement_clarified` | `6aspecdoc/green/<feature-name>/artifacts/domain-model.md` |
+| `designed` | `modeled` | `6aspecdoc/green/<feature-name>/artifacts/tech-design.md`、`api-definition.md`；若存在则一并删除 `artifacts/visual-logic.md` |
+| `tasks_created` | `designed` | `6aspecdoc/green/<feature-name>/tasks/` 目录下全部文件（含 `README.md` 及所有 `task-*.md`） |
+
+## 执行步骤
+
+### Step 1: 确定需求并读取状态
+
+1. **确定当前需求**：根据当前工作目录或用户 @ 的文件，确定 `6aspecdoc/green/<feature-name>/`；若有多个需求则让用户选择。
+2. **读取状态文件**：读取 `6aspecdoc/green/<feature-name>/.green-status.json`。若文件不存在，停止并提示先运行 `/6aspec:green:new`。
+3. **阶段门禁**：检查 `status`：
+   - **允许回退**：仅当 `status` 为 `requirement_clarified`、`modeled`、`designed`、`tasks_created` 之一时继续。
+   - **拒绝回退**：若为 `created`、`implementing`、`completed`、`archived`，则停止并输出：
+
+```
+❌ 不允许执行回退 (rollback)
+
+当前状态：<status>
+
+允许回退的阶段：仅限 requirement_clarified、modeled、designed、tasks_created。
+created（无上一阶段）、implementing（已进入代码实现）、completed、archived 不允许回退。
+
+若已进入实现阶段且需求有变更，建议通过修改需求/设计文档并补充任务处理，或新建需求。
+```
+
+### Step 2: 列出回退影响并请求用户明确确认
+
+根据当前状态，输出**回退影响说明**，并**禁止在未得到用户明确确认前执行任何删除或写状态文件操作**。
+
+输出格式（必须包含以下内容）：
+
+```markdown
+## 回退影响说明
+
+- **当前状态**：<current-status>
+- **回退后状态**：<target-status>
+- **回退后下一步**：需重新执行 <command>（<描述>）
+
+### 即将删除的文件（执行回退后将不可恢复）
+
+<按下面表格根据当前状态填写>
+
+| 路径 | 说明 |
+|------|------|
+| <path1> | <说明> |
+| <path2> | <说明> |
+
+### 状态文件更新
+
+- `.green-status.json` 中 `status` 将更新为 `<target-status>`
+- 当前阶段对应工件的 `status` 将置为 pending/blocked
+
+---
+
+⚠️ **请确认后再执行回退**
+
+回退将**永久删除**上述文件，且不可通过本命令恢复。
+
+请明确回复以下之一后，我才会执行删除与状态更新：
+- **「确认回退」**
+- **「执行回退」**
+
+若不需要回退，请直接说明取消。
+```
+
+**根据当前状态填写的删除清单：**
+
+- **requirement_clarified → created**  
+  | 路径 | 说明 |
+  |------|------|
+  | `6aspecdoc/green/<feature-name>/requirement.md` | 需求澄清文档 |
+
+- **modeled → requirement_clarified**  
+  | 路径 | 说明 |
+  |------|------|
+  | `6aspecdoc/green/<feature-name>/artifacts/domain-model.md` | 领域模型文档 |
+
+- **designed → modeled**  
+  | 路径 | 说明 |
+  |------|------|
+  | `6aspecdoc/green/<feature-name>/artifacts/tech-design.md` | 技术设计文档 |
+  | `6aspecdoc/green/<feature-name>/artifacts/api-definition.md` | API 定义文档 |
+  | `6aspecdoc/green/<feature-name>/artifacts/visual-logic.md` | 可视化逻辑图（若存在） |
+
+- **tasks_created → designed**  
+  | 路径 | 说明 |
+  |------|------|
+  | `6aspecdoc/green/<feature-name>/tasks/` 下全部文件 | 任务列表及 README 等 |
+
+### Step 3: 等待用户明确确认
+
+- **仅当**用户回复中包含「确认回退」或「执行回退」的**明确意图**时，才继续执行 Step 4。
+- 若用户回复取消、或仅表达犹豫（如「再想想」），则**不执行**回退，并回复已取消。
+- 若用户未明确确认，则**不得**执行任何文件删除或状态文件写入。
+
+### Step 4: 执行回退（仅在用户已明确确认后）
+
+4.1 **删除工件文件**  
+按 Step 2 中列出的路径执行删除（若某路径不存在则跳过，不报错）。
+
+4.2 **更新 `.green-status.json`**  
+按当前回退类型更新状态与工件状态（见下表），并更新 `lastModified`、`nextAction`。
+
+**requirement_clarified → created**
+
+```json
+{
+  "status": "created",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "requirement": { "status": "pending", "path": "..." },
+    "models": { "status": "blocked", "path": "..." },
+    "design": { "status": "blocked", "path": "..." },
+    "tasks": { "status": "blocked", "path": "..." }
+  },
+  "nextAction": { "command": "new", "description": "完成需求澄清" }
+}
+```
+
+**modeled → requirement_clarified**
+
+```json
+{
+  "status": "requirement_clarified",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "models": { "status": "ready", "path": "..." },
+    "design": { "status": "blocked", "path": "..." },
+    "tasks": { "status": "blocked", "path": "..." }
+  },
+  "nextAction": { "command": "model", "description": "开始领域建模" }
+}
+```
+
+**designed → modeled**
+
+```json
+{
+  "status": "modeled",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "design": { "status": "blocked", "path": "..." },
+    "tasks": { "status": "blocked", "path": "..." }
+  },
+  "tasks": { "total": 0, "completed": 0, "remaining": 0 },
+  "nextAction": { "command": "design", "description": "开始技术方案设计" }
+}
+```
+
+**tasks_created → designed**
+
+```json
+{
+  "status": "designed",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "tasks": { "status": "blocked", "path": "..." }
+  },
+  "tasks": { "total": 0, "completed": 0, "remaining": 0 },
+  "nextAction": { "command": "tasks", "description": "开始任务拆解" }
+}
+```
+
+### Step 5: 输出回退结果
+
+```
+✅ 回退已执行
+
+需求：<feature-name>
+回退前状态：<previous-status>
+当前状态：<new-status>
+已删除：<列出已删除的路径>
+
+下一步：请运行 /6aspec:green:<command> 重新执行该阶段（或先修改需求/设计后再执行）。
+```
+
+## 注意
+- **严禁在未获得用户明确确认前**执行 Step 4 的删除或状态更新。
+- 删除为永久操作，不提供撤销；用户确认前务必确保其理解将删除的内容。
+- 仅支持单步回退；需回退多步时，请多次执行 rollback。
+
+## 参考
+- 状态定义：`.6aspec/rules/green/green_status_schema.md`

package/.6aspec/rules/green/6A_status_sop.md

@@ -0,0 +1,275 @@
+# 绿地需求状态查询 SOP
+
+## 目标
+
+查询并显示当前绿地需求的状态、工件完成情况、任务进度和下一步建议。
+
+## 前置条件
+
+- 已经通过 `/6aspec:green:new` 创建了需求目录
+- 存在状态文件 `.green-status.json`
+
+## 执行步骤
+
+### Step 1: 检测当前需求
+
+**1.1 检查是否在需求目录下**
+
+检查当前工作目录是否在 `6aspecdoc/green/<feature-name>/` 下：
+
+```bash
+pwd
+```
+
+如果在需求目录下，自动识别需求名称（从路径中提取）。
+
+**1.2 如果不在需求目录下，列出所有活跃需求**
+
+```bash
+find 6aspecdoc/green -maxdepth 2 -name ".green-status.json" -type f
+```
+
+如果找到多个需求，使用 **AskUserQuestion** 让用户选择要查看的需求。
+
+如果没有找到任何需求，输出：
+```
+未找到任何绿地需求。
+
+请先运行 /6aspec:green:new 创建一个新需求。
+```
+
+### Step 2: 读取状态文件
+
+读取 `6aspecdoc/green/<feature-name>/.green-status.json` 文件：
+
+```javascript
+const statusPath = '6aspecdoc/green/<feature-name>/.green-status.json';
+const status = JSON.parse(fs.readFileSync(statusPath, 'utf8'));
+```
+
+如果文件不存在或格式错误，输出错误信息并退出。
+
+### Step 3: 解析状态信息
+
+从状态文件中提取以下信息：
+
+- `name`: 需求名称
+- `status`: 当前生命周期状态
+- `created`: 创建时间
+- `lastModified`: 最后修改时间
+- `artifacts`: 工件完成情况
+- `tasks`: 任务进度
+- `nextAction`: 下一步建议
+
+### Step 4: 显示状态信息
+
+按照以下格式输出状态信息：
+
+```markdown
+## 需求状态：<feature-name>
+
+**当前阶段**：<status-display-name>
+**创建时间**：<formatted-created-time>
+**最后更新**：<formatted-modified-time>
+
+### 工件完成情况
+<artifact-status-list>
+
+### 任务进度
+<task-progress>
+
+### 下一步建议
+<next-action-suggestion>
+```
+
+#### 4.1 状态显示名称映射
+
+| 状态值 | 显示名称 |
+|--------|---------|
+| `created` | 已创建（等待需求澄清） |
+| `requirement_clarified` | 需求已澄清 |
+| `modeled` | 领域建模完成 |
+| `designed` | 技术方案完成 |
+| `tasks_created` | 任务已拆解 |
+| `implementing` | 实施中 |
+| `completed` | 已完成 |
+| `archived` | 已归档 |
+
+#### 4.2 工件状态显示
+
+对于每个工件，根据其状态显示不同的图标和说明：
+
+- `done`: ✓ <工件名称> (<文件路径>)
+- `ready`: ⧗ <工件名称> (<文件路径>) - 准备就绪
+- `pending`: ○ <工件名称> (<文件路径>) - 等待创建
+- `blocked`: ⊗ <工件名称> (<文件路径>) - 等待依赖工件
+
+工件名称映射：
+- `requirement`: 需求澄清文档
+- `models`: 领域模型
+- `design`: 技术方案
+- `tasks`: 任务列表
+
+如果工件有 `files` 字段，显示文件数量：
+```
+✓ 领域模型 (artifacts/) - 3 个文件
+```
+
+#### 4.3 任务进度显示
+
+根据任务状态显示：
+
+- 如果 `tasks.total == 0`: "尚未拆解任务"
+- 如果 `tasks.completed == tasks.total`: "✓ 所有任务已完成 (N/N)"
+- 否则: "进行中：N/M 已完成，剩余 K 个任务"
+
+如果有 `lastExecuted` 字段，显示：
+```
+最后执行：<task-file-name>
+```
+
+#### 4.4 下一步建议
+
+根据当前状态和 `nextAction` 字段显示建议：
+
+如果有 `nextAction` 字段：
+```
+运行 /6aspec:green:<command> - <description>
+或运行 /6aspec:green:continue 自动执行下一步
+```
+
+如果没有 `nextAction` 字段，根据状态推断：
+
+| 状态 | 建议 |
+|------|------|
+| `created` | 运行 /6aspec:green:clarify 继续需求澄清，或运行 /6aspec:green:model 开始领域建模 |
+| `requirement_clarified` | 运行 /6aspec:green:model 开始领域建模（可选：运行 /6aspec:green:clarify 继续深化需求） |
+| `modeled` | 运行 /6aspec:green:design 开始技术方案设计 |
+| `designed` | 运行 /6aspec:green:tasks 开始任务拆解 |
+| `tasks_created` | 运行 /6aspec:green:execute-task 开始执行任务 |
+| `implementing` | 运行 /6aspec:green:execute-task 继续执行任务 |
+| `completed` | 运行 /6aspec:green:archive 归档需求 |
+| `archived` | 需求已归档 |
+
+### Step 5: 支持 JSON 输出（可选）
+
+如果用户请求 JSON 格式输出（通过参数 `--json`），直接输出状态文件的内容：
+
+```json
+{
+  "name": "...",
+  "status": "...",
+  ...
+}
+```
+
+## 输出示例
+
+### 示例 1: 需求澄清完成后
+
+```markdown
+## 需求状态：user-authentication
+
+**当前阶段**：需求已澄清
+**创建时间**：2026-02-16 11:00
+**最后更新**：2026-02-16 11:15
+
+### 工件完成情况
+✓ 需求澄清文档 (requirement.md)
+⧗ 领域模型 (artifacts/) - 准备就绪
+⊗ 技术方案 (artifacts/) - 等待领域模型
+⊗ 任务列表 (tasks/) - 等待技术方案
+
+### 任务进度
+尚未拆解任务
+
+### 下一步建议
+运行 /6aspec:green:model 开始领域建模
+或运行 /6aspec:green:continue 自动执行下一步
+```
+
+### 示例 2: 实施中
+
+```markdown
+## 需求状态：user-authentication
+
+**当前阶段**：实施中
+**创建时间**：2026-02-16 11:00
+**最后更新**：2026-02-16 15:30
+
+### 工件完成情况
+✓ 需求澄清文档 (requirement.md)
+✓ 领域模型 (artifacts/) - 3 个文件
+✓ 技术方案 (artifacts/)
+✓ 任务列表 (tasks/) - 8 个任务
+
+### 任务进度
+进行中：5/8 已完成，剩余 3 个任务
+最后执行：task_05_session_management.md
+
+### 下一步建议
+运行 /6aspec:green:execute-task 继续执行任务
+或运行 /6aspec:green:continue 自动执行下一步
+```
+
+### 示例 3: 已完成
+
+```markdown
+## 需求状态：user-authentication
+
+**当前阶段**：已完成
+**创建时间**：2026-02-16 11:00
+**最后更新**：2026-02-16 18:45
+
+### 工件完成情况
+✓ 需求澄清文档 (requirement.md)
+✓ 领域模型 (artifacts/) - 3 个文件
+✓ 技术方案 (artifacts/)
+✓ 任务列表 (tasks/) - 8 个任务
+
+### 任务进度
+✓ 所有任务已完成 (8/8)
+
+### 下一步建议
+运行 /6aspec:green:archive 归档需求
+```
+
+## 错误处理
+
+### 错误 1: 状态文件不存在
+
+```
+错误：未找到状态文件
+
+路径：6aspecdoc/green/<feature-name>/.green-status.json
+
+这可能是因为：
+1. 需求目录不是通过 /6aspec:green:new 创建的
+2. 状态文件被意外删除
+
+请运行 /6aspec:green:new 重新创建需求。
+```
+
+### 错误 2: 状态文件格式错误
+
+```
+错误：状态文件格式错误
+
+路径：6aspecdoc/green/<feature-name>/.green-status.json
+
+错误信息：<parse-error>
+
+请检查状态文件格式是否正确，或运行 /6aspec:green:new 重新创建需求。
+```
+
+## 注意事项
+
+1. **只读操作**：status 命令只读取状态，不修改任何文件
+2. **时间格式化**：显示时间时使用易读格式（YYYY-MM-DD HH:mm）
+3. **路径简化**：显示文件路径时使用相对路径，省略 `6aspecdoc/green/<feature-name>/` 前缀
+4. **用户友好**：使用图标和颜色（如果终端支持）提升可读性
+5. **状态一致性**：如果发现状态不一致（如工件状态与生命周期状态不匹配），显示警告信息
+
+## 参考文档
+
+- 状态文件结构定义：`.6aspec/rules/green/green_status_schema.md`

package/.6aspec/rules/green/6A_tasks_sop.md

@@ -0,0 +1,181 @@
+---
+description: 任务拆解标准操作流程 (Functional Entrypoint SOP)
+alwaysApply: false
+---
+
+# tasks: 任务拆解标准操作流程 (Functional Entrypoint SOP)
+
+## 工作流概述
+
+当触发 tasks 工作流时，AI 需作为 **Lead Engineer / Project Manager**，基于已生成的 `tech-design.md` 文档，将架构设计转化为以**入口点（API/事件/定时任务）**为核心的原子开发任务。
+
+## 前置条件（依赖门禁，必须首先执行）
+
+在执行任务拆解前，**必须**先完成依赖检查，不通过则**立即停止**并提示，不得继续：
+
+1. **确定当前需求**：根据当前工作目录或用户 @ 的文件，确定 `6aspecdoc/green/<feature-name>/`；若有多个需求则让用户选择。
+2. **读取状态文件**：读取 `6aspecdoc/green/<feature-name>/.green-status.json`。若文件不存在，停止并提示先运行 `/6aspec:green:new` 创建需求。
+3. **检查上一流程已完成**：
+   - 若 `status` 不是 `designed`，停止并提示：
+     ```
+     ❌ 未通过依赖检查，无法执行任务拆解
+
+     当前状态：<status>
+     要求状态：designed（技术方案已完成）
+
+     请先完成技术方案设计：运行 /6aspec:green:design，并确保生成 artifacts/tech-design.md、api-definition.md 且状态已更新为 designed。
+     ```
+   - 若 `artifacts.design.status` 不是 `done`，停止并提示先运行 `/6aspec:green:design` 完成技术方案。
+4. **检查 tech-design.md 存在**：若 `6aspecdoc/green/<feature-name>/artifacts/tech-design.md` 不存在，停止并提示先完成技术方案设计。
+
+**只有以上检查全部通过后，才允许继续执行本 SOP 的拆解步骤。**
+
+## 0. 执行协议 (Protocol) - 必须遵守
+
+你是一个**技术项目经理 (TPM)**。在执行任务拆解前，请严格遵守：
+
+1.  **主动检索 (Active Retrieval)**：
+    *   当用户指定 `{功能名称}` 时，优先尝试读取 `6aspecdoc/green/<feature-name>/artifacts/tech-design.md`。
+    *   如果找不到 TDD 文档，**立即停止**并报错，提示用户先完成 TDD 设计。
+
+2.  **思维链门禁 (Chain of Thought Gatekeeping)**：
+    *   在输出任务列表前，**必须**先输出 `<thinking>` 块。
+    *   **Check**: TDD 是否包含清晰的“接口列表”、“定时任务列表”、“事件订阅列表”？
+    *   **Check**: 所有的入口点是否都有对应的“执行逻辑”描述？
+    *   **Decision**: 若 TDD 内容严重缺失（如只有标题无逻辑），拒绝拆解，要求用户先完善 TDD。
+
+3.  **依赖分析 (Dependency Analysis)**：
+    *   在 `<thinking>` 块中，分析任务间的依赖关系（例如：退款任务依赖于支付查询接口）。
+    *   基于依赖关系生成合理的**开发顺序**，而不是简单的线性排列。
+
+## 核心原则
+1. **纵向拆解**：一个任务即一个完整的功能入口，包含其关联的枚举、 DTO、Service、Repository，gateway 等所有逻辑实现
+2. **职责完备**：在执行某个任务时，AI 应根据需要自动创建或修改涉及的模型与逻辑，而不是拆分成多个任务
+3. **规约驱动**：不同类型的任务必须显式指定对应的编码规约文件
+
+## 输入要求
+- **必需输入**：已完成的 `tech-design.md` 文档
+- **关联规约**：
+    - API 任务：`./.6aspec/rules/biz/api_rule.md`
+    - 事件订阅任务：`./.6aspec/rules/biz/event_subscriber_rule.md`
+    - 定时任务任务：`./.6aspec/rules/biz/scheduled_job_rule.md`
+    - 后台任务任务：`./.6aspec/rules/biz/background_job_rule.md`
+
+## 第一阶段：任务分类与规则映射
+
+在拆解时，AI 必须识别 TDD 中的功能点属于哪种类型，并分配对应的规约文件：
+
+| 任务类型 | 识别特征 | 关联规约文件 |
+| :--- | :--- | :--- |
+| **API 任务** | TDD 中的 RESTful API 设计、Controller 接口 | `./.6aspec/rules/biz/api_rule.md` |
+| **事件订阅任务** | TDD 中的事件订阅 (Subscriber)、异步消息处理 | `./.6aspec/rules/biz/event_subscriber_rule.md` |
+| **定时任务任务** | TDD 中的定时任务 (Scheduled Task)、Cron 任务 | `./.6aspec/rules/biz/scheduled_job_rule.md` |
+| **后台任务任务** | TDD 中的后台任务（Async Background Job）、需要异步执行的任务 | `./.6aspec/rules/biz/background_job_rule.md` |
+
+## 第二阶段：输出规范
+
+### 1. 目录结构
+所有任务文件必须存储在以下路径：
+- `6aspecdoc/green/<feature-name>/tasks/`（feature-name 使用 kebab-case 命名，如：user-authentication）
+
+### 2. 文件命名规范
+- 格式：`task-{序号}-{任务类型}-{功能简名}.md`
+- 示例：`task-001-api-create-contract.md`, `task-002-event-contract-signed.md`
+
+### 3. 任务文档模板 (Task Template)
+每个生成的任务文件必须**严格包含**以下章节：
+
+```markdown
+# 任务 [序号]: [任务标题 (如: 开发 XXX 接口)]
+
+### 0. 任务状态
+- 状态：[待开始 / 进行中 / 已完成 / 阻塞 / 取消]
+- 最后更新：[YYYY-MM-DD]
+
+### 1. 任务目标
+- 描述任务的入口点（如：开发 API `POST /v1/contract/save`）
+- 明确该任务需要实现的功能边界
+
+### 2. 预计工时（小时）
+- 预计：X 小时
+- **评估基准 (Baseline)**：
+    - 简单 CRUD 接口：0.5 - 1h
+    - 带简单业务逻辑（校验/状态变更）：1 - 2h
+    - 复杂逻辑（外部调用/并发锁/事务）：3 - 5h
+    - 极高复杂度（核心金融链路）：5h+
+
+### 2.5 任务依赖与前置条件 (Dependencies)
+- **前置任务**：[Task-001 / 无] (必须先完成的任务)
+- **依赖模块**：[UserFacade / PaymentService] (需调用的外部依赖)
+
+### 3. 业务规则与实现细节
+- **核心逻辑**：基于 TDD 中的"执行逻辑"描述，详细说明 Service 层及领域层需处理的规则（如存在对应的可视化文档 `visual-logic.md`，可作为辅助参考，但不得脱离 TDD 自行补充规则）。
+- **核心技术决策**：回顾 TDD 中的关键决策（如幂等方案），再次确认落实。
+- **数据结构与契约 (Binding)**：
+    - **API 契约**：必须严格遵循 `api-definition.md` 中的 Request/Response 结构。
+    - **Entity 引用**：实体类与 Mapper 均已预生成，请在代码实现阶段搜索并复用（如 `MyEntity.java`, `MyEntityMapper.java`或者`MyEntityDao.java`），**严禁重复创建**。
+- **状态流转**：若涉及状态变更，明确状态机逻辑。
+- **数据结构**：涉及的 DTO、Command、Query 的定义要求
+- **异常处理**：需捕获并抛出的业务异常类型。
+
+### 4. 跨模块依赖调用
+- 明确需要调用哪些已有模块的 Facade 或 RMI 接口
+- 描述依赖的数据来源或前置条件
+
+### 5. 必须参考的编码规则
+- **本任务类型**：[API / 事件订阅 / 定时任务 / 后台任务]
+- **规则文件**：[此处填入对应的 .md 规则路径]
+- **编码公共规则文件**：`.6aspec/rules/biz/code.md`和`.6aspec/rules/biz/project-structure.md`
+- **执行说明**：在执行本任务代码生成时，必须严格遵守该规则文件中的代码分层、命名及注释规范
+- **C/B 端标识**：API 接口必须识别是 C 端(小程序端)还是 B 端(PC 端和 APP 端)
+
+### 6. 验收标准 (DoD)
+- [ ] 对应的接口/订阅者/定时器已成功创建。
+- [ ] 内部逻辑（Service/Repository）完整实现且符合业务预期。
+- [ ] 幂等性与并发控制已按 TDD 要求实现。
+- [ ] 满足规约文件中的所有强制性要求。
+```
+
+## 第三阶段：拆解执行步骤
+1. **扫描入口点**：从 TDD 文档中提取所有“接口设计”、“事件设计”、“定时任务”和“后台任务”中的条目。
+2. **合并依赖项**：将该入口点涉及的所有业务逻辑（Service）、数据访问（Repository）、模型定义（DTO/VO/Enum）全部归入该入口点的原子任务中。
+3. **排序与编排**：基于`<thinking>`中的依赖分析，对任务进行逻辑排序（先基础后上层，先前置后依赖）。
+4. **生成文件**：为每个识别出的入口点生成独立的任务 Markdown 文件。
+5. **生成总览**：任务拆解完成后，必须在 `6aspecdoc/green/<feature-name>/tasks/README.md` 输出任务总览。
+6. **状态维护（必须执行）**：后续每当完成一个任务，必须同步更新：
+   - 对应任务文件中的"任务状态"。
+   - `6aspecdoc/green/<feature-name>/tasks/README.md` 中该任务的状态展示。
+
+## 输出要求
+1. **格式**：Markdown 源码格式。
+2. **一致性**：任务中的类名、方法名和字段名必须与 TDD 保持完全一致。
+3. **禁用范围**：不拆解前端任务、不拆解单纯的单元测试任务、不拆解 Entity/SQL 任务。
+4. **总览 README（必须输出）**：在 `6aspecdoc/green/<feature-name>/tasks/README.md` 生成任务总览文件，必须包含：
+   - **项目进度看板**：任务总工时、已完成工时、进度条。
+   - **任务清单**：按推荐执行顺序排列，包含状态图标 (✅/🔄/⏳)。
+   - **开发阶段划分**：建议将任务划分为 Phase 1 (Core), Phase 2 (Extensions) 等阶段。
+   - **验收标准汇总**：从各任务 DoD 汇总，形成整体 DoD。
+   - **注意事项与相关文档链接**: 至少包含指向 `../artifacts/tech-design.md`、`../artifacts/api-definition.md` 的链接；如存在则包含 `../artifacts/visual-logic.md`
+
+## 流程完成提示 (Workflow Progress)
+
+**重要提示**：本节内容仅用于向用户输出流程进度提示，**不要写入任何文档文件**。
+
+当完成本 SOP 流程后，必须向用户输出以下流程进度提示：
+
+---
+
+✅ **已完成：任务拆解 (tasks)**
+
+📊 **进度：3/4 (主流程)**
+
+**下一步建议：**
+- 【主流程】执行开发任务：命令 `execute-task`
+  开始执行具体的开发任务，将设计转化为代码实现
+
+**完整流程图：**
+```
+主流程：领域建模 ✅ → 技术方案 ✅ → 任务生成 ✅ → 执行任务 (3/4)
+```
+
+---