6a-spec-install 1.0.8-dev.0 → 1.0.8-dev.2

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

@@ -0,0 +1,319 @@
+# new: 新特性需求澄清标准操作流程 (New Feature Requirement SOP)
+
+## 角色
+你现在的角色是【需求分析师 + 业务架构师】，负责将产品提供的原始需求文档（PRD）转化为结构化的、开发可执行的需求澄清文档。你认为"清晰的需求是高质量交付的基础"，因此你严控需求的完整性、一致性和可追溯性。
+
+## 目标
+- 基于用户提供的 PRD 或需求描述，完成需求的结构化梳理
+- 创建特性目录和状态文件
+- 通过反向提问机制，识别需求中的模糊点、遗漏和潜在风险
+- 生成结构化的需求澄清文档 `requirement.md`
+
+## 规则
+1. **结构先行**：先理解业务全貌，再深入细节
+2. **反向提问**：主动识别不确定点，向用户提问确认，而非假设或猜测
+3. **溯源标注**：所有结论必须标注来源（PRD 章节、用户口头确认等）
+4. **范围明确**：必须明确界定做什么和不做什么的边界
+
+## 输入要求
+- **必需输入**：PRD（产品需求文档）或功能需求描述（用户通过 `@` 提供文件或直接粘贴文本）
+- **可选输入**：补充的业务说明、竞品参考、设计稿等
+
+## 执行步骤
+
+### Step 1: 创建特性目录与状态文件
+
+**1.0 前置检查（避免与 clarify 混淆）**
+
+- 若当前工作目录已在 `6aspec/green/<某需求名>/` 下，或用户 @ 的文件位于某需求目录内，则**先提示**：
+  ```
+  当前处于需求目录「<需求名>」内。如需对本需求继续澄清，请使用 /6aspec:green:clarify；
+  如需新建另一个需求，请切换到项目根目录后再次执行 /6aspec:green:new。
+  ```
+  并询问用户是「对当前需求继续澄清（改用 clarify）」还是「确认要新建另一需求（继续 new）」。
+
+**1.1 确定特性名称**
+
+根据用户提供的 PRD 或需求描述，提取核心功能名称，转换为 kebab-case 格式。
+
+如果无法从文档中明确提取，使用 **AskUserQuestion** 让用户确认特性名称：
+
+```
+请确认本次需求的特性名称（将用于目录命名）：
+
+建议名称：<suggested-name>
+
+您也可以输入自定义名称（使用英文短横线分隔，如 user-authentication）。
+```
+
+**1.2 创建目录结构**
+
+```
+6aspec/green/<feature-name>/
+├── .green-status.json     # 状态文件
+├── requirement.md         # 需求澄清文档（本步骤生成）
+├── artifacts/             # 存放 model、design、visual-logic 生成的文档
+└── tasks/                 # 任务目录（后续步骤）
+```
+
+**1.3 初始化状态文件**
+
+创建 `.green-status.json`，内容如下：
+
+```json
+{
+  "name": "<feature-name>",
+  "status": "created",
+  "created": "<ISO8601-now>",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "requirement": {
+      "status": "pending",
+      "path": "6aspec/green/<feature-name>/requirement.md"
+    },
+    "models": {
+      "status": "blocked",
+      "path": "6aspec/green/<feature-name>/artifacts/"
+    },
+    "design": {
+      "status": "blocked",
+      "path": "6aspec/green/<feature-name>/artifacts/"
+    },
+    "tasks": {
+      "status": "blocked",
+      "path": "6aspec/green/<feature-name>/tasks/"
+    }
+  },
+  "tasks": {
+    "total": 0,
+    "completed": 0,
+    "remaining": 0
+  },
+  "nextAction": {
+    "command": "new",
+    "description": "完成需求澄清"
+  }
+}
+```
+
+### Step 2: 需求初步分析
+
+阅读用户提供的 PRD 或需求描述，按以下维度进行初步分析：
+
+1. **业务背景提取**：这个需求要解决什么业务问题？面向什么用户群体？
+2. **核心流程识别**：主业务流程是什么？有哪些关键分支流程？
+3. **角色识别**：涉及哪些用户角色？各角色的操作权限边界是什么？
+4. **数据流向分析**：核心数据从哪里来、到哪里去？
+5. **集成点识别**：需要与哪些现有系统或模块交互？
+
+### Step 3: 反向提问（核心环节）
+
+**这是本 SOP 的核心价值环节。**
+
+基于 Step 2 的初步分析，AI 必须主动列出 **3-5 个关键不确定点或风险点**，向用户提问确认。
+
+#### 反向提问的分类
+
+| 类别 | 说明 | 示例 |
+| :--- | :--- | :--- |
+| **语义模糊** | PRD 中描述不够精确的业务概念 | "PRD 中提到'高级用户'，具体判定标准是什么？" |
+| **边界缺失** | 未明确的功能范围或限制条件 | "批量操作是否有数量上限？异常情况如何处理？" |
+| **流程遗漏** | 主流程之外可能遗漏的分支场景 | "审批被驳回后，是否可以重新提交？重新提交是否需要重新审批？" |
+| **规则冲突** | 不同章节描述存在矛盾或歧义 | "3.1节说状态有5种，但3.4节的流程图只涉及4种状态" |
+| **非功能隐患** | 性能、安全、并发等非功能性风险 | "高峰期预估并发量是多少？是否需要考虑限流策略？" |
+
+#### 提问格式
+
+```markdown
+---
+
+## 🔍 需求澄清确认
+
+基于对 PRD 的分析，以下 N 个问题需要确认后才能继续：
+
+### Q1: [问题标题]
+**类别**：语义模糊 / 边界缺失 / 流程遗漏 / 规则冲突 / 非功能隐患
+**来源**：PRD 第X章 / 第X节
+**问题描述**：<具体问题>
+**AI 建议**：<如果有合理的默认假设，可以给出建议供用户参考>
+
+### Q2: [问题标题]
+...
+
+---
+
+请逐一确认以上问题，您可以：
+- 直接回答每个问题
+- 提供补充文档
+- 告知哪些问题需要与产品/业务方再确认（将记录为"待确认项"）
+```
+
+**重要**：
+- 必须等待用户回复后再继续，不要跳过此步骤
+- 如果用户表示某些问题需要后续确认，记录为"待确认项"写入 requirement.md
+- 用户确认后，如果又发现新的不确定点，可以再次提问（最多追加 2 轮）
+
+### Step 4: 生成需求澄清文档
+
+根据 PRD 内容和用户确认的结果，生成结构化的 `requirement.md` 文档。
+
+#### 文档模板
+
+```markdown
+# <特性中文名称> 需求澄清文档
+
+## 1. 需求概述
+> 一句话描述本特性的核心价值和目标。
+
+**特性名称**：<feature-name>
+**需求来源**：<PRD文档名称/编号>
+**创建日期**：<date>
+
+## 2. 业务背景与目标
+
+### 2.1 业务背景
+<为什么要做这个需求？解决什么业务痛点？>
+
+### 2.2 业务目标
+<可量化的业务目标，如有>
+
+### 2.3 目标用户
+| 角色 | 说明 | 关键操作 |
+| :--- | :--- | :--- |
+| <角色1> | <角色描述> | <主要操作> |
+
+## 3. 功能范围
+
+### 3.1 功能清单（Scope-In）
+| 序号 | 功能项 | 优先级 | 说明 | PRD来源 |
+| :--- | :--- | :--- | :--- | :--- |
+| 1 | <功能1> | P0/P1/P2 | <简要描述> | PRD X.X |
+
+### 3.2 不做范围（Scope-Out）
+| 序号 | 排除项 | 排除原因 |
+| :--- | :--- | :--- |
+| 1 | <排除功能> | <原因> |
+
+## 4. 核心业务流程
+
+### 4.1 主流程
+<描述主业务流程，可使用文字或列表>
+
+### 4.2 分支流程
+<描述关键的分支/异常流程>
+
+## 5. 业务规则与约束
+
+| 序号 | 规则描述 | 适用场景 | PRD来源 |
+| :--- | :--- | :--- | :--- |
+| BR-01 | <业务规则> | <适用场景> | PRD X.X |
+
+## 6. 集成与依赖
+
+### 6.1 系统集成
+| 集成系统/模块 | 交互方式 | 说明 |
+| :--- | :--- | :--- |
+| <系统名> | API调用/事件/数据同步 | <说明> |
+
+### 6.2 数据依赖
+<依赖的基础数据、配置数据等>
+
+## 7. 非功能性需求
+| 类别 | 需求描述 | 说明 |
+| :--- | :--- | :--- |
+| 性能 | <如有> | |
+| 安全 | <如有> | |
+| 兼容性 | <如有> | |
+
+## 8. 待确认项
+> 以下问题尚需与产品/业务方进一步确认，不阻塞领域建模但可能影响详细设计。
+
+| 序号 | 问题 | 状态 | 负责人 | 备注 |
+| :--- | :--- | :--- | :--- | :--- |
+| TBD-01 | <待确认问题> | 待确认/已确认 | <负责人> | <备注> |
+
+## 9. 附录
+
+### 9.1 PRD 原始引用
+- 文档名称：<PRD文档名>
+- 关键章节索引：<章节列表>
+
+### 9.2 需求澄清记录
+| 日期 | 问题 | 确认结果 | 确认人 |
+| :--- | :--- | :--- | :--- |
+| <date> | <问题> | <结果> | <确认人> |
+```
+
+### Step 5: 更新状态文件
+
+完成需求澄清文档后，更新 `.green-status.json`：
+
+```json
+{
+  "status": "requirement_clarified",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "requirement": {
+      "status": "done",
+      "completedAt": "<ISO8601-now>"
+    },
+    "models": {
+      "status": "ready"
+    }
+  },
+  "nextAction": {
+    "command": "model",
+    "description": "开始领域建模"
+  }
+}
+```
+
+**注意**：如果存在较多"待确认项"（TBD 项 ≥ 3 个且涉及核心流程），建议状态保持为 `created`，并提示用户：
+```
+⚠️ 当前有 N 个待确认项涉及核心流程，建议先与产品/业务方确认后，再运行 /6aspec:green:clarify 继续澄清。
+```
+
+此时 `nextAction` 应设置为：
+```json
+{
+  "command": "clarify",
+  "description": "继续需求澄清（有 N 个核心待确认项）"
+}
+```
+
+## 输出要求
+1. 格式：Markdown 源码格式
+2. 文档位置：`6aspec/green/<feature-name>/requirement.md`
+3. 文档命名：`requirement.md`
+4. 必须包含"待确认项"章节（即使为空）
+
+## 注意
+- **严格溯源**：所有功能项、业务规则必须有明确的 PRD 来源标注
+- **不可臆断**：对于 PRD 中未明确说明的内容，不可自行补充假设，必须通过反向提问确认或记录为"待确认项"
+- **范围克制**：只记录 PRD 中明确要求或用户确认的功能，不主动扩大范围
+
+## 流程完成提示 (Workflow Progress)
+
+**重要提示**：本节内容仅用于向用户输出流程进度提示，**不要写入任何文档文件**。
+
+当完成本 SOP 流程后，必须向用户输出以下流程进度提示：
+
+---
+
+✅ **已完成：需求澄清 (new)**
+
+📊 **进度：0/4 (主流程)**
+
+**下一步建议：**
+- 【可选】深化需求澄清：命令 `clarify`
+  如有待确认项或想进一步细化需求，可继续澄清
+- 【主流程】领域建模：命令 `model`
+  基于需求澄清文档进行领域模型和数据库设计
+
+**完整流程图：**
+```
+主流程：需求澄清 ✅ → 领域建模 → 技术方案 → 任务生成 → 执行任务 (0/4)
+可选流程：需求深化澄清 / 表导入建模平台 / 生成可视化逻辑图
+```
+
+---

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

@@ -0,0 +1,275 @@
+# 绿地需求状态查询 SOP
+
+## 目标
+
+查询并显示当前绿地需求的状态、工件完成情况、任务进度和下一步建议。
+
+## 前置条件
+
+- 已经通过 `/6aspec:green:new` 创建了需求目录
+- 存在状态文件 `.green-status.json`
+
+## 执行步骤
+
+### Step 1: 检测当前需求
+
+**1.1 检查是否在需求目录下**
+
+检查当前工作目录是否在 `6aspec/green/<feature-name>/` 下：
+
+```bash
+pwd
+```
+
+如果在需求目录下，自动识别需求名称（从路径中提取）。
+
+**1.2 如果不在需求目录下，列出所有活跃需求**
+
+```bash
+find 6aspec/green -maxdepth 2 -name ".green-status.json" -type f
+```
+
+如果找到多个需求，使用 **AskUserQuestion** 让用户选择要查看的需求。
+
+如果没有找到任何需求，输出：
+```
+未找到任何绿地需求。
+
+请先运行 /6aspec:green:new 创建一个新需求。
+```
+
+### Step 2: 读取状态文件
+
+读取 `6aspec/green/<feature-name>/.green-status.json` 文件：
+
+```javascript
+const statusPath = '6aspec/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: 状态文件不存在
+
+```
+错误：未找到状态文件
+
+路径：6aspec/green/<feature-name>/.green-status.json
+
+这可能是因为：
+1. 需求目录不是通过 /6aspec:green:new 创建的
+2. 状态文件被意外删除
+
+请运行 /6aspec:green:new 重新创建需求。
+```
+
+### 错误 2: 状态文件格式错误
+
+```
+错误：状态文件格式错误
+
+路径：6aspec/green/<feature-name>/.green-status.json
+
+错误信息：<parse-error>
+
+请检查状态文件格式是否正确，或运行 /6aspec:green:new 重新创建需求。
+```
+
+## 注意事项
+
+1. **只读操作**：status 命令只读取状态，不修改任何文件
+2. **时间格式化**：显示时间时使用易读格式（YYYY-MM-DD HH:mm）
+3. **路径简化**：显示文件路径时使用相对路径，省略 `6aspec/green/<feature-name>/` 前缀
+4. **用户友好**：使用图标和颜色（如果终端支持）提升可读性
+5. **状态一致性**：如果发现状态不一致（如工件状态与生命周期状态不匹配），显示警告信息
+
+## 参考文档
+
+- 状态文件结构定义：`.6aspec/rules/green/green_status_schema.md`

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

@@ -9,12 +9,33 @@ alwaysApply: false
 
 当触发 tasks 工作流时，AI 需作为 **Lead Engineer / Project Manager**，基于已生成的 `tech-design.md` 文档，将架构设计转化为以**入口点（API/事件/定时任务）**为核心的原子开发任务。
 
+## 前置条件（依赖门禁，必须首先执行）
+
+在执行任务拆解前，**必须**先完成依赖检查，不通过则**立即停止**并提示，不得继续：
+
+1. **确定当前需求**：根据当前工作目录或用户 @ 的文件，确定 `6aspec/green/<feature-name>/`；若有多个需求则让用户选择。
+2. **读取状态文件**：读取 `6aspec/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 存在**：若 `6aspec/green/<feature-name>/artifacts/tech-design.md` 不存在，停止并提示先完成技术方案设计。
+
+**只有以上检查全部通过后，才允许继续执行本 SOP 的拆解步骤。**
+
 ## 0. 执行协议 (Protocol) - 必须遵守
 
 你是一个**技术项目经理 (TPM)**。在执行任务拆解前，请严格遵守：
 
 1.  **主动检索 (Active Retrieval)**：
-    *   当用户指定 `{功能名称}` 时，优先尝试读取 `6aspec/{kebab-case-功能名称}/tech-design.md`。
+    *   当用户指定 `{功能名称}` 时，优先尝试读取 `6aspec/green/<feature-name>/artifacts/tech-design.md`。
     *   如果找不到 TDD 文档，**立即停止**并报错，提示用户先完成 TDD 设计。
 
 2.  **思维链门禁 (Chain of Thought Gatekeeping)**：
@@ -55,7 +76,7 @@ alwaysApply: false
 
 ### 1. 目录结构
 所有任务文件必须存储在以下路径：
-- `6aspec/{kebab-case-功能名称}/tasks/`（功能名称使用 kebab-case 命名，如：user-authentication）
+- `6aspec/green/<feature-name>/tasks/`（feature-name 使用 kebab-case 命名，如：user-authentication）
 
 ### 2. 文件命名规范
 - 格式：`task-{序号}-{任务类型}-{功能简名}.md`
@@ -120,21 +141,21 @@ alwaysApply: false
 2. **合并依赖项**：将该入口点涉及的所有业务逻辑（Service）、数据访问（Repository）、模型定义（DTO/VO/Enum）全部归入该入口点的原子任务中。
 3. **排序与编排**：基于`<thinking>`中的依赖分析，对任务进行逻辑排序（先基础后上层，先前置后依赖）。
 4. **生成文件**：为每个识别出的入口点生成独立的任务 Markdown 文件。
-5. **生成总览**：任务拆解完成后，必须在 `6aspec/{kebab-case-功能名称}/tasks/README.md` 输出任务总览。
+5. **生成总览**：任务拆解完成后，必须在 `6aspec/green/<feature-name>/tasks/README.md` 输出任务总览。
 6. **状态维护（必须执行）**：后续每当完成一个任务，必须同步更新：
    - 对应任务文件中的"任务状态"。
-   - `6aspec/{kebab-case-功能名称}/tasks/README.md` 中该任务的状态展示。
+   - `6aspec/green/<feature-name>/tasks/README.md` 中该任务的状态展示。
 
 ## 输出要求
 1. **格式**：Markdown 源码格式。
 2. **一致性**：任务中的类名、方法名和字段名必须与 TDD 保持完全一致。
 3. **禁用范围**：不拆解前端任务、不拆解单纯的单元测试任务、不拆解 Entity/SQL 任务。
-4. **总览 README（必须输出）**：在 `6aspec/{kebab-case-功能名称}/tasks/README.md` 生成任务总览文件，必须包含：
+4. **总览 README（必须输出）**：在 `6aspec/green/<feature-name>/tasks/README.md` 生成任务总览文件，必须包含：
    - **项目进度看板**：任务总工时、已完成工时、进度条。
    - **任务清单**：按推荐执行顺序排列，包含状态图标 (✅/🔄/⏳)。
    - **开发阶段划分**：建议将任务划分为 Phase 1 (Core), Phase 2 (Extensions) 等阶段。
    - **验收标准汇总**：从各任务 DoD 汇总，形成整体 DoD。
-   - **注意事项与相关文档链接**: 至少包含：tech-design.md、api-definition.md、如存在则包含 visual-logic.md 文档链接
+   - **注意事项与相关文档链接**: 至少包含指向 `../artifacts/tech-design.md`、`../artifacts/api-definition.md` 的链接；如存在则包含 `../artifacts/visual-logic.md`
 
 ## 流程完成提示 (Workflow Progress)
 

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

@@ -21,14 +21,14 @@ alwaysApply: false
 
 ## 输入要求
 ### 必需输入
-- **TDD 文档路径**：`6aspec/{kebab-case-功能名称}/tech-design.md`（功能名称使用 kebab-case 命名，如：user-authentication）
+- **TDD 文档路径**：`6aspec/green/<feature-name>/artifacts/tech-design.md`（feature-name 使用 kebab-case 命名，如：user-authentication）
 - **人类选择的生成范围（必须明确，否则中断提问）**：
   - 需要生成的图表类型：Flowchart / Sequence / State（可多选）
   - 覆盖范围：具体到“哪些入口/哪些业务流程/哪些对象”（例如：仅 `3.1` 中某个写 API；或某个事件订阅；或某个后台任务）
   - 抽象层级：是否细到 service/repository/facade 级别（建议默认到 service/repository/facade）
 
 ### 可选输入（用于补齐 TDD 未显式写清的信息）
-- 数据模型文档：`6aspec/{kebab-case-功能名称}/domain-model.md`
+- 数据模型文档：`6aspec/green/<feature-name>/artifacts/domain-model.md`
 - PRD：`.prd/{功能名称}-prd.md`
 - 事件清单：`./.6aspec/biz/event-list.md`（当涉及事件订阅/发布时）
 - 能力地图：`./.6aspec/biz/functional-capability-Map.md`（当涉及跨模块 Facade 依赖时）
@@ -42,7 +42,7 @@ alwaysApply: false
 
 ## 输出要求
 1. **输出格式**：Markdown 源码 + Mermaid 代码块（严禁截图）
-2. **输出位置**：`6aspec/{kebab-case-功能名称}/visual-logic.md`
+2. **输出位置**：`6aspec/green/<feature-name>/artifacts/visual-logic.md`
 3. **引用关系**：在输出文档开头必须写明：
    - 输入 TDD 文档路径
    - 本次选择生成的图表类型与覆盖范围
@@ -88,7 +88,7 @@ alwaysApply: false
 - 迁移必须标注触发入口（API/事件/定时任务/后台任务）
 
 ### 第四步：输出文档并自检
-1. 写入 `6aspec/{kebab-case-功能名称}/visual-logic.md`
+1. 写入 `6aspec/green/<feature-name>/artifacts/visual-logic.md`
 2. 自检：
    - Mermaid 语法是否完整
    - 是否严格遵循"按需生成"与"范围约束"