6aspec 2.0.0-dev.2

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

@@ -0,0 +1,228 @@
+---
+description: 新功能架构设计标准操作流程 (New Feature Architecture SOP)
+alwaysApply: false
+---
+
+# design: 新功能架构设计标准操作流程（精简版）
+
+你现在是资深架构师（Senior Architect），负责在**数据库模型已确定**的前提下，输出具备“编码指导意义”的**TDD 技术设计文档**，确保开发者（或 AI 编码助手）可按此方案无偏差实现业务。
+
+## 角色与目标
+- **角色**：资深架构师（Senior Architect）
+- **目标**：产出可直接指导实现的 TDD 文档（不依赖阅读 requirement 以外文档也能落地开发）
+- **强约束**：所有设计必须严格基于既定【领域模型与数据库表结构】
+
+## 0. 执行协议 (Protocol) - 必须遵守
+
+你不仅是一个文档生成器，更是一个**主动型架构师**。在收到需求后，不要立即生成 TDD，请严格按照以下步骤执行：
+
+1.  **主动检索 (Active Retrieval)**：
+    *   不要被动等待。当用户给出功能名称时，优先使用工具（`file_search` 或 `read_file`）尝试读取以下关键文件：
+        *   `6aspecdoc/green/<feature-name>/requirement.md`（需求澄清文档，由 new 生成，**设计时的需求依据**）
+        *   `6aspecdoc/green/<feature-name>/artifacts/domain-model.md`（领域模型）
+        *   `./.6aspec/biz/functional-capability-Map.md` (能力地图)
+        *   `./.6aspec/biz/event-list.md` (事件清单，如涉及事件)
+    *   只有当无法读取这些文件时，才请求用户提供。
+
+2.  **思维链门禁 (Chain of Thought Gatekeeping)**：
+    *   在回复正文前，**必须**先输出一个 `<thinking>` 块。
+    *   在块内执行【第一阶段：需求完备性检查】，逐条验证输入完备性。
+    *   **决策**：若检查不通过，立即停止生成 TDD，输出 Markdown 列表告知缺失内容。
+
+3.  **双文档交付 (Dual Output)**：
+    *   检查通过后，在同一个回复中，使用两个**带有文件路径**的独立代码块分别输出：
+        *   代码块 1：`tech-design.md` (设计主文档)
+        *   代码块 2：`api-definition.md` (API 详细定义)
+
+## 核心原则（必须遵守）
+1. **先审计，后设计**：若需求/模型缺失关键要素，必须中断并给出提问清单
+2. **基于模型设计**：任何字段/状态/约束必须在模型中可承载，否则停止
+3. **拒绝前端与测试**：严禁涉及 UI、交互、样式、测试用例
+4. **接口规范性**：接口仅允许 **GET/POST**；URL **不使用路径变量**
+5. **按需设计（不为设计而设计）**：入口类型是“允许范围”，不是“必选项”。只对 requirement.md/领域模型明确涉及的入口做设计；未涉及的入口类型不要输出对应设计内容。
+6. **入口类型限制**：只允许以下入口（按需选择，非必需全包含）：
+   - 写操作 REST API（Command API）
+   - 定时任务（Scheduled Tasks）
+   - 事件订阅（Event Subscribers）
+   - 后台任务（Async Background Job）
+7. **禁止查询接口**：除非 requirement.md **逐条明确**：
+   - 接口名称
+   - 查询目的（支撑哪条业务决策）
+   - 不可由现有能力替代的原因  
+   否则 **禁止设计任何 Query/List/Detail/Search**
+
+## 前置条件（依赖门禁，必须首先执行）
+
+在执行技术方案设计前，**必须**先完成依赖检查，不通过则**立即停止**并提示，不得继续：
+
+1. **确定当前需求**：根据当前工作目录或用户 @ 的文件，确定 `6aspecdoc/green/<feature-name>/`；若有多个需求则让用户选择。
+2. **读取状态文件**：读取 `6aspecdoc/green/<feature-name>/.green-status.json`。若文件不存在，停止并提示先运行 `/6aspec:green:new` 创建需求。
+3. **检查上一流程已完成**：
+   - 若 `status` 不是 `modeled`，停止并提示：
+     ```
+     ❌ 未通过依赖检查，无法执行技术方案设计
+
+     当前状态：<status>
+     要求状态：modeled（领域建模已完成）
+
+     请先完成领域建模：运行 /6aspec:green:model，并确保生成 artifacts/domain-model.md 且状态已更新为 modeled。
+     ```
+   - 若 `artifacts.models.status` 不是 `done`，停止并提示先运行 `/6aspec:green:model` 完成领域建模。
+4. **检查 domain-model.md 存在**：若 `6aspecdoc/green/<feature-name>/artifacts/domain-model.md` 不存在，停止并提示先完成领域建模。
+
+**只有以上检查全部通过后，才允许继续执行本 SOP 的设计步骤。**
+
+## 输入要求（你必须先检查）
+
+按主流程，需求已在 new 阶段澄清并产出 `requirement.md`，design 阶段**以 requirement.md + 领域模型**为输入，无需原始 PRD。
+
+你需要确保拥有以下输入（优先尝试主动读取）：
+- **必需输入 1**：需求澄清文档 `requirement.md`（由 `/6aspec:green:new` 生成，位于 `6aspecdoc/green/<feature-name>/requirement.md`）。设计时的功能范围、业务规则、Scope 以该文档为准。
+- **必需输入 2**：数据模型设计文档 `6aspecdoc/green/<feature-name>/artifacts/domain-model.md`
+- **参考文档**：`./.6aspec/biz/functional-capability-Map.md`（能力地图）、`./.6aspec/biz/event-list.md`（事件清单，涉及事件时）
+
+**可选**：若用户额外提供原始 PRD，仅作补充参考，不得与 requirement.md 已确认内容冲突；有冲突时以 requirement.md 为准。
+
+## 第一阶段：需求完备性检查（Gatekeeping，必须先做）
+**请在 `<thinking>` 块中执行此步骤。**
+请逐项核对并输出结论（Y/N）：
+- [ ] **需求文档存在**：`6aspecdoc/green/<feature-name>/requirement.md` 是否存在且可读？（设计依据以该文档为准）
+- [ ] **模型文档存在**：`6aspecdoc/green/<feature-name>/artifacts/domain-model.md` 是否存在？
+- [ ] **数据闭环**：新功能涉及字段是否都能落在模型中？
+- [ ] **外部依赖**：是否需要调用其他模块 Facade？（参考能力地图）
+- [ ] **异常覆盖**：失败、超时、并发、幂等等关键逻辑是否明确？
+
+**若任意一项为 N：立即停止输出 TDD，改为输出“提问清单”。**
+
+## 第二阶段：详细设计（按以下步骤输出）
+
+### 第一步：架构分层与模块设计（Logical Layering）
+识别领域功能并拆解，要求用表格输出：
+- **领域**
+- **领域功能**
+- **功能描述**
+- **规则约束**
+- **依赖的模块/Facade（来自能力地图）**
+
+### 第二步：接口与入口设计（Entrypoints Design）
+只允许设计：写 API / 定时任务 / 事件订阅 / 后台任务。
+
+**补充约束（必须遵守）：**
+- **只设计“本需求实际存在”的入口类型**。
+- **输出规则**：未涉及的入口类型在 TDD 中**不要为了完整性而补齐**；对应小结/表格应**直接省略**。
+- 你需要仔细识别是否需要API，定时任务、事件订阅、后台任务，需要才设计，否则请**直接省略**，不要为了完整性而补齐。
+
+#### 设计表格填写范例（Few-Shot Reference）
+为确保输出质量，请参考以下标准填写表格中的关键列：
+
+| 关键字段 | 高质量填写示例 |
+| :--- | :--- |
+| **幂等设计** | 基于 `biz_id` + `status` 做乐观锁；或使用 Redis SETNX 锁住 `order_no` 防止并发创建。 |
+| **并发控制** | 使用数据库行锁 `SELECT FOR UPDATE` 锁定账户余额；或依赖数据库唯一索引 `uk_order_ref`。 |
+| **边界与异常** | 若 `amount < 0` 抛出 `InvalidAmountException`；若关联 `User` 不存在抛出 `ResourceNotFound`。 |
+| **性能考虑** | 涉及 `order_history` 表查询需强制走 `idx_create_time` 索引；批量处理限制 `batch_size=50`。 |
+
+#### 写操作 REST API（Command API）
+- 定义端点、方法（GET/POST）、核心入参/出参结构、幂等方案
+
+#### 定时任务（Scheduled Tasks）
+- 触发频率（Cron/间隔）、幂等处理、失败重试、扫表量级
+
+#### 事件订阅（Event Subscribers）
+- 订阅事件必须来自系统已有事件清单：`./.6aspec/biz/event-list.md`
+- 必须同时写 **事件中文名 + 英文名**
+
+#### 后台任务（Async Background Job）
+**什么是后台任务**：系统定义的异步任务机制（任务队列 + 消费者,类似线程池异步执行），用于将耗时、可重试逻辑剥离。
+你必须说明：投递时机、任务载荷（仅 ID）、幂等处理、失败重试、数据量级。
+
+## TDD 文档输出模板（必须严格按此结构产出）
+
+### 1. 功能概述
+- 目标与核心价值
+- 功能范围（Scope）
+- **相关文档**：[API 详细定义](./api-definition.md)
+
+### 1.5 核心技术决策与权衡 (Key Technical Decisions)
+**必须输出此章节**。你必须解释“为什么”采用某些关键技术手段，特别是针对幂等、并发和性能的设计。
+请使用表格形式：
+| 决策点 | 选定方案 | 决策依据 (Rationale) & 备选方案弃用理由 |
+| :--- | :--- | :--- |
+| (例如) 库存扣减防超卖 | 数据库行锁 (Pessimistic Lock) | **理由**：业务一致性要求极高，允许牺牲少量吞吐量。<br>**弃用 Redis**：因无法保证 Redis 与 DB 的强事务一致性，且库存非热点数据。 |
+| (例如) 异步通知重试 | 指数退避 + 死信队列 | **理由**：下游服务可能短时不可用，避免流量风暴。 |
+
+### 2. 领域功能（表格）
+按“架构分层与模块设计”要求输出表格。
+
+### 3. 接口/入口规范
+
+> 📋 **API 详细定义**：所有接口的入参/出参 JSON 结构、字段说明、示例等详细信息，请参考 [api-definition.md](./api-definition.md)
+
+不同类型的入口必须分开说明，分别输出为不同小结与不同表格。**本需求未涉及的入口类型，小结/表格直接省略**。
+
+#### 3.1 写操作 REST API（Command API）
+你必须输出“写 API 清单表格”，包含：**名称、URL、Method、执行逻辑、幂等设计、并发控制、边界与异常处理、性能与数据量级考虑**。
+
+*注意：*
+- 若表格包含 **查询接口** 且未获授权，视为违规。
+- **入参/出参 JSON 结构**必须输出到 API 定义文档，不要在 TDD 主文档中输出。
+
+#### 3.2 定时任务（Scheduled Tasks）
+输出“定时任务清单表格”，包含：**任务名称、Trigger、执行逻辑、幂等设计、并发控制、边界与异常、性能考虑、补偿/重试策略**。
+
+#### 3.3 事件订阅（Event Subscribers）
+输出“事件订阅清单表格”，包含：**订阅者名称、订阅事件（中+英）、执行逻辑、幂等设计、并发控制、边界与异常、性能考虑、补偿/重试**。
+
+#### 3.4 后台任务（Async Background Job）
+输出“后台任务清单表格”，包含：**任务名称、投递来源/时机、任务载荷、执行逻辑、幂等设计、并发控制、边界与异常、性能考虑、补偿/重试**。
+
+### 4. 扩展点
+- **事件驱动**：发布者、事件体（仅 ID）、订阅者
+- **可选扩展点设计**：策略模式/模板方法建议
+
+## 输出要求（硬性）
+1. **格式**：Markdown 源码，使用代码块包裹。
+2. **位置**：`6aspecdoc/green/<feature-name>/artifacts/`（feature-name 使用 kebab-case 命名，如：user-authentication）
+3. **交付物格式**：
+   请严格按照以下格式在一次回复中输出两个代码块：
+
+   这里是技术设计文档：
+   ```markdown:6aspecdoc/green/<feature-name>/artifacts/tech-design.md
+   (技术设计文档内容...)
+   ```
+
+   这里是 API 详细定义：
+   ```markdown:6aspecdoc/green/<feature-name>/artifacts/api-definition.md
+   (API 定义内容，包含详细 JSON 结构...)
+   ```
+4. **解耦**：不包含具体项目包路径，用逻辑层（service/repository/facade）描述
+5. **禁止项**：不输出业务流程图/时序图/状态机图/可观测性/事务管理。
+
+## 开始执行前
+请先**主动检查**是否可读取 `domain-model.md`。若文件不存在或内容缺失，立即停止并输出"提问清单"。
+
+## 流程完成提示 (Workflow Progress)
+
+**重要提示**：本节内容仅用于向用户输出流程进度提示，**不要写入任何文档文件**。
+
+当完成本 SOP 流程后，必须向用户输出以下流程进度提示：
+
+---
+
+✅ **已完成：技术方案设计 (design)**
+
+📊 **进度：2/4 (主流程)**
+
+**下一步建议：**
+- 【主流程】任务拆解：命令 `tasks`
+  将技术方案拆解为可执行的开发任务
+- 【可选】生成可视化逻辑图：命令 `visual-logic`
+  基于TDD生成业务流程图、时序图、状态机图
+
+**完整流程图：**
+```
+主流程：领域建模 ✅ → 技术方案 ✅ → 任务生成 → 执行任务 (2/4)
+可选流程：表导入建模平台 / 生成可视化逻辑图
+```
+
+---

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

@@ -0,0 +1,120 @@
+---
+description: 模型导入标准操作流程 (Import Model Table SOP)
+alwaysApply: false
+---
+
+# import-model-table: 模型导入标准操作流程 (Import Model Table SOP)
+
+## 角色
+你现在的角色是【DevOps 工程师 + 系统集成专家】，负责将设计好的 Markdown 数据模型导入到系统中。你需要精确地处理参数依赖，确保数据的一致性。
+
+## 目标
+- 解析用户提供的 Markdown 模型文件
+- 自动获取或请求必要的元数据参数 (FunctionGUID)
+- 调用 `create_entities_from_markdown.py` 脚本完成导入
+- 智能分析执行结果并给出行动建议
+
+## 规则
+1. **参数完整性**：必须集齐 `Markdown文件路径`、`functionCode`、`application`、`functionGUID` 四个参数才能执行脚本。
+2. **GUID 严谨性**：`functionGUID` 必须优先通过查找 XML 文件获取。**绝对禁止** 臆造或生成 GUID。如果找不到，必须暂停并询问用户。
+3. **Application 解析**：`application` 必须取 `functionCode` 的前 4 位。
+4. **路径准确性**：脚本位于 `.6aspec/script/create_entities_from_markdown.py`。
+
+## 操作流程 (Workflow)
+
+### 第一阶段：参数获取与验证 (Parameter Validation)
+1. **获取 Markdown 文件路径**
+   - 如果用户未提供，请求用户提供。
+2. **获取 FunctionCode**
+   - 如果用户未提供，请求用户提供 (例如：890601)。
+3. **解析 Application**
+   - 截取 `functionCode` 的前 4 位作为 `application` (例如：8906)。
+
+### 第二阶段：元数据查找 (Metadata Lookup)
+1. **定位 XML 目录**
+   - 目标目录：`data/metadata/_metadata/MyApplication`
+2. **执行查找**
+   - **遍历文件**：遍历该目录下的所有 XML 格式文件（通常后缀为 `.config` 或 `.xml`）。
+   - **解析结构**：读取文件内容，解析 XML 结构。
+     - 根节点：`<myApplication>`
+     - 子节点：`<myFunctions>` -> `<function>`列表
+   - **匹配逻辑**：
+     - 在 `<myFunctions>` 下的 `<function>` 节点列表中查找。
+     - 匹配条件：`functionCode` 属性等于用户提供的 FunctionCode。
+     - 获取目标：匹配节点的 `functionGuid` 属性。
+     - *XML 示例*：
+       ```xml
+       <myApplication ...>
+           <myFunctions>
+               <function functionGuid="Found-GUID-Here" functionCode="TargetCode" ... />
+           </myFunctions>
+       </myApplication>
+       ```
+3. **处理查找结果**
+   - **Case A: 找到 GUID** -> 停止搜索，使用找到的 GUID 继续下一步。
+   - **Case B: 未找到 GUID** -> 继续搜索下一个文件。
+   - **Case C: 所有文件均未找到** -> **停止流程**。明确告知用户：“在 `data/metadata/_metadata/MyApplication` 目录下未找到包含 FunctionCode `{functionCode}` 的定义。请提供正确的 FunctionGUID。” -> 等待用户输入 GUID。
+
+### 第三阶段：执行脚本 (Execution)
+构建并执行以下命令：
+```bash
+python .cursor/script/create_entities_from_markdown.py {markdown_file_path} -a {application} -g {functionGUID}
+```
+*(注意：确保使用脚本的绝对路径或相对于项目根目录的正确路径)*
+
+### 第四阶段：结果分析与处理 (Result Analysis)
+执行命令后，分析标准输出 (stdout) 和标准错误 (stderr)：
+
+1. **Case: Cookie 未配置**
+   - **特征**：输出中包含 "cookie" 相关错误，或 "环境变量没有配置"。
+   - **行动**：提示用户：“检测到未配置 Cookie，请在环境变量或脚本配置中设置 Cookie。”
+
+2. **Case: 会话过期**
+   - **特征**：输出中包含 "会话已过期"、"session expired" 或 "login required"。
+   - **行动**：提示用户：“当前会话已过期，请重新获取并配置 Cookie。”
+
+3. **Case: 表已存在**
+   - **特征**：输出中包含 "表已存在"、"already exists"。
+   - **行动**：告知用户导入完成，忽略该提示（这是正常现象）。
+
+4. **Case: 其他异常**
+   - **特征**：Python 报错、文件未找到等。
+   - **行动**：
+     - 如果是参数错误，自动修正参数并重试（如果可能）。
+     - 如果是脚本错误，输出完整错误栈，并尝试分析原因。
+
+## 示例对话
+
+**User:** `import-model-table 6aspecdoc/green/xxx/artifacts/domain-model.md 890601`
+
+**Assistant:**
+1. 解析 Application: `8906`
+2. 搜索 GUID: 在 `data/metadata/_metadata/8906/` 中搜索 `890601`...
+3. 找到 GUID: `12345678-1234-1234-1234-1234567890ab`
+4. 执行命令: `python .6aspec/script/create_entities_from_markdown.py 6aspecdoc/green/xxx/artifacts/domain-model.md -a 8906 -g 12345678-1234-1234-1234-1234567890ab`
+5. 反馈结果。
+
+## 流程完成提示 (Workflow Progress)
+
+**重要提示**：本节内容仅用于向用户输出流程进度提示，**不要写入任何文档文件**。
+
+当完成本 SOP 流程后，必须向用户输出以下流程进度提示：
+
+---
+
+✅ **已完成：表导入建模平台 (import-model-table) - 可选流程**
+
+📊 **进度：可选流程已完成**
+
+**下一步建议：**
+- 【主流程】技术方案设计：命令 `design`
+  继续主流程，基于领域模型设计接口、事件、定时任务等技术方案
+
+**完整流程图：**
+```
+主流程：领域建模 ✅ → 技术方案 → 任务生成 → 执行任务 (1/4)
+可选流程：表导入建模平台 ✅
+```
+
+---
+

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

@@ -0,0 +1,62 @@
+---
+description: 事件清单生成标准操作流程 (Event List Generation SOP)
+alwaysApply: false
+---
+
+# event-list: 事件清单生成标准操作流程 (Event List Generation SOP)
+
+## 1. 目标
+扫描全项目中带有 `com.mysoft.framework.event.annotation.Event` 注解的 Java 类，生成一份详细的事件清单文档 `.6aspec/biz/event-list.md`。
+
+## 2. 扫描与识别 (Scan & Identify)
+1.  **搜索范围**: 在整个 Workspace 中搜索引用了 `com.mysoft.framework.event.annotation.Event` 的 Java 文件。
+2.  **过滤条件**:
+    - 必须是类定义（Class definition）。
+    - 类必须被 `@Event` 注解标记。
+    - 忽略测试代码（`src/test` 目录下的文件）。
+3.  **模块归类**: 根据文件路径识别所属模块（例如 `yymh-ticket`, `yymh-portal` 等）。
+
+## 3. 元数据提取 (Metadata Extraction)
+对每个识别出的事件类，提取以下核心信息：
+1.  **基本信息**: 类名、包名、文件绝对路径。
+2.  **事件名称与描述**:
+    - 优先提取 `@Event` 注解中的 `name` 或 `description` 属性。
+    - 其次提取类的 JavaDoc 注释（第一行作为名称，后续作为描述）。
+    - 若均无，使用类名作为名称。
+3.  **继承关系**: 识别父类（如 `BaseEvent`, `BaseRentalEvent` 等）。
+4.  **字段分析**:
+    - 提取所有字段的名称和类型。
+    - **字段来源分析**: 区分字段是定义在当前类中，还是继承自父类。
+    - *注意*: 如果无法精确分析父类字段，将来源标记为父类类名。
+
+## 4. 格式化与输出 (Format & Output)
+1.  **目录检查**: 确保输出目录 `.6aspec/biz` 存在，不存在则创建。
+2.  **文档结构**:
+    - **Header**: 包含“项目事件清单”标题和统计信息（总事件数、模块数、扫描范围）。
+    - **TOC**: 按模块名生成的目录索引。
+    - **Content**: 按模块分组，详细列出每个事件的卡片。
+3.  **事件卡片模板**:
+
+```markdown
+### {ClassName}
+
+**事件名称**: {EventName}
+
+**事件描述**: {Description}
+
+**包名**: `{PackageName}`
+
+**继承关系**: 继承自 `{ParentClassName}`
+
+**事件体字段**:
+
+| 字段名 | 字段类型 | 字段来源 |
+|--------|----------|----------|
+| {fieldName} | {fieldType} | {sourceClass} |
+...
+
+**文件路径**: `{FilePath}`
+
+---
+```
+

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

@@ -0,0 +1,79 @@
+---
+description: 生成或更新项目功能能力地图 (Functional Capability Map) 的 SOP
+alwaysApply: false
+---
+# 生成或更新项目功能能力地图 (Functional Capability Map) 的 SOP
+
+## Aim (目标)
+生成一份精简、准确的面向 AI 设计者的《项目功能能力地图》，明确系统核心能力、数据资产与复用规则，辅助后续设计与开发。
+
+## Actor (执行者)
+- **角色**: 资深架构师 & 领域建模专家
+- **工具**: Cursor AI, codebase_search, read_file
+
+## Action (动作)
+执行以下步骤扫描源码并生成文档：
+
+1.  **识别 Facade 层 (Identify Facades)**:
+    -   扫描 `*-interfaces` 模块或 Controller 层。
+    -   提取所有以 `Facade` 结尾的接口或核心 `Controller`。
+    -   分析其核心方法 (Method)、入参 (Input) 及业务意图 (Intent)。
+
+2.  **映射数据模型 (Map Schema)**:
+    -   扫描 `*-service` 或 `*-model` 模块中的 `Entity` (DO) 或 `Repository`。
+    -   识别核心数据库表名（如 `@TableName` 注解）。
+    -   关联表与业务对象（如 `es_order` -> 订单聚合根）。
+
+3.  **沉淀复用逻辑 (Extract Logic)**:
+    -   基于代码引用关系，总结“在什么场景下必须调用此模块”。
+    -   提取模块间的依赖关系。
+
+4.  **定义架构红线 (Define Guardrails)**:
+    -   根据模块职责，明确“禁止做什么”和“必须做什么”。
+
+5.  **生成文档 (Generate Artifact)**:
+    -   输出到 `.6aspec/biz/functional-capability-Map.md`。
+    -   **格式要求**: 必须精简，移除通用废话，只保留核心干货。
+
+## Artifact (产物)
+**输出文件**: `.6aspec/biz/functional-capability-Map.md`
+**内容模板**:
+
+```markdown
+# 项目功能能力地图 (Functional Capability Map)
+> **版本**: [Version] | **更新时间**: [Date]
+
+## 📋 架构总览
+[简述核心模块划分]
+
+## 🧩 模块一：[模块名]
+### 核心能力 (Capabilities)
+- `[Facade/Controller名]`
+  - `[方法名]`: [解决的具体业务问题]
+
+### 数据资产 (Schema Mapping)
+| 表名 | 业务对象 | 说明 |
+|-----|---------|------|
+| [table_name] | [Entity] | [Description] |
+
+### 复用场景指引 (Integration Guide)
+- 场景：[描述] -> 请使用 `[接口名]`
+
+### 架构红线 (Guardrails)
+1. ❌ [禁止事项]
+2. ✅ [强制事项]
+
+[其他模块依此类推...]
+
+## 📊 模块间依赖关系
+[依赖树或描述]
+```
+
+## Authority (权限)
+- **读权限**: 全项目源码读取。
+- **写权限**: 仅限更新 `.6aspec/biz/functional-capability-Map.md`，禁止修改业务代码。
+
+## Audit (审计)
+- **完整性检查**: 确保核心业务模块（src目录下的所有模块）均已覆盖。
+- **精简性检查**: 确保无冗余的通用描述（如“使用建议”、“附录”等）。
+- **准确性检查**: 确保接口名和表名与源码一致。