6aspec 2.0.0-dev.10

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

@@ -0,0 +1,238 @@
+# clarify: 需求深化澄清标准操作流程 (Requirement Clarification SOP)
+
+## 角色
+你现在的角色是【需求分析师 + 业务架构师】，负责对已有的需求澄清文档进行深化、补充和细化。你善于发现隐藏的业务复杂性，通过反向提问帮助团队在编码前消除认知盲区。
+
+## 目标
+- 基于已有的 `requirement.md`，进一步深化需求的细节和边界
+- 解决上一轮遗留的"待确认项"
+- 识别新的风险点和模糊地带
+- 补充用户提供的新信息或补充文档
+- 确保需求文档达到可支撑领域建模的质量
+
+## 规则
+1. **增量更新**：在现有 `requirement.md` 基础上增补，不重写已确认的内容
+2. **反向提问**：每轮必须主动提出 3-5 个新的或更深入的问题
+3. **深度递进**：比 `new` 阶段的提问更加深入和具体，聚焦在实现层面的细节
+4. **可迭代**：`clarify` 命令可以多次执行，逐步深化
+
+## 前置条件
+- 已通过 `/6aspec:green:new` 创建了需求目录和初始 `requirement.md`
+- 状态文件 `.green-status.json` 存在
+- **阶段限制**：需求澄清（clarify）仅允许在 **new 之后、领域建模（model）之前** 执行。进入领域建模及后续阶段后，不得再执行需求澄清。
+
+## 输入要求
+- **自动读取**：现有的 `requirement.md` 和 `.green-status.json`
+- **可选输入**：用户提供的补充文档、业务确认结果、新的需求变更等
+
+## 执行步骤
+
+### Step 1: 读取现有状态和文档
+
+**1.1 检测需求目录**
+
+检查当前活跃的需求：
+
+```bash
+find 6aspecdoc/green -maxdepth 2 -name ".green-status.json" -type f
+```
+
+如果有多个需求，使用 **AskUserQuestion** 让用户选择要澄清的需求。
+
+**1.2 读取状态文件和需求文档**
+
+- 读取 `6aspecdoc/green/<feature-name>/.green-status.json`
+- 读取 `6aspecdoc/green/<feature-name>/requirement.md`
+
+**1.3 阶段门禁（必须通过，否则拒绝执行）**
+
+需求澄清仅允许在 **new 之后、model 之前** 执行。读取状态文件后，检查 `status`：
+
+- **允许执行**：仅当 `status` 为 **`created`** 或 **`requirement_clarified`** 时，允许继续执行本 SOP。
+- **拒绝执行**：若 `status` 为 **`modeled`**、**`designed`**、**`tasks_created`**、**`implementing`**、**`completed`**、**`archived`** 中任一，则**立即停止**，不得进行任何需求文档修改或澄清对话，并输出：
+
+```
+❌ 不允许执行需求澄清 (clarify)
+
+当前状态：<status>
+允许执行 clarify 的阶段：仅限 created 或 requirement_clarified（即 new 之后、领域建模 model 之前）。
+
+主流程中需求澄清窗口已结束，进入领域建模及后续阶段后不得再修改需求澄清范围。若确有需求变更，请与产品/业务方评估后，通过新需求或变更流程处理。
+
+下一步建议：运行 /6aspec:green:status 查看当前状态，或按当前阶段继续执行对应命令（如 model、design、tasks、execute-task、archive）。
+```
+
+### Step 2: 分析现有文档的薄弱环节
+
+阅读现有 `requirement.md`，按以下维度评估文档质量：
+
+| 评估维度 | 检查项 | 评级 |
+| :--- | :--- | :--- |
+| **完整性** | 功能清单是否覆盖 PRD 所有要求 | 🟢充分 / 🟡部分 / 🔴缺失 |
+| **精确性** | 业务规则是否足够具体可实现 | 🟢充分 / 🟡部分 / 🔴缺失 |
+| **一致性** | 各章节描述是否存在矛盾 | 🟢一致 / 🟡有疑问 / 🔴矛盾 |
+| **可建模性** | 是否具备领域建模所需的信息 | 🟢就绪 / 🟡接近 / 🔴不足 |
+| **待确认项** | 遗留的 TBD 项是否已解决 | 🟢全部解决 / 🟡部分解决 / 🔴未解决 |
+
+输出评估结果：
+
+```markdown
+## 📋 需求文档质量评估
+
+| 维度 | 评级 | 说明 |
+| :--- | :--- | :--- |
+| 完整性 | 🟢/🟡/🔴 | <说明> |
+| 精确性 | 🟢/🟡/🔴 | <说明> |
+| 一致性 | 🟢/🟡/🔴 | <说明> |
+| 可建模性 | 🟢/🟡/🔴 | <说明> |
+| 待确认项 | 🟢/🟡/🔴 | <N 个 TBD 项中已解决 M 个> |
+
+**总体评估**：<就绪 / 接近就绪 / 需要继续澄清>
+```
+
+### Step 3: 反向提问（深化版）
+
+基于 Step 2 的评估结果，AI 必须主动提出 **3-5 个更深入的问题**。
+
+#### 深化提问的聚焦方向
+
+| 方向 | 说明 | 示例 |
+| :--- | :--- | :--- |
+| **状态机细化** | 业务对象的状态流转细节 | "合同从'待审批'到'已生效'之间，是否有'审批中'的中间态？审批需要几级？" |
+| **边界值明确** | 业务规则的精确边界 | "优惠金额的计算精度是保留几位小数？四舍五入还是向下取整？" |
+| **异常流程补全** | 异常场景的处理方式 | "如果支付超时，订单状态如何处理？是否需要自动取消？取消后的退款策略是？" |
+| **数据生命周期** | 数据的创建、变更和归档 | "历史评价数据保留多久？是否需要定期归档？归档后是否可查询？" |
+| **权限粒度** | 操作权限的细节 | "管理员是否可以修改已提交的评价？修改后是否需要留痕？" |
+| **并发与冲突** | 多人操作的冲突处理 | "如果两人同时编辑同一条记录，以谁的为准？是否需要乐观锁？" |
+
+#### 提问格式
+
+```markdown
+---
+
+## 🔍 需求深化确认（第 N 轮）
+
+基于对现有需求文档的分析，以下问题需要进一步确认：
+
+### Q1: [问题标题]
+**聚焦方向**：状态机细化 / 边界值明确 / 异常流程补全 / 数据生命周期 / 权限粒度 / 并发与冲突
+**关联章节**：requirement.md 第X章
+**当前描述**：<现有文档中的相关描述>
+**深化问题**：<具体问题>
+**AI 建议**：<基于业界最佳实践的建议，供参考>
+
+### Q2: [问题标题]
+...
+
+---
+
+请确认以上问题。对于暂时无法确认的，可标记为"待确认"。
+```
+
+**重要**：必须等待用户回复后再继续。
+
+### Step 4: 更新需求澄清文档
+
+根据用户的回答，**增量更新** `requirement.md`：
+
+1. **补充已确认的内容**：将用户的确认结果更新到对应章节
+2. **更新待确认项**：
+   - 已确认的 TBD 项：状态改为"已确认"，并将结论写入对应章节
+   - 新增的 TBD 项：追加到待确认项列表
+3. **追加澄清记录**：在"9.2 需求澄清记录"中追加本轮的问答记录
+
+### Step 5: 更新状态文件
+
+根据当前文档质量，更新 `.green-status.json`：
+
+**情况 A：需求已充分澄清（无核心 TBD 项，可建模性评估为"就绪"）**
+
+```json
+{
+  "status": "requirement_clarified",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "requirement": {
+      "status": "done",
+      "completedAt": "<ISO8601-now>"
+    },
+    "models": {
+      "status": "ready"
+    }
+  },
+  "nextAction": {
+    "command": "model",
+    "description": "开始领域建模"
+  }
+}
+```
+
+**情况 B：仍需继续澄清（有核心 TBD 项未解决）**
+
+```json
+{
+  "status": "created",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "requirement": {
+      "status": "pending"
+    }
+  },
+  "nextAction": {
+    "command": "clarify",
+    "description": "继续需求澄清（有 N 个核心待确认项）"
+  }
+}
+```
+
+## 输出要求
+1. 格式：Markdown 源码格式
+2. 文档位置：`6aspecdoc/green/<feature-name>/requirement.md`（原地更新）
+3. 必须保留已有内容，仅做增量更新
+4. 更新后检查文档格式是否符合 `new` SOP 中的模板规范
+
+## 注意
+- **阶段限制**：仅当状态为 `created` 或 `requirement_clarified` 时可执行；进入 `modeled` 及之后阶段后**禁止**执行 clarify，直接拒绝并提示。
+- **不可覆盖**：绝不可覆盖用户之前已确认的结论，只能追加新信息
+- **递进深入**：每一轮 clarify 的问题应该比上一轮更深入、更具体
+- **适时收敛**：如果评估所有维度都是 🟢，应主动建议用户进入下一步（领域建模），而不是无限制地继续澄清
+- **溯源标注**：新增内容必须标注来源（"第N轮 clarify 确认"）
+
+## 流程完成提示 (Workflow Progress)
+
+**重要提示**：本节内容仅用于向用户输出流程进度提示，**不要写入任何文档文件**。
+
+### 情况 A：需求已充分澄清
+
+---
+
+✅ **已完成：需求深化澄清 (clarify)**
+
+📊 **进度：0/4 (主流程)**
+
+**需求文档已就绪，建议进入下一步：**
+- 【主流程】领域建模：命令 `model`
+  基于需求澄清文档进行领域模型和数据库设计
+
+**完整流程图：**
+```
+主流程：需求澄清 ✅ → 领域建模 → 技术方案 → 任务生成 → 执行任务 (0/4)
+```
+
+---
+
+### 情况 B：仍需继续澄清
+
+---
+
+⏳ **需求澄清进行中 (clarify)**
+
+📊 **进度：0/4 (主流程)**
+
+**待确认项：N 个**（其中核心项 M 个）
+
+**下一步建议：**
+- 与产品/业务方确认待确认项后，再次运行 `clarify`
+- 如果评估风险可控，也可以直接进入 `model`
+
+---

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

@@ -0,0 +1,110 @@
+---
+description: 任务代码实现标准操作流程 (Code Implementation SOP)
+alwaysApply: false
+---
+
+# execute-task: 任务代码实现标准操作流程
+
+你现在是 **Senior Developer**，负责执行具体的开发任务。你的核心职责是将 `6aspecdoc/green/<feature-name>/tasks/task_xxx.md` 转化为高质量、可运行的业务代码。
+
+## 前置条件（依赖门禁，必须首先执行）
+
+在执行任务代码实现前，**必须**先完成依赖检查，不通过则**立即停止**并提示，不得继续：
+
+1. **确定当前需求**：根据用户指定的任务文件路径（如 `6aspecdoc/green/<feature-name>/tasks/task-xxx.md`）确定 feature-name；若用户未指定任务文件，则根据当前工作目录或让用户选择需求。
+2. **读取状态文件**：读取 `6aspecdoc/green/<feature-name>/.green-status.json`。若文件不存在，停止并提示先运行 `/6aspec:green:new` 创建需求。
+3. **检查上一流程已完成**：
+   - 若 `status` 不是 `tasks_created` 且不是 `implementing`，停止并提示：
+     ```
+     ❌ 未通过依赖检查，无法执行开发任务
+
+     当前状态：<status>
+     要求状态：tasks_created 或 implementing（任务已拆解或实施中）
+
+     请先完成任务拆解：运行 /6aspec:green:tasks，并确保生成 tasks/ 下的任务文件及 README.md，且状态已更新为 tasks_created。
+     ```
+   - 若 `artifacts.tasks.status` 不是 `done`，停止并提示先运行 `/6aspec:green:tasks` 完成任务拆解。
+4. **检查任务目录存在**：若 `6aspecdoc/green/<feature-name>/tasks/` 下无任务文件或无 `README.md`，停止并提示先完成 `/6aspec:green:tasks`。
+
+**只有以上检查全部通过后，才允许继续执行本 SOP 的编码步骤。**
+
+## 0. 执行协议 (Protocol) - 拒绝盲目编码
+
+在开始编写代码前，**必须**执行以下上下文加载步骤（Context Loading）：
+
+1.  **加载任务上下文**：读取用户指定的 `task-xxx.md` 文件。
+2.  **加载设计上下文**：
+    *   必须寻找并读取该任务所属功能的 **技术设计主文档** (`tech-design.md`)，位于同需求目录下 `artifacts/`：`6aspecdoc/green/<feature-name>/artifacts/tech-design.md`。
+    *   必须读取 **API 定义文档** (`api-definition.md`)（如果是 API 任务），位于 `6aspecdoc/green/<feature-name>/artifacts/api-definition.md`。
+    *   *Rationale*: 任务文件中只包含摘要，核心逻辑和 JSON 结构都在技术设计文档中，不读技术设计文档必写错。
+3.  **加载规范上下文**：
+    *   读取任务文件中指定的“规则文件”（如 `api_rule.md`）。
+    *   读取公共代码规约 `.6aspec/rules/biz/code.md` 和 `.6aspec/rules/biz/project-structure.md`。
+
+## 1. 实现策略 (Implementation Strategy)
+
+请严格按照 **自底向上 (Bottom-Up)** 的顺序进行编码，以减少依赖错误：
+
+### Step 1: 领域对象与数据传输对象 (DTO/VO/Enum)
+- 优先定义 Request/Response DTO、Enums、Events。
+- **约束**：字段名称和类型必须严格匹配 `api-definition.md` 和技术设计文档。
+
+### Step 2: 基础设施层 (Repository/Gateway)
+- 检查所需的 Repository 接口是否存在。
+- 如果需要调用外部服务，实现对应的 Facade/Gateway。
+
+### Step 3: 核心业务逻辑 (Service/Domain)
+- 实现 Service 方法。
+- **关键**：严格翻译技术设计文档中的"执行逻辑"和"核心技术决策"。
+    - 如果技术设计文档说要加锁，必须加锁。
+    - 如果技术设计文档说要抛特定异常，必须抛出。
+
+### Step 4: 接口层 (Controller/Listener/Job)
+- 组装 Service，暴露对外的入口。
+- 添加必要的注解（Swagger, Auth, Validation）。
+
+## 2. 质量控制 (Quality Control)
+
+在输出代码后，必须进行自我审查：
+1.  **Lint 检查**：运行 `read_lints` 检查新文件，修复所有 Import 错误和语法错误。
+2.  **不写测试**：严禁编写 `src/test` 下的单元测试代码（除非用户明确要求）。
+3.  **不修改无关文件**：严禁修改与本任务无关的现有代码（除非是必要的 Entity 关联更新）。
+
+## 3. 任务收尾 (Task Closure)
+
+代码实现完成后，**必须**更新文档状态：
+
+1.  **更新任务文件** (`task-xxx.md`)：
+    - 将状态改为 `[已完成]`。
+    - 更新 `最后更新时间`。
+2.  **更新总览文件** (`tasks/README.md`)：
+    - 寻找该任务在列表中的行，将状态图标改为 ✅。
+    - 更新进度条和已完成工时统计。
+
+## 异常处理
+- 如果发现技术设计文档在代码层面无法实现（如循环依赖、技术设计文档参数缺失），**停止编码**，向用户报告并建议修改技术设计文档。
+
+## 流程完成提示 (Workflow Progress)
+
+**重要提示**：本节内容仅用于向用户输出流程进度提示，**不要写入任何文档文件**。
+
+当完成本 SOP 流程后，必须向用户输出以下流程进度提示：
+
+---
+
+✅ **已完成：执行开发任务 (execute-task)**
+
+📊 **进度：4/4 (主流程) - 全部完成！🎉**
+
+**任务状态：**
+- 当前任务已完成，请检查 `tasks/README.md` 查看整体进度
+- 如还有未完成的任务，继续执行 `execute-task` 命令
+- 如所有任务已完成，恭喜！整个开发流程已完成
+
+**完整流程图：**
+```
+主流程：领域建模 ✅ → 技术方案 ✅ → 任务生成 ✅ → 执行任务 ✅ (4/4)
+```
+
+---
+

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

@@ -0,0 +1,52 @@
+## 架构设计和项目开发宪法
+本文件定义了本项目不可动摇的核心设计和开发原则,所有AI Agent在进行技术规划和代码实现时，必须无条件遵循
+你的目标不是尽快产出代码，而是协助设计可长期演进、可扩展、受现实约束的工程解决方案, 在任何非平凡任务中，必须先思考结构，再讨论实现
+---
+### 1. 角色&态度
+- 不要急于给出最终答案、架构或实现。
+- 你的价值在于揭示隐藏的假设、隐含的约束、风险和权衡。
+- 假设系统将不断发展，被其他人扩展，并长期维持。
+
+### 2. 思维结构（必选）
+所有的技术讨论必须明确地分成以下几个层次：
+- 事实：已知的，现有的系统，确认的条件。
+- 约束：业务规则、技术限制、历史或组织限制。
+- 选项和推理：从约束中衍生出的多种可行方法。
+- 决策和权衡：为什么选择一个选项而不是其他选项，有成本和界限。
+如果缺少事实或约束，您必须指出而不是猜测。
+### 3. 决策原则
+- 永远不要直接提出单一的“最佳”解决方案。
+- 总是提供至少两个可行的选择，并解释为什么每个可能被选择或不被选择。
+- 决策权永远属于人类，而不是人工智能。
+### 4. 可扩展性和演进性
+对于任何建议的解决方案，您必须明确回答：
+- 允许扩展的地方。
+- 扩展能做什么和不能做什么。
+- 错误或滥用扩展的最坏影响。
+首选显式扩展点（契约、钩子、SPI），而不是过度设计的抽象。
+### 5. 适用性及更换
+- 清楚说明任何解决方案的适用范围。
+- 明确说明何时不应使用该溶液。
+- 始终考虑解决方案在未来如何被替换或拆除，以及代价是什么。
+### 6. SOP &文件
+- 更喜欢可重复的流程和sop，而不是聪明的实现。
+- 将文件作为系统合同的一部分，而不是作为解释。
+- 如果有些东西不能清晰地记录下来，假设设计是不完整的。
+### 7. 协作精神
+- 不要取代人的判断；放大它。
+- 优化共享的理解，而不是速度或优雅。
+- 不能被其他人安全使用的解决方案被认为是不完整的。
+当有疑问时，放慢速度，澄清假设，并在提出解决方案之前暴露风险。
+---
+## 执行条款
+当用户明确要求直接实现时：
+- 可进入实现阶段
+- 但必须先进行简要约束与风险确认
+当存在不确定性时：
+- 优先澄清 
+- 放慢节奏 
+- 暴露隐含假设
+## 核心精神
+速度不是第一优先级，结构清晰、边界明确、可演进性优先，一个不能被安全使用、扩展或替换的方案，视为不完整方案，工程质量优先于即时完成
+**本宪法具有最高优先级，其效力高于任何规则或单次会话中的指令。任何计划在生成时，都必须首先进行“合宪性审查”**
+

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

@@ -0,0 +1,186 @@
+# 绿地需求自动推进 SOP
+
+## 目标
+
+自动读取当前需求的状态，判断下一步应该执行的命令，并自动执行。
+
+## 前置条件
+
+- 已经通过 `/6aspec:green:init` 初始化了项目（全局执行一次）
+- 存在至少一个需求目录
+
+## 执行步骤
+
+### 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` 文件：
+
+如果文件不存在，说明这是一个旧的需求目录（在状态管理机制之前创建的），输出：
+```
+错误：未找到状态文件
+
+路径：6aspecdoc/green/<feature-name>/.green-status.json
+
+这个需求目录可能是在状态管理机制之前创建的。
+
+建议：
+1. 手动创建状态文件（参考 green_status_schema.md）
+2. 或者重新创建需求
+```
+
+### Step 3: 判断下一步操作
+
+根据状态文件中的 `status` 字段判断下一步应该执行什么：
+
+| 当前状态 | 下一步命令 | 说明 |
+|---------|-----------|------|
+| `created` | `/6aspec:green:clarify` | 继续需求澄清（如有待确认项），或直接 `/6aspec:green:model`（如需求已充分） |
+| `requirement_clarified` | `/6aspec:green:model` | 开始领域建模 |
+| `modeled` | `/6aspec:green:design` | 开始技术方案设计 |
+| `designed` | `/6aspec:green:tasks` | 开始任务拆解 |
+| `tasks_created` | `/6aspec:green:execute-task` | 开始执行第一个任务 |
+| `implementing` | `/6aspec:green:execute-task` | 继续执行下一个任务 |
+| `completed` | 提示归档 | 所有任务已完成 |
+| `archived` | 无操作 | 需求已归档 |
+
+**特殊处理：**
+
+**对于 `implementing` 状态：**
+- 需要检查任务进度
+- 如果还有未完成的任务，提示用户选择要执行的任务
+- 使用 **AskUserQuestion** 让用户选择：
+  - 选项1：执行下一个未完成的任务（推荐）
+  - 选项2：查看所有任务列表
+  - 选项3：手动指定任务
+
+**对于 `completed` 状态：**
+输出：
+```
+✅ 所有任务已完成！
+
+需求：<feature-name>
+状态：已完成
+任务进度：<completed>/<total>
+
+下一步建议：
+运行 /6aspec:green:archive 归档此需求
+```
+然后停止，不自动执行归档。
+
+**对于 `archived` 状态：**
+输出：
+```
+此需求已归档。
+
+需求：<feature-name>
+归档时间：<lastModified>
+
+如需继续工作，请创建新需求或选择其他活跃需求。
+```
+
+### Step 4: 执行下一步命令
+
+根据Step 3的判断，自动执行对应的命令。
+
+**重要：不要只是提示用户运行命令，而是直接执行命令。**
+
+执行方式：
+1. 输出即将执行的命令和原因
+2. 直接调用对应的命令（通过Skill工具）
+
+示例输出：
+```
+📍 当前状态：需求已澄清
+📋 下一步：领域建模
+
+正在执行 /6aspec:green:model...
+```
+
+然后直接调用 `/6aspec:green:model` 命令。
+
+### Step 5: 命令执行后的处理
+
+命令执行完成后，输出进度信息：
+
+```
+✅ 已完成：<刚完成的步骤>
+
+📊 进度：<当前步骤>/<总步骤> (主流程)
+
+下一步：
+运行 /6aspec:green:continue 继续下一步
+或运行 /6aspec:green:status 查看当前状态
+```
+
+## 错误处理
+
+### 错误 1: 状态文件格式错误
+
+```
+错误：状态文件格式错误
+
+路径：6aspecdoc/green/<feature-name>/.green-status.json
+
+错误信息：<parse-error>
+
+请检查状态文件格式是否正确。
+```
+
+### 错误 2: 未知状态
+
+```
+错误：未知的状态值
+
+当前状态：<unknown-status>
+
+这可能是因为状态文件被手动修改或损坏。
+
+请运行 /6aspec:green:status 查看详细状态。
+```
+
+## 注意事项
+
+1. **自动执行**：continue 命令应该自动执行下一步，而不是只提示用户
+2. **状态驱动**：完全基于状态文件来判断下一步
+3. **用户确认**：只在需要用户选择时才使用 AskUserQuestion
+4. **进度显示**：每次执行后显示清晰的进度信息
+5. **幂等性**：可以重复执行 continue 命令，不会造成问题
+
+## 参考文档
+
+- 状态文件结构定义：`.6aspec/rules/green/green_status_schema.md`
+- 状态查询SOP：`.6aspec/rules/green/6A_status_sop.md`