6aspec 2.0.0-dev.2

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

@@ -0,0 +1,210 @@
+---
+description: 数据模型设计标准操作流程 (Data model design SOP)
+alwaysApply: false
+---
+
+# model: 数据模型设计标准操作流程 (Data model design SOP)
+
+## 角色色
+你现在的角色是【领域架构师 + 数据建模专家】，负责在编写任何业务代码前，完成最核心的数据架构设计。你认为“数据模型是对业务本质的抽象”，因此你严控冗余，追求模型的高内聚与低耦合。
+
+## 目标
+- 基于 PRD 和已确认的领域模型，设计稳定、可演进的数据模型
+- 本阶段不允许设计接口、流程、事件、定时任务
+
+## 规则：
+1. **复用评估（Reuse Evaluation）**：
+   - **检索与分析**：必须检索 `./.6aspec/biz/functional-capability-Map.md`，查找潜在相关的现有资产。
+   - **决策原则**：
+      - **优先复用**：若新数据的**业务含义**、**生命周期**与现有资产高度一致，应优先复用。
+      - **避免硬套**：若仅仅是字段相似但业务归属不同（如“访客姓名”与“业主姓名”），或强行复用会导致概念混淆与高耦合，则应新建表或独立模块。
+2. **领域驱动**：先有领域对象（Domain Object）及其关系，再有物理数据库表（Physical Table）
+3. 若发现以下任一情况，必须中断并提问：
+    - 字段语义不清
+    - 是否复用已有表无法确认
+
+## 前置条件（依赖门禁，必须首先执行）
+
+在执行领域建模前，**必须**先完成依赖检查，不通过则**立即停止**并提示，不得继续：
+
+1. **确定当前需求**：根据当前工作目录或用户 @ 的文件，确定 `6aspecdoc/green/<feature-name>/`；若有多个需求则让用户选择。
+2. **读取状态文件**：读取 `6aspecdoc/green/<feature-name>/.green-status.json`。若文件不存在，说明尚未通过 `new` 创建该需求，停止并提示：
+   ```
+   ❌ 未通过依赖检查，无法执行领域建模
+
+   原因：未找到状态文件，该需求尚未通过 /6aspec:green:new 创建。
+
+   请先运行 /6aspec:green:new 创建需求并完成需求澄清。
+   ```
+3. **检查上一流程已完成**：
+   - 若 `status` 不是 `requirement_clarified`，停止并提示：
+     ```
+     ❌ 未通过依赖检查，无法执行领域建模
+
+     当前状态：<status>
+     要求状态：requirement_clarified（需求已澄清）
+
+     请先完成需求澄清：运行 /6aspec:green:new 或 /6aspec:green:clarify，并确保生成 requirement.md 且状态已更新为 requirement_clarified。
+     ```
+   - 若 `artifacts.requirement.status` 不是 `done`，停止并提示：
+     ```
+     ❌ 未通过依赖检查，无法执行领域建模
+
+     需求澄清文档（requirement）尚未完成。
+
+     请先运行 /6aspec:green:new 或 /6aspec:green:clarify 完成 requirement.md 后再执行 model。
+     ```
+4. **检查 requirement.md 存在**：若 `6aspecdoc/green/<feature-name>/requirement.md` 不存在或为空，停止并提示先完成需求澄清。
+
+5. **检查项目已初始化（可选但推荐）**：若 `./.6aspec/biz/functional-capability-Map.md` 不存在，提示：
+   ```
+   ⚠️ 未检测到能力地图，建议先运行 /6aspec:green:init 初始化项目（生成能力地图与事件清单），以便建模时复用现有资产。
+   是否仍继续？（继续则无法做复用评估）
+   ```
+   若用户选择继续，可仅基于 requirement 建模；否则等待用户执行 init 后再执行 model。
+
+**只有第 1～4 项检查全部通过后，才允许继续执行本 SOP 的建模步骤。**
+
+## 输入要求
+- **首选输入**：需求澄清文档 `requirement.md`（由 `/6aspec:green:new` 生成，位于 `6aspecdoc/green/<feature-name>/requirement.md`）
+- **备选输入**：如果尚未执行 `new` 命令，可直接使用 PRD（产品需求文档）或功能需求描述
+- **可选输入**：已确认的领域边界与核心实体语义(可以是markdown文档)
+- **系统自带知识库**：
+    - 现有能力地图:`./.6aspec/biz/functional-capability-Map.md`
+    - **C端用户体系规范**:`./.6aspec/rules/biz/c_user_system_rule.md` (仅在涉及C端用户/门户/小程序相关设计时**必需**读取)
+
+> **注意**：如果用户提供了 `requirement.md`，应以其中的功能清单、业务规则和范围界定为基础进行建模，确保模型与已确认的需求保持一致。
+
+
+## 第一阶段：资产审计与策略定义 (Asset Audit)
+在进行具体建模前，请执行以下审计动作：
+- [ ] **资产对齐**：检索《能力地图》查找相关联的业务领域。评估其数据结构是否涵盖当前需求，识别是“引用现有实体”、“扩展现有实体”还是“完全独立的业务对象”。
+- [ ] **逻辑依赖**：识别新模型需要引用的外部主键（如 `contractId`, `customerId`）
+
+## 第二阶段：模型设计流程 (Design Process)
+
+### 第一步：资产映射分析表 (Asset Mapping)
+请按以下格式输出，证明你已深度思考复用性：
+
+| 业务实体 (Entity) | 存储策略 | 复用理由/冲突说明 | 涉及模块与表名 |
+| :--- | :--- | :--- | :--- |
+| (例：评价维度) | 现有模块复用 | 基础数据已有字典配置能力 | `rental-basicdata` |
+| (例：评价单) | 新建独立表 | 核心业务凭证，现有表无法承载 | `rental-customer` |
+
+### 第二步：领域模型设计 (Domain Modeling)
+
+1. **核心领域对象说明 (Domain Object Definitions)**
+   需识别并解释核心领域名词（聚合根、实体、值对象），按如下表格输出：
+   | 领域对象 | 类型 | 业务含义与职责 | 生命周期描述 |
+   | :--- | :--- | :--- | :--- |
+   | (例：评价单) | 聚合根 | 记录客户对服务的评价内容 | 创建 -> 待评价 -> 已评价 -> 归档 |
+   | (例：评价维度) | 值对象 | 定义评价的具体切面（如响应速度） | 随评价配置创建，不可变 |
+
+2. **领域事件设计 (Domain Events)**
+   识别领域状态变更产生的关键业务事件：
+   | 事件名称 | 触发条件 | 携带关键数据 | 消费方示例 |
+   | :--- | :--- | :--- | :--- |
+   | (例：评价已提交) | 用户完成表单提交并落库 | 评价单ID, 评分, 评价时间 | 积分系统, 消息通知 |
+
+3. **UML 类图 (Class Diagram)**
+   使用 Mermaid 语法绘制：
+   - **要求**：展示实体（Entity）之间的关系（一对一、一对多、组合关系），实体的字段必须要有中文说明
+   - **禁止内容**：不要在此阶段绘制任何 Flowchart（流程图）或 Sequence（时序图）
+
+
+### 第三步：数据库物理设计 (Physical Schema)
+根据领域模型，进行表设计，必须遵循以下格式规范：
+1. **命名与类型约束**：
+    - **表命名规则**：前缀`{业务系统名}_{表名}`,表名必须是驼峰命名，例如：`yymh_visitorInvitation`
+    - **字段命名规则**：
+        - 必须使用 **驼峰命名风格 (camelCase)**
+        - **主键命名**：必须遵循 `{表名}GUID` 格式。类型必须是：主键，例如：表名 `User` -> `userGUID`
+        - **外键命名**：字段名称必须以 `Id` 结尾，例如 `contractId`
+        - **状态字段**：若为整数类型且表示状态，必须在说明列中标注枚举值（如：`0-禁用, 1-启用`），字段中文名称也必须体现，如邀约状态: 0-未开始, 1-进行中, 2-已结束
+        - **项目ID字段**：项目ID字段，必须使用 `ProjGUID` 命名,类型必须是：唯一标识
+    - **字段类型严格约束**（必须从下表选择，**严禁**使用 `varchar`, `int`, `datetime` 等数据库物理类型）：
+
+   | 类型名称 | 默认长度 | 约束说明                                      |
+       | :--- | :--- |:------------------------------------------|
+   | **主键** | -1 | **每表必有且仅有一个**，命名严格遵循 `{表名}GUID`           |
+   | **唯一标识** | -1 | **外键字段必须选此类型**。也用于CompanyId、customerId等场景 |
+   | **单行文本** | 128 | 可选长度：16, 32, 64, 128, 512, 1024。适用于名称、编码等 |
+   | **多行文本** | -1 | 适用于备注、描述等大文本量字段                           |
+   | **富文本** | -1 | 适用于公告、合同条款等带格式文本                          |
+   | **日期与时间** | -1 | 日期或时间类型                                   |
+   | **整数** | -1 | 计数、状态值等                                   |
+   | **金额** | 18 | 货币相关，支持设置精度                               |
+   | **面积** | 12 | 空间大小，支持设置精度                               |
+   | **比率** | 29 | 百分比、税率、达成率等                               |
+   | **汇率** | 18 | 货币兑换比率                                    |
+   | **附件** | -1 | 文件上传场景                                    |
+   | **图片** | -1 | 图片上传展示场景                                  |
+   | *长整数* | -1 | *不建议使用*                                   |
+
+    - **禁止项**：模型设计阶段 **不要** 包含 `CreatedTime`, `ModifiedTime`, `CreatedBy`, `ModifiedBy`, `VersionNumber` 等系统自动维护字段
+2. 输出模板 (必须严格执行)
+   A、标题：{序号}. {中文表名}({表英文名})
+   B、表格展示：使用表格展示表的结构，表格的格式说明如下
+- 第一行，第一列：固定值：表中文名称，第二列：表中文名称
+- 第二行，第一列：固定值：表英文名称，第二列：表英文名称
+- 第三行，第一列：固定值：说明，第二列：说明
+- 第四行开始，第一列：字段中文名称，第二列：字段英文名称，第三列：字段类型，第四列：长度，第五列：是否必填(是、否)，第六列：字段说明，第七列：业务来源
+
+#### 表设计表格展示示例
+```
+##### 1. 服务评价单表 (rental_ServiceEvaluation)
+| 表中文名称 | 服务评价单表 |
+| :--- | :--- |
+| 表英文名称 | rental_ServiceEvaluation |
+| 说明 | 服务评价单主表，记录服务评价的完整信息 |
+
+| 字段中文名称 | 字段英文名称 | 字段类型 | 长度 | 是否必填 | 字段说明 | 业务来源 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| 服务评价单GUID | serviceEvaluationGUID | 唯一标识 | - | 是 | 主键 | 系统生成 |
+| 服务评价单号 | serviceEvaluationNo | 单行文本 | 是 | 64 | 服务评价单编号，系统自动生成 | PRD 3.1.2 评价规则 |
+| 服务场景 | serviceScene | 单行文本 | 64 | 是 | 服务场景：预约带看、合同新签、入住办理、换房办理、退房办理、报事工单、报修工单、投诉工单、建议工单 | PRD 3.2 场景枚举 |
+```
+
+### 第四步：关键决策说明 (Key Design Decisions)
+对建模过程中的核心决策进行记录，特别是涉及**复用/新建**、**拆分/合并**、**性能/范式**权衡的场景：
+
+| 决策点 | 备选方案 | 最终选择 | 决策理由 |
+| :--- | :--- | :--- | :--- |
+| (例：评价状态存储) | 方案A：在主表存状态字段<br>方案B：独立状态流水表 | 方案A | 业务逻辑简单，无须追溯状态变更历史，且查询性能要求高 |
+| (例：客户信息引用) | 方案A：冗余客户名称<br>方案B：仅存客户ID | 方案B | 客户改名频率低，且需保证各模块显示一致，通过前端关联查询解决展示问题 |
+
+## 输出要求：
+1. 格式：Markdown 源码格式
+2. 文档位置：`6aspecdoc/green/<feature-name>/artifacts/` 目录（feature-name 使用 kebab-case 命名，如：user-authentication）
+3. 文档命名：`domain-model.md`（完整路径：`6aspecdoc/green/<feature-name>/artifacts/domain-model.md`）
+4. 请务必检查下第三步的输出是否满足格式要求
+
+## 注意
+- **严格溯源**：所有字段必须有明确的业务来源（PRD章节、补充需求文档或业界通用标准），并在"业务来源"列中明确标注，严禁"为了完整"而臆造字段。
+- **一致性**：表格中的说明必须与 PRD 描述保持一致。
+
+## 流程完成提示 (Workflow Progress)
+
+**重要提示**：本节内容仅用于向用户输出流程进度提示，**不要写入任何文档文件**。
+
+当完成本 SOP 流程后，必须向用户输出以下流程进度提示：
+
+---
+
+✅ **已完成：领域建模 (model)**
+
+📊 **进度：1/4 (主流程)**
+
+**下一步建议：**
+- 【主流程】技术方案设计：命令 `design`
+  基于领域模型设计接口、事件、定时任务等技术方案
+- 【可选】表导入建模平台：命令 `import-model-table`
+  将设计好的数据模型导入到建模平台
+
+**完整流程图：**
+```
+主流程：需求澄清 ✅ → 领域建模 ✅ → 技术方案 → 任务生成 → 执行任务 (1/4)
+可选流程：需求深化澄清 / 表导入建模平台 / 生成可视化逻辑图
+```
+
+---

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 混淆）**
+
+- 若当前工作目录已在 `6aspecdoc/green/<某需求名>/` 下，或用户 @ 的文件位于某需求目录内，则**先提示**：
+  ```
+  当前处于需求目录「<需求名>」内。如需对本需求继续澄清，请使用 /6aspec:green:clarify；
+  如需新建另一个需求，请切换到项目根目录后再次执行 /6aspec:green:new。
+  ```
+  并询问用户是「对当前需求继续澄清（改用 clarify）」还是「确认要新建另一需求（继续 new）」。
+
+**1.1 确定特性名称**
+
+根据用户提供的 PRD 或需求描述，提取核心功能名称，转换为 kebab-case 格式。
+
+如果无法从文档中明确提取，使用 **AskUserQuestion** 让用户确认特性名称：
+
+```
+请确认本次需求的特性名称（将用于目录命名）：
+
+建议名称：<suggested-name>
+
+您也可以输入自定义名称（使用英文短横线分隔，如 user-authentication）。
+```
+
+**1.2 创建目录结构**
+
+```
+6aspecdoc/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": "6aspecdoc/green/<feature-name>/requirement.md"
+    },
+    "models": {
+      "status": "blocked",
+      "path": "6aspecdoc/green/<feature-name>/artifacts/"
+    },
+    "design": {
+      "status": "blocked",
+      "path": "6aspecdoc/green/<feature-name>/artifacts/"
+    },
+    "tasks": {
+      "status": "blocked",
+      "path": "6aspecdoc/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. 文档位置：`6aspecdoc/green/<feature-name>/requirement.md`
+3. 文档命名：`requirement.md`
+4. 必须包含"待确认项"章节（即使为空）
+
+## 注意
+- **严格溯源**：所有功能项、业务规则必须有明确的 PRD 来源标注
+- **不可臆断**：对于 PRD 中未明确说明的内容，不可自行补充假设，必须通过反向提问确认或记录为"待确认项"
+- **范围克制**：只记录 PRD 中明确要求或用户确认的功能，不主动扩大范围
+
+## 流程完成提示 (Workflow Progress)
+
+**重要提示**：本节内容仅用于向用户输出流程进度提示，**不要写入任何文档文件**。
+
+当完成本 SOP 流程后，必须向用户输出以下流程进度提示：
+
+---
+
+✅ **已完成：需求澄清 (new)**
+
+📊 **进度：0/4 (主流程)**
+
+**下一步建议：**
+- 【可选】深化需求澄清：命令 `clarify`
+  如有待确认项或想进一步细化需求，可继续澄清
+- 【主流程】领域建模：命令 `model`
+  基于需求澄清文档进行领域模型和数据库设计
+
+**完整流程图：**
+```
+主流程：需求澄清 ✅ → 领域建模 → 技术方案 → 任务生成 → 执行任务 (0/4)
+可选流程：需求深化澄清 / 表导入建模平台 / 生成可视化逻辑图
+```
+
+---