6a-spec-install 1.0.1-dev.13 → 1.0.1-dev.17

package/.cursor/commands/6A-execute-task.md

@@ -0,0 +1,21 @@
+---
+description: 6A-code: 执行开发任务 (Execute Task)
+alwaysApply: false
+---
+
+# 执行开发任务指令
+
+该指令用于触发标准化的代码实现流程。
+
+## 触发动作
+当用户提供一个任务文件路径（如 `@task_01_api_xxx.md`）并要求“执行任务”时：
+
+1.  **激活角色**：切换至 `Senior Developer` 角色。
+2.  **调用 SOP**：严格遵循 `.cursor/rules/6A/6A_code_implementation_sop.md` 中的协议。
+    - **Step 0**: 上下文加载 (Task + TDD + Rules)
+    - **Step 1**: 自底向上编码 (DTO -> Repo -> Service -> API)
+    - **Step 2**: 质量检查 (Lint)
+    - **Step 3**: 状态更新 (Task File + README)
+
+## 快捷指令参数
+用户可以直接输入：`6A-exec @task_file`

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

@@ -0,0 +1,65 @@
+---
+description: 任务代码实现标准操作流程 (Code Implementation SOP)
+alwaysApply: false
+---
+
+# 6A-code: 任务代码实现标准操作流程
+
+你现在是 **Senior Developer**，负责执行具体的开发任务。你的核心职责是将 `.docs/.../task/task_xxx.md` 转化为高质量、可运行的业务代码。
+
+## 0. 执行协议 (Protocol) - 拒绝盲目编码
+
+在开始编写代码前，**必须**执行以下上下文加载步骤（Context Loading）：
+
+1.  **加载任务上下文**：读取用户指定的 `task_xxx.md` 文件。
+2.  **加载设计上下文**：
+    *   必须寻找并读取该任务所属功能的 **TDD 主文档** (`TDD_{功能名称}.md`)。
+    *   必须读取 **API 定义文档** (`TDD_{功能名称}_API_def.md`)（如果是 API 任务）。
+    *   *Rationale*: 任务文件中只包含摘要，核心逻辑和 JSON 结构都在 TDD 中，不读 TDD 必写错。
+3.  **加载规范上下文**：
+    *   读取任务文件中指定的“规则文件”（如 `api_rule.md`）。
+    *   读取公共代码规约 `.cursor/rules/biz/code.md` 和 `.cursor/rules/biz/project-structure.md`。
+
+## 1. 实现策略 (Implementation Strategy)
+
+请严格按照 **自底向上 (Bottom-Up)** 的顺序进行编码，以减少依赖错误：
+
+### Step 1: 领域对象与数据传输对象 (DTO/VO/Enum)
+- 优先定义 Request/Response DTO、Enums、Events。
+- **约束**：字段名称和类型必须严格匹配 `API_def.md` 和 TDD 文档。
+
+### Step 2: 基础设施层 (Repository/Gateway)
+- 检查所需的 Repository 接口是否存在。
+- 如果需要调用外部服务，实现对应的 Facade/Gateway。
+
+### Step 3: 核心业务逻辑 (Service/Domain)
+- 实现 Service 方法。
+- **关键**：严格翻译 TDD 中的“执行逻辑”和“核心技术决策”。
+    - 如果 TDD 说要加锁，必须加锁。
+    - 如果 TDD 说要抛特定异常，必须抛出。
+
+### 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.  **更新总览文件** (`task/README.md`)：
+    - 寻找该任务在列表中的行，将状态图标改为 ✅。
+    - 更新进度条和已完成工时统计。
+
+## 异常处理
+- 如果发现 TDD 设计在代码层面无法实现（如循环依赖、TDD 参数缺失），**停止编码**，向用户报告并建议修改 TDD。
+

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

@@ -28,6 +28,7 @@ alwaysApply: false
 - **可选输入**：已确认的领域边界与核心实体语义(可以是markdown文档)
 - **系统自带知识库**：
     - 现有能力地图:`./.6A-spec/biz/functional-capability-Map.md`
+    - **C端用户体系规范**:`./.cursor/rules/biz/c_user_system_rule.md` (仅在涉及C端用户/门户/小程序相关设计时**必需**读取)
 
 
 ## 第一阶段：资产审计与策略定义 (Asset Audit)
@@ -46,9 +47,24 @@ alwaysApply: false
 | (例：评价单) | 新建独立表 | 核心业务凭证，现有表无法承载 | `rental-customer` |
 
 ### 第二步：领域模型设计 (Domain Modeling)
-1. 使用 Mermaid 语法绘制 **UML 类图 (Class Diagram)**
-- **要求**：展示实体（Entity）之间的关系（一对一、一对多、组合关系），实体的字段必须要有中文说明
-- **禁止内容**：不要在此阶段绘制任何 Flowchart（流程图）或 Sequence（时序图）
+
+1. **核心领域对象说明 (Domain Object Definitions)**
+   需识别并解释核心领域名词（聚合根、实体、值对象），按如下表格输出：
+   | 领域对象 | 类型 | 业务含义与职责 | 生命周期描述 |
+   | :--- | :--- | :--- | :--- |
+   | (例：评价单) | 聚合根 | 记录客户对服务的评价内容 | 创建 -> 待评价 -> 已评价 -> 归档 |
+   | (例：评价维度) | 值对象 | 定义评价的具体切面（如响应速度） | 随评价配置创建，不可变 |
+
+2. **领域事件设计 (Domain Events)**
+   识别领域状态变更产生的关键业务事件：
+   | 事件名称 | 触发条件 | 携带关键数据 | 消费方示例 |
+   | :--- | :--- | :--- | :--- |
+   | (例：评价已提交) | 用户完成表单提交并落库 | 评价单ID, 评分, 评价时间 | 积分系统, 消息通知 |
+
+3. **UML 类图 (Class Diagram)**
+   使用 Mermaid 语法绘制：
+   - **要求**：展示实体（Entity）之间的关系（一对一、一对多、组合关系），实体的字段必须要有中文说明
+   - **禁止内容**：不要在此阶段绘制任何 Flowchart（流程图）或 Sequence（时序图）
 
 
 ### 第三步：数据库物理设计 (Physical Schema)
@@ -87,9 +103,9 @@ alwaysApply: false
 - 第一行，第一列：固定值：表中文名称，第二列：表中文名称
 - 第二行，第一列：固定值：表英文名称，第二列：表英文名称
 - 第三行，第一列：固定值：说明，第二列：说明
-- 第四行开始，第一列：字段中文名称，第二列：字段英文名称，第三列：字段类型，第四列：长度，第五列：是否必填(是、否)，第六列：字段说明
+- 第四行开始，第一列：字段中文名称，第二列：字段英文名称，第三列：字段类型，第四列：长度，第五列：是否必填(是、否)，第六列：字段说明，第七列：业务来源
 
-## 表设计表格展示示例
+#### 表设计表格展示示例
 ```
 ##### 1. 服务评价单表 (rental_ServiceEvaluation)
 | 表中文名称 | 服务评价单表 |
@@ -97,13 +113,21 @@ alwaysApply: false
 | 表英文名称 | rental_ServiceEvaluation |
 | 说明 | 服务评价单主表，记录服务评价的完整信息 |
 
-| 字段中文名称 | 字段英文名称 | 字段类型 | 长度 | 是否必填 | 字段说明 |
-| :--- | :--- | :--- | :--- | :--- |
-| 服务评价单GUID | serviceEvaluationGUID | 唯一标识 | - | 是 | 主键 |
-| 服务评价单号 | serviceEvaluationNo | 单行文本 | 是 | 64 | 服务评价单编号，系统自动生成 |
-| 服务场景 | serviceScene | 单行文本 | 64 | 是 | 服务场景：预约带看、合同新签、入住办理、换房办理、退房办理、报事工单、报修工单、投诉工单、建议工单 |
+| 字段中文名称 | 字段英文名称 | 字段类型 | 长度 | 是否必填 | 字段说明 | 业务来源 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| 服务评价单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. 文档位置：`.docs/{功能名称}` 目录
@@ -111,5 +135,5 @@ alwaysApply: false
 4. 请务必检查下第三步的输出是否满足格式要求
 
 ## 注意
-- 不要为了“完整”而臆造字段
-- 所有字段必须能在 PRD 中或者补充信息中找到业务来源
+- **严格溯源**：所有字段必须有明确的业务来源（PRD章节、补充需求文档或业界通用标准），并在“业务来源”列中明确标注，严禁“为了完整”而臆造字段。
+- **一致性**：表格中的说明必须与 PRD 描述保持一致。

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

@@ -12,6 +12,27 @@ alwaysApply: false
 - **目标**：产出可直接指导实现的 TDD 文档（不依赖阅读 PRD 也能落地开发）
 - **强约束**：所有设计必须严格基于既定【领域模型与数据库表结构】
 
+## 0. 执行协议 (Protocol) - 必须遵守
+
+你不仅是一个文档生成器，更是一个**主动型架构师**。在收到需求后，不要立即生成 TDD，请严格按照以下步骤执行：
+
+1.  **主动检索 (Active Retrieval)**：
+    *   不要被动等待。当用户给出功能名称时，优先使用工具（`file_search` 或 `read_file`）尝试读取以下关键文件：
+        *   `./.docs/{功能名称}/MODEL_{功能名称}.md`
+        *   `./.6A-spec/biz/functional-capability-Map.md` (能力地图)
+        *   `./.6A-spec/biz/event-list.md` (事件清单，如涉及事件)
+    *   只有当无法读取这些文件时，才请求用户提供。
+
+2.  **思维链门禁 (Chain of Thought Gatekeeping)**：
+    *   在回复正文前，**必须**先输出一个 `<thinking>` 块。
+    *   在块内执行【第一阶段：需求完备性检查】，逐条验证输入完备性。
+    *   **决策**：若检查不通过，立即停止生成 TDD，输出 Markdown 列表告知缺失内容。
+
+3.  **双文档交付 (Dual Output)**：
+    *   检查通过后，在同一个回复中，使用两个**带有文件路径**的独立代码块分别输出：
+        *   代码块 1：`TDD_{功能名称}.md` (设计主文档)
+        *   代码块 2：`TDD_{功能名称}_API_def.md` (API 详细定义)
+
 ## 核心原则（必须遵守）
 1. **先审计，后设计**：若需求/模型缺失关键要素，必须中断并给出提问清单
 2. **基于模型设计**：任何字段/状态/约束必须在模型中可承载，否则停止
@@ -30,12 +51,13 @@ alwaysApply: false
    否则 **禁止设计任何 Query/List/Detail/Search**
 
 ## 输入要求（你必须先检查）
-你需要用户提供：
-- **必需输入 1**：PRD 文档或功能需求描述
+你需要确保拥有以下输入（优先尝试主动读取）：
+- **必需输入 1**：PRD 文档或功能需求描述（通常由用户在对话中提供）
 - **必需输入 2**：数据模型设计文档：`./.docs/{功能名称}/MODEL_{功能名称}.md`
 - **参考文档**：`./.6A-spec/biz/functional-capability-Map.md`（能力地图）
 
 ## 第一阶段：需求完备性检查（Gatekeeping，必须先做）
+**请在 `<thinking>` 块中执行此步骤。**
 请逐项核对并输出结论（Y/N）：
 - [ ] **数据闭环**：新功能涉及字段是否都能落在模型中？
 - [ ] **外部依赖**：是否需要调用其他模块 Facade？（参考能力地图）
@@ -57,32 +79,33 @@ alwaysApply: false
 ### 第二步：接口与入口设计（Entrypoints Design）
 只允许设计：写 API / 定时任务 / 事件订阅 / 后台任务。
 
-补充约束（必须遵守）：
-- **只设计“本需求实际存在”的入口类型**：若 PRD 未提出、或业务链路中没有该触发方式，则不需要设计该入口类型。
-- **输出规则**：未涉及的入口类型在 TDD 中**不要为了完整性而补齐**；对应小结/表格应**直接省略**（不要输出空表）。
+**补充约束（必须遵守）：**
+- **只设计“本需求实际存在”的入口类型**。
+- **输出规则**：未涉及的入口类型在 TDD 中**不要为了完整性而补齐**；对应小结/表格应**直接省略**。
+
+#### 设计表格填写范例（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/间隔）
-- 幂等处理
-- 失败重试/补偿策略
-- 扫表量级与分页/分片方案（如有）
+- 触发频率（Cron/间隔）、幂等处理、失败重试、扫表量级
 
 #### 事件订阅（Event Subscribers）
 - 订阅事件必须来自系统已有事件清单：`./.6A-spec/biz/event-list.md`
-- 必须同时写 **事件中文名 + 英文名**（如：自动出账提醒事件（AutoBillingRemindEvent））
+- 必须同时写 **事件中文名 + 英文名**
 
 #### 后台任务（Async Background Job）
-**什么是后台任务**：这是我们系统定义的异步任务机制（可理解为“任务队列 + 消费者”，类似线程池异步执行），用于将耗时、可重试、需要异步执行的逻辑从主流程中剥离。
-
-你必须说明：
-- **投递时机**：由哪个入口触发投递（API/定时任务/事件订阅/其他后台任务）
-- **任务载荷**：建议只传业务主键 ID（或可复算的最小必要信息）
-- **幂等处理**：如何防止重复消费导致的重复写入/重复副作用
-- **失败重试/补偿策略**：重试次数/退避策略/死信或人工介入机制（如系统支持）
-- **数据量级**：是否批处理/是否需要分页拉取/是否会扫表
+**什么是后台任务**：系统定义的异步任务机制（任务队列 + 消费者），用于将耗时、可重试逻辑剥离。
+你必须说明：投递时机、任务载荷（仅 ID）、幂等处理、失败重试、数据量级。
 
 ## TDD 文档输出模板（必须严格按此结构产出）
 
@@ -90,79 +113,57 @@ alwaysApply: false
 - 目标与核心价值
 - 功能范围（Scope）
 
+### 1.5 核心技术决策与权衡 (Key Technical Decisions)
+**必须输出此章节**。你必须解释“为什么”采用某些关键技术手段，特别是针对幂等、并发和性能的设计。
+请使用表格形式：
+| 决策点 | 选定方案 | 决策依据 (Rationale) & 备选方案弃用理由 |
+| :--- | :--- | :--- |
+| (例如) 库存扣减防超卖 | 数据库行锁 (Pessimistic Lock) | **理由**：业务一致性要求极高，允许牺牲少量吞吐量。<br>**弃用 Redis**：因无法保证 Redis 与 DB 的强事务一致性，且库存非热点数据。 |
+| (例如) 异步通知重试 | 指数退避 + 死信队列 | **理由**：下游服务可能短时不可用，避免流量风暴。 |
+
 ### 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 文档中输出
+你必须输出“写 API 清单表格”，包含：**名称、URL、Method、执行逻辑、幂等设计、并发控制、边界与异常处理、性能与数据量级考虑**。
+
+*注意：*
+- 若表格包含 **查询接口** 且未获授权，视为违规。
+- **入参/出参 JSON 结构**必须输出到 API 定义文档，不要在 TDD 主文档中输出。
 
 #### 3.2 定时任务（Scheduled Tasks）
-你必须输出“定时任务清单表格”，包含以下列：
-- **任务名称**
-- **Trigger（Cron/间隔）**
-- **执行逻辑**
-- **幂等设计**
-- **并发控制（如需要）**
-- **边界与异常处理**
-- **性能与数据量级考虑**（是否扫表、分页/分片策略、批处理大小等）
-- **补偿/重试策略**
+输出“定时任务清单表格”，包含：**任务名称、Trigger、执行逻辑、幂等设计、并发控制、边界与异常、性能考虑、补偿/重试策略**。
 
 #### 3.3 事件订阅（Event Subscribers）
-你必须输出“事件订阅清单表格”，包含以下列：
-- **订阅者名称**
-- **订阅事件（中文名 / 英文名）**（事件必须来自：`./.6A-spec/biz/event-list.md`）
-- **执行逻辑**
-- **幂等设计**
-- **并发控制（如需要）**
-- **边界与异常处理**
-- **性能与数据量级考虑**
-- **补偿/重试策略（如适用）**
+输出“事件订阅清单表格”，包含：**订阅者名称、订阅事件（中+英）、执行逻辑、幂等设计、并发控制、边界与异常、性能考虑、补偿/重试**。
 
 #### 3.4 后台任务（Async Background Job）
-你必须输出“后台任务清单表格”，包含以下列：
-- **任务名称**
-- **投递来源/投递时机**（由哪个入口触发投递）
-- **任务载荷（Payload）**（建议业务主键 ID 或最小必要信息）
-- **执行逻辑**
-- **幂等设计**
-- **并发控制（如需要）**
-- **边界与异常处理**
-- **性能与数据量级考虑**
-- **补偿/重试策略（如适用）**
+输出“后台任务清单表格”，包含：**任务名称、投递来源/时机、任务载荷、执行逻辑、幂等设计、并发控制、边界与异常、性能考虑、补偿/重试**。
 
 ### 4. 扩展点
-- **事件驱动**：
-  - 发布者：哪些写操作会触发事件
-  - 事件体：只发布业务主键 ID
-  - 订阅者：哪些后续动作需要异步响应
-- **可选扩展点设计**：识别可能变化的规则，建议策略模式/模板方法（只需描述）
+- **事件驱动**：发布者、事件体（仅 ID）、订阅者
+- **可选扩展点设计**：策略模式/模板方法建议
 
 ## 输出要求（硬性）
-1. **格式**：Markdown 源码
+1. **格式**：Markdown 源码，使用代码块包裹。
 2. **位置**：`.docs/{功能名称}/`
-3. **命名**：`TDD_{功能名称}.md`
-4. **API 详细定义**：`.docs/{功能名称}/TDD_{功能名称}_API_def.md`
-5. **解耦**：不包含具体项目包路径，用逻辑层（service/repository/facade）描述
-6. **禁止项（本版本已移除）**：
-   - 不输出：业务流程图 / 交互时序图 / 状态机图
-   - 不输出：可观测性、事务管理相关内容
-
-## 开始执行前（你需要向用户确认/索取）
-请先检查并确认用户已提供 PRD + `MODEL_{功能名称}.md`。若缺失或 Gatekeeping 任一项不满足，立即停止并输出“提问清单”，不要继续生成 TDD
+3. **交付物格式**：
+   请严格按照以下格式在一次回复中输出两个代码块：
+
+   这里是 TDD 设计文档：
+   ```markdown:.docs/{功能名称}/TDD_{功能名称}.md
+   (TDD 文档内容...)
+   ```
+
+   这里是 API 详细定义：
+   ```markdown:.docs/{功能名称}/TDD_{功能名称}_API_def.md
+   (API 定义内容，包含详细 JSON 结构...)
+   ```
+4. **解耦**：不包含具体项目包路径，用逻辑层（service/repository/facade）描述
+5. **禁止项**：不输出业务流程图/时序图/状态机图/可观测性/事务管理。
+
+## 开始执行前
+请先**主动检查**是否可读取 `MODEL_{功能名称}.md`。若文件不存在或内容缺失，立即停止并输出“提问清单”。

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

@@ -9,6 +9,24 @@ alwaysApply: false
 
 当触发 6A-task 工作流时，AI 需作为 **Lead Engineer / Project Manager**，基于已生成的 `TDD_{功能名称}.md` 文档，将架构设计转化为以**入口点（API/事件/定时任务）**为核心的原子开发任务。
 
+## 0. 执行协议 (Protocol) - 必须遵守
+
+你是一个**技术项目经理 (TPM)**。在执行任务拆解前，请严格遵守：
+
+1.  **主动检索 (Active Retrieval)**：
+    *   当用户指定 `{功能名称}` 时，优先尝试读取 `.docs/{功能名称}/TDD_{功能名称}.md`。
+    *   如果找不到 TDD 文档，**立即停止**并报错，提示用户先完成 TDD 设计。
+
+2.  **思维链门禁 (Chain of Thought Gatekeeping)**：
+    *   在输出任务列表前，**必须**先输出 `<thinking>` 块。
+    *   **Check**: TDD 是否包含清晰的“接口列表”、“定时任务列表”、“事件订阅列表”？
+    *   **Check**: 所有的入口点是否都有对应的“执行逻辑”描述？
+    *   **Decision**: 若 TDD 内容严重缺失（如只有标题无逻辑），拒绝拆解，要求用户先完善 TDD。
+
+3.  **依赖分析 (Dependency Analysis)**：
+    *   在 `<thinking>` 块中，分析任务间的依赖关系（例如：退款任务依赖于支付查询接口）。
+    *   基于依赖关系生成合理的**开发顺序**，而不是简单的线性排列。
+
 ## 核心原则
 1. **纵向拆解**：一个任务即一个完整的功能入口，包含其关联的枚举、 DTO、Service、Repository，gateway 等所有逻辑实现
 2. **职责完备**：在执行某个任务时，AI 应根据需要自动创建或修改涉及的模型与逻辑，而不是拆分成多个任务
@@ -59,10 +77,19 @@ alwaysApply: false
 
 ### 2. 预计工时（小时）
 - 预计：X 小时
-- 工时的评估以一个5年高级开发的标准进行评估
+- **评估基准 (Baseline)**：
+    - 简单 CRUD 接口：0.5 - 1h
+    - 带简单业务逻辑（校验/状态变更）：1 - 2h
+    - 复杂逻辑（外部调用/并发锁/事务）：3 - 5h
+    - 极高复杂度（核心金融链路）：5h+
+
+### 2.5 任务依赖与前置条件 (Dependencies)
+- **前置任务**：[Task-001 / 无] (必须先完成的任务)
+- **依赖模块**：[UserFacade / PaymentService] (需调用的外部依赖)
 
 ### 3. 业务规则与实现细节
 - **核心逻辑**：基于 TDD 中的“执行逻辑”描述，详细说明 Service 层及领域层需处理的规则（如存在对应的可视化文档 `TDD_{功能名称}_Visual.md`，可作为辅助参考，但不得脱离 TDD 自行补充规则）。
+- **核心技术决策**：回顾 TDD 中的关键决策（如幂等方案），再次确认落实。
 - **状态流转**：若涉及状态变更，明确状态机逻辑。
 - **数据结构**：涉及的 DTO、Command、Query 的定义要求。
 - **异常处理**：需捕获并抛出的业务异常类型。
@@ -76,31 +103,31 @@ alwaysApply: false
 - **规则文件**：[此处填入对应的 .md 规则路径]
 - **编码公共规则文件**：`.cursor/rules/biz/code.md`和`.cursor/rules/biz/project-structure.md`
 - **执行说明**：在执行本任务代码生成时，必须严格遵守该规则文件中的代码分层、命名及注释规范
-- API接口必须识别是C端(小程序端)还是B端(PC端和APP端)
+- **C/B 端标识**：API 接口必须识别是 C 端(小程序端)还是 B 端(PC 端和 APP 端)
 
 ### 6. 验收标准 (DoD)
 - [ ] 对应的接口/订阅者/定时器已成功创建。
 - [ ] 内部逻辑（Service/Repository）完整实现且符合业务预期。
-- [ ] 满足规约文件中的所有强制性要求
+- [ ] 幂等性与并发控制已按 TDD 要求实现。
+- [ ] 满足规约文件中的所有强制性要求。
 ```
 
 ## 第三阶段：拆解执行步骤
-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. **扫描入口点**：从 TDD 文档中提取所有“接口设计”、“事件设计”、“定时任务”和“后台任务”中的条目。
+2. **合并依赖项**：将该入口点涉及的所有业务逻辑（Service）、数据访问（Repository）、模型定义（DTO/VO/Enum）全部归入该入口点的原子任务中。
+3. **排序与编排**：基于`<thinking>`中的依赖分析，对任务进行逻辑排序（先基础后上层，先前置后依赖）。
+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 文档链接）
+1. **格式**：Markdown 源码格式。
+2. **一致性**：任务中的类名、方法名和字段名必须与 TDD 保持完全一致。
+3. **禁用范围**：不拆解前端任务、不拆解单纯的单元测试任务、不拆解 Entity/SQL 任务。
+4. **总览 README（必须输出）**：在 `.docs/{功能名称}/task/README.md` 生成任务总览文件，必须包含：
+   - **项目进度看板**：任务总工时、已完成工时、进度条。
+   - **任务清单**：按推荐执行顺序排列，包含状态图标 (✅/🔄/⏳)。
+   - **开发阶段划分**：建议将任务划分为 Phase 1 (Core), Phase 2 (Extensions) 等阶段。
+   - **验收标准汇总**：从各任务 DoD 汇总，形成整体 DoD。

package/.cursor/rules/biz/c_user_system_rule.md

@@ -0,0 +1,240 @@
+---
+description: C端用户体系规范
+alwaysApply: false
+---
+
+# C端用户体系规范
+
+## 概述
+
+本规范定义了系统中C端用户体系的设计标准，包括用户表结构、认证机制、身份类型、数据关联规范等。
+
+**适用范围**：所有面向C端用户的门户应用，主要依赖微信小程序。
+
+---
+
+## 一、核心表结构
+
+### 1.1 C端用户中心表（mdm_mycuser）
+
+**表说明**：C端用户中心的核心表，存储所有C端用户的基础信息。
+
+**使用场景**：
+- 用户在小程序登录后会自动生成一条用户记录
+- 存储用户基础信息和手机号
+- 未认证用户的业务关联直接使用此表
+
+**关键字段**：
+- 用户ID（主键）
+- 手机号：用户授权后的实名认证手机号
+- 创建时间：用户首次登录时间
+- 其他用户基础信息字段
+
+**使用原则**：
+- ✅ 查询所有C端用户（包括未认证用户）
+- ✅ 未认证用户的业务数据关联
+- ✅ 用户基础信息的存储和查询
+- ❌ 不应直接在此表存储业务相关字段
+
+---
+
+### 1.2 门户用户表（nr_tocuser）
+
+**表说明**：门户管理应用中的用户表，与 `mdm_mycuser` 一一对应（历史遗留原因）。
+
+**使用场景**：
+- 经过认证的用户业务关联
+- 门户业务相关的用户扩展信息
+- 用户身份信息的存储
+
+**关键字段**：
+- 用户ID（主键）
+- 关联的 mdm_mycuser 用户ID（外键）
+- 身份类型
+- 认证状态
+- 其他门户业务相关字段
+
+**使用原则**：
+- ✅ 已认证用户的业务数据关联（推荐使用此表）
+- ✅ 门户业务相关的用户扩展信息
+- ✅ 用户身份和权限相关的查询
+- ❌ 不应用于未认证用户的关联
+
+---
+
+### 1.3 表关系说明
+
+```
+┌─────────────────┐         一对一关系         ┌─────────────────┐
+│  mdm_mycuser    │ ─────────────────────────> │   nr_tocuser    │
+│  (C端用户中心)   │                            │   (门户用户)     │
+└─────────────────┘                            └─────────────────┘
+      ↑                                                ↑
+      │                                                │
+      │                                                │
+未认证用户关联                                    已认证用户关联
+```
+
+**说明**：
+1. 每个 `nr_tocuser` 记录对应一个 `mdm_mycuser` 记录
+2. `mdm_mycuser` 记录不一定有对应的 `nr_tocuser` 记录（未认证用户）
+3. 这是历史遗留的表结构设计，需要理解并正确使用
+
+---
+
+## 二、用户身份体系
+
+### 2.1 身份类型
+
+系统支持以下四种C端用户身份类型：
+
+| 身份类型 | 认证状态 | 说明 | 使用场景 |
+|---------|---------|------|---------|
+| **游客** | 未认证 | 仅登录小程序，未进行手机号认证 | 浏览公开信息、查看基础内容 |
+| **管理员** | 已认证 | 通过手机号认证，匹配为管理员身份 | 管理功能、审批操作 |
+| **业务代理人** | 已认证 | 通过手机号认证，匹配为业务代理人身份 | 代理业务操作、客户服务 |
+| **企业员工** | 已认证 | 通过手机号认证，匹配为企业员工身份 | 企业内部业务操作 |
+
+### 2.2 身份识别流程
+
+```
+用户登录小程序
+    ↓
+创建 mdm_mycuser 记录
+    ↓
+授权手机号？
+    ├─ 否 → 游客身份（只有 mdm_mycuser 记录）
+    └─ 是 → 手机号实名认证
+             ↓
+        手机号匹配系统基础数据
+             ↓
+        创建 nr_tocuser 记录
+             ↓
+        分配对应身份（管理员/业务代理人/企业员工）
+```
+
+### 2.3 认证机制
+
+**认证方式**：
+- 用户授权手机号
+- 手机号与系统基础数据的客户进行匹配
+- 匹配逻辑由认证服务统一处理（具体匹配规则由业务层定义）
+
+**认证状态判断**：
+```java
+// 判断用户是否已认证
+boolean isAuthenticated = nr_tocuser 记录存在;
+
+// 判断用户身份类型
+if (nr_tocuser.身份类型 == "管理员") {
+    // 管理员权限
+} else if (nr_tocuser.身份类型 == "业务代理人") {
+    // 业务代理人权限
+} else if (nr_tocuser.身份类型 == "企业员工") {
+    // 企业员工权限
+} else {
+    // 游客权限（仅有 mdm_mycuser 记录）
+}
+```
+
+---
+
+## 三、数据关联规范
+
+### 3.1 选择关联表的原则
+
+根据用户的认证状态选择合适的表进行业务数据关联：
+
+#### 规则一：已认证用户 → 使用 nr_tocuser
+
+**适用场景**：
+- 需要身份验证的业务操作
+- 需要权限控制的功能
+- 门户业务数据的用户关联
+
+#### 规则二：未认证用户 → 使用 mdm_mycuser
+
+**适用场景**：
+- 游客可访问的功能
+- 不需要身份验证的业务场景
+- 用户行为追踪
+
+#### 规则三：混合场景 → 同时支持两种关联
+
+**适用场景**：
+- 业务数据需要支持游客和已认证用户
+- 用户从游客升级为认证用户后，数据需要保持连续性
+
+--- 
+
+### 3.2 实体字段命名规范
+
+**关联字段命名**：
+
+| 关联表 | 字段名称          | 字段类型 | 说明 |
+|-------|---------------|---------|------|
+| `mdm_mycuser` | `cuserId`     | UUID（唯一标识） | 关联C端用户中心用户ID |
+| `mdm_mycuser` | `cuserName`   | String（单行文本，长度128） | 冗余字段：用户名称 |
+| `nr_tocuser` | `tocuserId`   | UUID（唯一标识） | 关联门户用户ID |
+| `nr_tocuser` | `tocuserName` | String（单行文本，长度128） | 冗余字段：用户名称 |
+
+---
+
+## 四、常见问题
+
+### Q1: 什么时候使用 mdm_mycuser，什么时候使用 nr_tocuser？
+
+**回答**：
+- **mdm_mycuser**：
+  - 未认证用户（游客）的业务关联
+  - 需要追踪所有用户（包括游客）的场景
+  - 用户基础信息的存储
+  
+- **nr_tocuser**：
+  - 已认证用户的业务关联（推荐）
+  - 需要身份验证的业务场景
+  - 需要权限控制的功能
+
+**判断标准**：看业务是否需要用户认证，需要认证就用 nr_tocuser，不需要认证就用 mdm_mycuser。
+
+---
+
+### Q2: 为什么有两个用户表？
+
+**回答**：
+这是历史遗留原因造成的设计。最初系统只有 `mdm_mycuser`（C端用户中心），后来门户系统独立发展，创建了 `nr_tocuser` 来存储门户业务相关的用户信息。虽然存在冗余，但两者有明确的职责划分：
+- `mdm_mycuser`：用户中心的核心表，存储用户基础信息
+- `nr_tocuser`：门户业务的扩展表，存储认证和身份信息
+
+---
+### Q5: C端用户的身份是如何匹配的？
+
+**回答**：
+用户通过手机号授权后，系统会执行以下匹配逻辑：
+1. 获取用户授权的手机号
+2. 将手机号与系统基础数据中的客户信息进行匹配
+3. 根据匹配结果分配相应的身份类型（管理员/业务代理人/企业员工）
+4. 创建 `nr_tocuser` 记录，存储身份信息
+
+**注意**：具体的匹配规则由业务层定义，不同的业务系统可能有不同的匹配逻辑。本规范只说明匹配机制的存在，不涉及具体匹配规则的实现细节。
+
+---
+
+## 五、检查清单
+
+在开发涉及C端用户的功能时，请确认：
+
+- [ ] 明确业务场景是否需要用户认证
+- [ ] 选择了正确的用户表进行关联（mdm_mycuser 或 nr_tocuser）
+- [ ] 实体字段命名符合规范（cuserId / tocuserId）
+- [ ] API 添加了正确的权限注解（@IdentityUserPermission()）
+- [ ] 添加了用户认证状态的判断逻辑
+- [ ] 考虑了不同身份类型的权限差异
+- [ ] 添加了必要的日志记录
+- [ ] 处理了用户不存在或未认证的异常情况
+---
+
+**文档版本**：v1.0  
+**最后更新**：2026-02-05  
+**维护人**：开发团队
+

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "6a-spec-install",
-  "version": "1.0.1-dev.13",
+  "version": "1.0.1-dev.17",
   "description": "6A-spec 驱动开发提示词安装工具，支持 Cursor 和 Claude",
   "main": "lib/installer.js",
   "bin": {

package/.cursor/commands/execute-task.md

@@ -1,9 +0,0 @@
----
-description: task-execute workflow
-alwaysApply: false
----
-1. 激活后立即响应：任务执行工作流已被激活
-2. 必需输入：任务文档(如@.docs/入住办理/task/TASK-03-单个办理入住核心逻辑.md)
-3. 要求
-   - 注意不要编写单元测试
-   - 完成后更新任务的状态

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. **文档完整性**
-   - 所有设计决策都要有说明
-   - 关键设计要有图表
-   - 提供足够的实现指导
-