6a-spec-install 1.0.1-dev.2 → 1.0.1-dev.20

package/.cursor/rules/6A/6A_model_sop.md

@@ -1,91 +0,0 @@
----
-description: 数据模型设计标准操作流程 (Data model design SOP)
-alwaysApply: false
----
-
-# 6A-model: 数据模型设计标准操作流程 (Data model design SOP)
-
-## 角色色
-你现在的角色是【领域架构师 + 数据建模专家】，负责在编写任何业务代码前，完成最核心的数据架构设计。你认为“数据模型是对业务本质的抽象”，因此你严控冗余，追求模型的高内聚与低耦合。
-
-## 目标
-- 基于 PRD 和已确认的领域模型，设计稳定、可演进的数据模型
-- 本阶段不允许设计接口、流程、事件、定时任务
-
-## 规则：
-1. 复用至上：必须严格检索 `./.cursor/rules/biz/functional-capability-Map.md`，任何能够利用现有表结构或现有模块（如基础数据、收缴、合同）承载的数据，严禁新设独立表
-2. **领域驱动**：先有领域对象（Domain Object）及其关系，再有物理数据库表（Physical Table）
-3. 若发现以下任一情况，必须中断并提问：
-    - 字段语义不清
-    - 是否复用已有表无法确认
-
-## 输入要求
-- **必需输入**：PRD（产品需求文档）或功能需求描述
-- **可选输入**：已确认的领域边界与核心实体语义(可以是markdown文档)
-- **系统自带知识库**：
-  - 现有能力地图:`./.cursor/rules/biz/functional-capability-Map.md`
-
-
-## 第一阶段：资产审计与策略定义 (Asset Audit)
-在进行具体建模前，请执行以下审计动作：
-- [ ] **资产对齐**：在《能力地图》中查找是否有相关联的业务领域。
-- [ ] **逻辑依赖**：识别新模型需要引用的外部主键（如 `contract_id`, `customer_id`）
-
-## 第二阶段：模型设计流程 (Design Process)
-
-### 第一步：资产映射分析表 (Asset Mapping)
-请按以下格式输出，证明你已深度思考复用性：
-
-| 业务实体 (Entity) | 存储策略 | 复用理由/冲突说明 | 涉及模块与表名 |
-| :--- | :--- | :--- | :--- |
-| (例：评价维度) | 现有模块复用 | 基础数据已有字典配置能力 | `rental-basicdata` |
-| (例：评价单) | 新建独立表 | 核心业务凭证，现有表无法承载 | `rental-customer` |
-
-### 第二步：领域模型设计 (Domain Modeling)
-1. 使用 Mermaid 语法绘制 **UML 类图 (Class Diagram)**
-- **要求**：展示实体（Entity）之间的关系（一对一、一对多、组合关系），实体的字段必须要有中文说明
-- **禁止内容**：不要在此阶段绘制任何 Flowchart（流程图）或 Sequence（时序图）
-
-
-### 第三步：数据库物理设计 (Physical Schema)
-根据领域模型，进行表设计，必须遵循以下格式规范：
-1. **命名与类型约束**：
-    - 表的命名规则：前缀{业务系统名}_{表名}
-    - 字段类型：主键，单行文本，多行文本，日期时间，整数，长整数，金额，面积，比率，汇率，附件，图片，唯一标识(关联外键的字段使用设个类型)
-    - 字段命名规则：
-      - 主键的命名：`{表名}+GUID`，主键的字段类型必须为：主键
-      - 字段名称必须是驼峰命名风格
-      - 如果字段类型是整型，并且表示状态，则必须说明状态值含义，并且字段的中文名称也加上说明，如：`状态：0-禁用,1-启用)`
-    - 禁止项：创建时间，更新时间，创建人，修改人，版本号这些字段
-2. 输出模板 (必须严格执行)
-A、标题：{序号}. {中文表名}({表英文名})
-B、表格展示：使用表格展示表的结构，表格的格式说明如下
-  - 第一行，第一列：固定值：表中文名称，第二列：表中文名称
-  - 第二行，第一列：固定值：表英文名称，第二列：表英文名称
-  - 第三行，第一列：固定值：说明，第二列：说明
-  - 第四行开始，第一列：字段中文名称，第二列：字段英文名称，第三列：字段类型，第四列：长度，第五列：是否必填(是、否)，第六列：字段说明
-
-## 表设计表格展示示例
-```
-##### 1. 服务评价单表 (rental_ServiceEvaluation)
-| 表中文名称 | 服务评价单表 |
-| :--- | :--- |
-| 表英文名称 | rental_ServiceEvaluation |
-| 说明 | 服务评价单主表，记录服务评价的完整信息 |
-
-| 字段中文名称 | 字段英文名称 | 字段类型 | 长度 | 是否必填 | 字段说明 |
-| :--- | :--- | :--- | :--- | :--- |
-| 服务评价单GUID | serviceEvaluationGUID | 唯一标识 | - | 是 | 主键 |
-| 服务评价单号 | serviceEvaluationNo | 单行文本 | 是 | 64 | 服务评价单编号，系统自动生成 |
-| 服务场景 | serviceScene | 单行文本 | 64 | 是 | 服务场景：预约带看、合同新签、入住办理、换房办理、退房办理、报事工单、报修工单、投诉工单、建议工单 |
-```
-
-## 输出要求：
-1. 格式：Markdown 源码格式
-2. 文档位置：`.docs/{功能名称}` 目录
-3. 文档命名：`MODEL_{功能名称}.md`
-4. 请务必检查下第三步的输出是否满足格式要求
-
-## 注意
-- 不要为了“完整”而臆造字段
-- 所有字段必须能在 PRD 中或者补充信息中找到业务来源

package/.cursor/rules/6A/6A_new_feature.md

@@ -1,255 +0,0 @@
----
-description: 新功能架构设计标准操作流程 (New Feature Architecture SOP)
-alwaysApply: false
----
-
-# 6A-new: 新功能架构设计标准操作流程 (New Feature Architecture SOP)
-
-## 工作流概述
-
-当触发 6A 工作流时，作为 Lead Engineer 和 Architect，需要按照以下步骤进行新功能的架构设计和技术设计文档（TDD）输出。
-
-## 输入要求
-
-- **必需输入**：PRD（产品需求文档）或功能需求描述
-- **可选输入**：业务流程图、UI 原型、现有类似功能参考
-
-## 设计流程
-
-### 第一步：需求分析 (Requirement Analysis)
-
-1. **理解业务需求**
-   - 明确功能目标和业务价值
-   - 识别核心业务流程
-   - 确定功能边界和范围
-
-2. **识别影响范围**
-   - 确定涉及的业务模块（如合同、客户、租控、收缴等）
-   - 识别需要修改的现有功能
-   - 识别需要新增的模块或组件
-
-3. **识别非功能性需求**
-   - 性能要求（响应时间、并发量）
-   - 数据量级（单次处理数据量、历史数据量）
-   - 安全要求（权限控制、数据加密）
-   - 可用性要求（容错、降级策略）
-
-### 第二步：架构设计 (Architecture Design)
-
-1. **模块划分**
-   - 根据项目结构规范，确定功能归属的业务模块
-   - 确定是否需要新建模块，或扩展现有模块
-   - 模块命名：`rental-{业务领域}`
-
-2. **分层设计**
-   - **interfaces 层**：定义 Facade 接口
-     - 接口命名：`{功能名}Facade`
-     - 包路径：`com.mysoft.rental.{业务领域}.interfaces`
-   - **service 层**：实现业务逻辑
-     - 实现类命名：`{功能名}FacadeImpl` 或 `{功能名}Service`
-     - 包路径：`com.mysoft.rental.{业务领域}.service`
-   - **model 层**：定义数据模型
-     - DTO/Command/Query/VO/Entity
-     - 包路径：`com.mysoft.rental.{业务领域}.model.{类型}`
-
-3. **数据模型设计**
-   - **DTO**：数据传输对象，用于接口层传输
-   - **Command**：命令对象，用于写操作
-   - **Query**：查询对象，用于读操作
-   - **VO**：视图对象，用于返回给前端
-   - **Entity**：实体对象，对应数据库表
-
-4. **Repository 层设计**
-   - Repository 命名：`{实体名}Repository`
-   - DAO 命名：`{实体名}Dao`
-   - Entity 命名：`{实体名}Entity`
-   - 包路径：`com.mysoft.rental.{业务领域}.repository`
-
-5. **Controller 层设计**
-   - Controller 命名：`{功能名}Controller`
-   - 包路径：按业务领域分类
-     - `controller.app`：应用端接口
-     - `controller.h5`：H5 端接口
-     - `controller.modeling.bizapi`：建模业务接口
-     - `controller.modeling.dataapi`：建模数据接口
-     - `controller.pub`：公共接口
-
-### 第三步：接口设计 (API Design)
-
-1. **接口定义**
-   - RESTful API 设计
-   - 接口路径规范：`/api/{版本}/{业务领域}/{功能}`
-   - HTTP 方法选择：GET（查询）、POST（创建/复杂查询）
-
-2. **参数设计**
-   - 使用 `@RequestBody` + DTO/Command/Query
-   - 使用 `@Valid`/`@Validated` 进行参数校验
-   - 简单参数使用 `@RequestParam`
-
-3. **返回值设计**
-   - 统一返回结构（如 `Result<T>`）
-   - 或直接返回 DTO/VO
-
-4. **异常设计**
-   - 定义业务异常枚举：`BusinessExceptionCodeEnums`
-   - 异常码分段规则：
-     - 62：合同组
-     - 65：收缴组
-     - 75：运营组
-     - 91：基础数据组
-   - 异常码格式：`{组号}{业务域}{序号}`
-
-### 第四步：数据库设计 (Database Design)
-
-1. **表结构设计**
-   - 表命名规范：`{业务前缀}_{表名}`
-   - 字段命名：小写下划线分隔
-   - 必须字段：`id`（UUID）、`create_time`、`update_time`、`creator_id`、`updater_id`
-
-2. **索引设计**
-   - 主键索引
-   - 业务查询索引
-   - 外键索引
-
-3. **数据迁移**
-   - 确定是否需要数据库迁移脚本
-   - 脚本位置：`data/sql/{数据库类型}/updatesql/`
-
-### 第五步：事件设计 (Event Design)
-
-1. **事件发布**
-   - 识别需要发布业务事件的场景
-   - 事件命名：`{业务动作}{业务对象}Event`
-   - 包路径：`com.mysoft.rental.{业务领域}.model.event`
-   - 发布位置：`com.mysoft.rental.{业务领域}.service.event.publisher`
-
-2. **事件订阅**
-   - 识别需要订阅的事件
-   - 订阅者命名：`{业务对象}{动作}Subscriber`
-   - 包路径：`com.mysoft.rental.{业务领域}.service.event.subscriber`
-
-### 第六步：扩展点设计 (Extension Point Design)
-
-1. **策略模式**
-   - 识别需要策略模式的场景
-   - 策略接口命名：`{业务}Strategy`
-   - 策略实现命名：`{具体策略}{业务}Strategy`
-
-2. **工厂模式**
-   - 策略工厂命名：`{业务}Factory`
-   - 使用注解 `@Extension` 标识扩展点
-
-### 第七步：技术选型 (Technology Selection)
-
-1. **框架和库**
-   - Spring Boot（已确定）
-   - MyBatis Plus（数据访问）
-   - Lombok（代码简化）
-
-2. **设计模式**
-   - Facade 模式（接口层）
-   - Strategy 模式（策略选择）
-   - Template 模式（模板方法）
-   - Factory 模式（对象创建）
-
-### 第八步：非功能性设计 (Non-Functional Design)
-
-1. **性能优化**
-   - 批量操作优化
-   - 缓存策略
-   - 数据库查询优化
-
-2. **事务管理**
-   - 确定需要事务的方法
-   - 使用 `@Transactional` 注解
-
-3. **权限控制**
-   - 接口权限注解
-   - 数据权限控制
-
-4. **日志记录**
-   - 关键操作日志
-   - 异常日志记录
-
-## TDD 文档模板
-
-### 1. 功能概述
-- 功能名称
-- 功能描述
-- 业务价值
-
-### 2. 需求分析
-- 功能需求
-- 非功能性需求
-- 约束条件
-
-### 3. 架构设计
-- 模块划分
-- 分层设计
-- 模块依赖关系图
-
-### 4. 接口设计
-- 接口列表
-- 接口详细设计（请求/响应）
-- 接口调用关系
-
-### 5. 数据模型设计
-- DTO/Command/Query/VO 设计
-- Entity 设计
-- 数据库表设计
-
-### 6. 业务流程设计
-- 核心业务流程
-- 异常流程处理
-- 状态流转图
-
-### 7. 技术实现
-- 关键技术点
-- 设计模式应用
-- 算法和数据结构
-
-### 8. 非功能性设计
-- 性能设计
-- 安全设计
-- 可扩展性设计
-
-### 9. 测试策略
-- 单元测试
-- 集成测试
-- 测试用例
-
-### 10. 风险评估
-- 技术风险
-- 业务风险
-- 应对措施
-
-## 输出要求
-
-1. **TDD 文档格式**：Markdown
-2. **文档位置**：项目根目录或 `.docs/` 目录
-3. **文档命名**：`TDD_{功能名称}.md`
-4. **必须包含**：以上所有章节
-5. **代码示例**：关键接口和类的伪代码或示例代码
-
-## 注意事项
-
-1. **严格遵循项目规范**
-   - 包结构规范
-   - 命名规范
-   - 代码风格规范
-
-2. **考虑现有代码**
-   - 复用现有组件
-   - 保持架构一致性
-   - 避免重复设计
-
-3. **可扩展性**
-   - 预留扩展点
-   - 考虑未来需求变化
-   - 保持接口稳定性
-
-4. **文档完整性**
-   - 所有设计决策都要有说明
-   - 关键设计要有图表
-   - 提供足够的实现指导
-

package/.cursor/rules/6A/6A_new_feature_sop.md

@@ -1,168 +0,0 @@
----
-description: 新功能架构设计标准操作流程 (New Feature Architecture SOP)
-alwaysApply: false
----
-
-# 6A-new: 新功能架构设计标准操作流程（精简版）
-
-你现在是资深架构师（Senior Architect），负责在**数据库模型已确定**的前提下，输出具备“编码指导意义”的**TDD 技术设计文档**，确保开发者（或 AI 编码助手）可按此方案无偏差实现业务。
-
-## 角色与目标
-- **角色**：资深架构师（Senior Architect）
-- **目标**：产出可直接指导实现的 TDD 文档（不依赖阅读 PRD 也能落地开发）
-- **强约束**：所有设计必须严格基于既定【领域模型与数据库表结构】
-
-## 核心原则（必须遵守）
-1. **先审计，后设计**：若需求/模型缺失关键要素，必须中断并给出提问清单
-2. **基于模型设计**：任何字段/状态/约束必须在模型中可承载，否则停止
-3. **拒绝前端与测试**：严禁涉及 UI、交互、样式、测试用例
-4. **接口规范性**：接口仅允许 **GET/POST**；URL **不使用路径变量**
-5. **按需设计（不为设计而设计）**：入口类型是“允许范围”，不是“必选项”。只对 PRD/模型明确涉及的入口做设计；未涉及的入口类型不要输出对应设计内容。
-6. **入口类型限制**：只允许以下入口（按需选择，非必需全包含）：
-   - 写操作 REST API（Command API）
-   - 定时任务（Scheduled Tasks）
-   - 事件订阅（Event Subscribers）
-   - 后台任务（Async Background Job）
-7. **禁止查询接口**：除非 PRD **逐条明确**：
-   - 接口名称
-   - 查询目的（支撑哪条业务决策）
-   - 不可由现有能力替代的原因  
-   否则 **禁止设计任何 Query/List/Detail/Search**
-
-## 输入要求（你必须先检查）
-你需要用户提供：
-- **必需输入 1**：PRD 文档或功能需求描述
-- **必需输入 2**：数据模型设计文档：`./.docs/{功能名称}/MODEL_{功能名称}.md`
-- **参考文档**：`./.cursor/rules/biz/functional-capability-Map.md`（能力地图）
-
-## 第一阶段：需求完备性检查（Gatekeeping，必须先做）
-请逐项核对并输出结论（Y/N）：
-- [ ] **数据闭环**：新功能涉及字段是否都能落在模型中？
-- [ ] **外部依赖**：是否需要调用其他模块 Facade？（参考能力地图）
-- [ ] **异常覆盖**：失败、超时、并发、幂等等关键逻辑是否明确？
-- [ ] **模型文档存在**：`./.docs/{功能名称}/MODEL_{功能名称}.md` 是否存在？
-
-**若任意一项为 N：立即停止输出 TDD，改为输出“提问清单”。**
-
-## 第二阶段：详细设计（按以下步骤输出）
-
-### 第一步：架构分层与模块设计（Logical Layering）
-识别领域功能并拆解，要求用表格输出：
-- **领域**
-- **领域功能**
-- **功能描述**
-- **规则约束**
-- **依赖的模块/Facade（来自能力地图）**
-
-### 第二步：接口与入口设计（Entrypoints Design）
-只允许设计：写 API / 定时任务 / 事件订阅 / 后台任务。
-
-补充约束（必须遵守）：
-- **只设计“本需求实际存在”的入口类型**：若 PRD 未提出、或业务链路中没有该触发方式，则不需要设计该入口类型。
-- **输出规则**：未涉及的入口类型在 TDD 中**不要为了完整性而补齐**；对应小结/表格应**直接省略**（不要输出空表）。
-
-#### 写操作 REST API（Command API）
-- 定义端点、方法（GET/POST）、核心入参/出参结构、幂等方案
-
-#### 定时任务（Scheduled Tasks）
-- 触发频率（Cron/间隔）
-- 幂等处理
-- 失败重试/补偿策略
-- 扫表量级与分页/分片方案（如有）
-
-#### 事件订阅（Event Subscribers）
-- 订阅事件必须来自系统已有事件清单：`./.cursor/rules/biz/event-list.md`
-- 必须同时写 **事件中文名 + 英文名**（如：自动出账提醒事件（AutoBillingRemindEvent））
-
-#### 后台任务（Async Background Job）
-**什么是后台任务**：这是我们系统定义的异步任务机制（可理解为“任务队列 + 消费者”，类似线程池异步执行），用于将耗时、可重试、需要异步执行的逻辑从主流程中剥离。
-
-你必须说明：
-- **投递时机**：由哪个入口触发投递（API/定时任务/事件订阅/其他后台任务）
-- **任务载荷**：建议只传业务主键 ID（或可复算的最小必要信息）
-- **幂等处理**：如何防止重复消费导致的重复写入/重复副作用
-- **失败重试/补偿策略**：重试次数/退避策略/死信或人工介入机制（如系统支持）
-- **数据量级**：是否批处理/是否需要分页拉取/是否会扫表
-
-## TDD 文档输出模板（必须严格按此结构产出）
-
-### 1. 功能概述
-- 目标与核心价值
-- 功能范围（Scope）
-
-### 2. 领域功能（表格）
-按“架构分层与模块设计”要求输出表格。
-
-### 3. 接口/入口规范
-不同类型的入口必须分开说明，分别输出为不同小结与不同表格，禁止混在同一张表中。
-同时，入口类型按需输出：**本需求未涉及的入口类型，小结/表格直接省略**（不要为了设计而设计）。
-
-#### 3.1 写操作 REST API（Command API）
-你必须输出“写 API 清单表格”，包含以下列（注意：边界/并发/性能不再单独成章，必须放进表格）：
-- **名称**
-- **URL**
-- **Method（仅 GET/POST）**
-- **执行逻辑**
-- **幂等设计**
-- **并发控制（如需要）**（锁/版本号/状态门禁/唯一约束等）
-- **边界与异常处理**（失败路径、超时、重复请求、数据不存在、状态不合法等）
-- **性能与数据量级考虑**（是否扫表、分页策略、批处理大小、索引/唯一约束依赖等）
-
-此外：
-- 若表格中包含 **任何查询接口**，但 PRD 未按“唯一例外”逐条授权，则该输出视为无效，你必须先停止并提示违规原因。 
-- API接口详细定义: 必须写到另一个文档中,命名规则：`TDD_{功能名称}_API_def.md`,必须提供链接
-- **入参/出参 JSON 结构**必须输出到文档：`.docs/{功能名称}/TDD_{功能名称}_API_def.md`，不要在 TDD 文档中输出
-
-#### 3.2 定时任务（Scheduled Tasks）
-你必须输出“定时任务清单表格”，包含以下列：
-- **任务名称**
-- **Trigger（Cron/间隔）**
-- **执行逻辑**
-- **幂等设计**
-- **并发控制（如需要）**
-- **边界与异常处理**
-- **性能与数据量级考虑**（是否扫表、分页/分片策略、批处理大小等）
-- **补偿/重试策略**
-
-#### 3.3 事件订阅（Event Subscribers）
-你必须输出“事件订阅清单表格”，包含以下列：
-- **订阅者名称**
-- **订阅事件（中文名 / 英文名）**（事件必须来自：`./.cursor/rules/biz/event-list.md`）
-- **执行逻辑**
-- **幂等设计**
-- **并发控制（如需要）**
-- **边界与异常处理**
-- **性能与数据量级考虑**
-- **补偿/重试策略（如适用）**
-
-#### 3.4 后台任务（Async Background Job）
-你必须输出“后台任务清单表格”，包含以下列：
-- **任务名称**
-- **投递来源/投递时机**（由哪个入口触发投递）
-- **任务载荷（Payload）**（建议业务主键 ID 或最小必要信息）
-- **执行逻辑**
-- **幂等设计**
-- **并发控制（如需要）**
-- **边界与异常处理**
-- **性能与数据量级考虑**
-- **补偿/重试策略（如适用）**
-
-### 4. 扩展点
-- **事件驱动**：
-  - 发布者：哪些写操作会触发事件
-  - 事件体：只发布业务主键 ID
-  - 订阅者：哪些后续动作需要异步响应
-- **可选扩展点设计**：识别可能变化的规则，建议策略模式/模板方法（只需描述）
-
-## 输出要求（硬性）
-1. **格式**：Markdown 源码
-2. **位置**：`.docs/{功能名称}/`
-3. **命名**：`TDD_{功能名称}.md`
-4. **API 详细定义**：`.docs/{功能名称}/TDD_{功能名称}_API_def.md`
-5. **解耦**：不包含具体项目包路径，用逻辑层（service/repository/facade）描述
-6. **禁止项（本版本已移除）**：
-   - 不输出：业务流程图 / 交互时序图 / 状态机图
-   - 不输出：可观测性、事务管理相关内容
-
-## 开始执行前（你需要向用户确认/索取）
-请先检查并确认用户已提供 PRD + `MODEL_{功能名称}.md`。若缺失或 Gatekeeping 任一项不满足，立即停止并输出“提问清单”，不要继续生成 TDD

package/.cursor/rules/6A/6A_task_sop.md

@@ -1,106 +0,0 @@
----
-description: 任务拆解标准操作流程 (Functional Entrypoint SOP)
-alwaysApply: false
----
-
-# 6A-task: 任务拆解标准操作流程 (Functional Entrypoint SOP)
-
-## 工作流概述
-
-当触发 6A-task 工作流时，AI 需作为 **Lead Engineer / Project Manager**，基于已生成的 `TDD_{功能名称}.md` 文档，将架构设计转化为以**入口点（API/事件/定时任务）**为核心的原子开发任务。
-
-## 核心原则
-1. **纵向拆解**：一个任务即一个完整的功能入口，包含其关联的枚举、 DTO、Service、Repository，gateway 等所有逻辑实现
-2. **职责完备**：在执行某个任务时，AI 应根据需要自动创建或修改涉及的模型与逻辑，而不是拆分成多个任务
-3. **规约驱动**：不同类型的任务必须显式指定对应的编码规约文件
-
-## 输入要求
-- **必需输入**：已完成的 `TDD_{功能名称}.md` 文档
-- **关联规约**：
-    - API 任务：`./cursor/biz/api_rule.md`
-    - 事件订阅任务：`./cursor/biz/event_subscriber_rule.md`
-    - 定时任务任务：`./cursor/biz/scheduled_task_rule.md`
-    - 后台任务任务：`./cursor/biz/background_job_rule.md`
-
-## 第一阶段：任务分类与规则映射
-
-在拆解时，AI 必须识别 TDD 中的功能点属于哪种类型，并分配对应的规约文件：
-
-| 任务类型 | 识别特征 | 关联规约文件 |
-| :--- | :--- | :--- |
-| **API 任务** | TDD 中的 RESTful API 设计、Controller 接口 | `./cursor/biz/api_rule.md` |
-| **事件订阅任务** | TDD 中的事件订阅 (Subscriber)、异步消息处理 | `./cursor/biz/event_subscriber_rule.md` |
-| **定时任务任务** | TDD 中的定时任务 (Scheduled Task)、Cron 任务 | `./cursor/biz/scheduled_task_rule.md` |
-| **后台任务任务** | TDD 中的后台任务（Async Background Job）、需要异步执行的任务 | `./cursor/biz/background_job_rule.md` |
-
-## 第二阶段：输出规范
-
-### 1. 目录结构
-所有任务文件必须存储在以下路径：
-- `.docs/{功能名称}/task/`
-
-### 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 小时
-- 工时的评估以一个5年高级开发的标准进行评估
-
-### 3. 业务规则与实现细节
-- **核心逻辑**：基于 TDD 中的“执行逻辑”描述，详细说明 Service 层及领域层需处理的规则（如存在对应的可视化文档 `TDD_{功能名称}_Visual.md`，可作为辅助参考，但不得脱离 TDD 自行补充规则）。
-- **状态流转**：若涉及状态变更，明确状态机逻辑。
-- **数据结构**：涉及的 DTO、Command、Query 的定义要求。
-- **异常处理**：需捕获并抛出的业务异常类型。
-
-### 4. 跨模块依赖调用
-- 明确需要调用哪些已有模块的 Facade 或 RMI 接口
-- 描述依赖的数据来源或前置条件
-
-### 5. 必须参考的编码规则
-- **本任务类型**：[API / 事件订阅 / 定时任务 / 后台任务]
-- **规则文件**：[此处填入对应的 .md 规则路径]
-- **编码公共规则文件**：`.cursor/rules/biz/code.md`和`.cursor/rules/biz/project-structure.md`
-- **执行说明**：在执行本任务代码生成时，必须严格遵守该规则文件中的代码分层、命名及注释规范
-- API接口必须识别是C端(小程序端)还是B端(PC端和APP端)
-
-### 6. 验收标准 (DoD)
-- [ ] 对应的接口/订阅者/定时器已成功创建。
-- [ ] 内部逻辑（Service/Repository）完整实现且符合业务预期。
-- [ ] 满足规约文件中的所有强制性要求
-```
-
-## 第三阶段：拆解执行步骤
-1. 扫描入口点：从 TDD 文档中提取所有“接口设计”、“事件设计”和“定时任务设计”中的条目
-2. 合并依赖项：将该入口点涉及的所有业务逻辑（Service）、数据访问（Repository）、模型定义（DTO/VO/Enum）全部归入该入口点的原子任务中
-3. 排除基础设施：严禁拆解数据库建表 (SQL) 和 Java Entity 映射任务。默认 Entity 已由人工基于 SQL 准备好
-4. 生成文件：为每个识别出的入口点生成独立的任务 Markdown 文件
-5. 生成总览：任务拆解完成后，必须在 `.docs/{功能名称}/task/README.md` 输出任务总览（见“输出要求”）
-6. 状态维护（必须执行）：后续每当完成一个任务，必须同步更新：
-   - 对应任务文件中的“任务状态”（至少更新状态与最后更新时间）
-   - `.docs/{功能名称}/task/README.md` 中该任务的状态展示（确保总览与任务文件一致）
-
-## 输出要求
-1. 格式：Markdown 源码格式。
-2. 一致性：任务中的类名、方法名和字段名必须与 TDD 保持完全一致。
-3. 禁用范围：不拆解前端任务、不拆解单纯的单元测试任务、不拆解 Entity/SQL 任务
-4. 总览 README（必须输出）：在 `.docs/{功能名称}/task/README.md` 生成任务总览文件，必须包含：
-   - 任务总工时与每个任务工时（单位：小时）
-   - 任务清单与功能描述（按任务文件链接列出，必须包含任务状态字段）
-   - 开发顺序建议（必须拆为 4 个阶段，并将任务归类到阶段内）
-   - 验收标准说明（从各任务 DoD 汇总，形成整体 DoD）
-   - 注意事项与相关文档链接（至少包含：TDD、API_def、如存在则包含 Visual 文档链接）