6a-spec-install 1.0.0

package/.cursor/commands/6A-excel-table-gen.md

@@ -0,0 +1,9 @@
+---
+description: 6A-export-table workflow
+alwaysApply: false
+---
+1. Immediate response upon activation: 6A-export-table workflow has been activated.
+2. Read file: `.cursor/rules/6A/6A_export_table_to_excel_sop.md`.
+3. Strictly and exclusively follow the "Excel file generation SOP" defined in that file.
+4. Do not invent, infer, or supplement any rules beyond the SOP.
+5. Output Excel files exactly as specified in the SOP.

package/.cursor/commands/6A-model.md

@@ -0,0 +1,8 @@
+---
+description: 6A-model workflow
+alwaysApply: false
+---
+1. Immediate response upon activation: 6A-model workflow has been activated
+2. Read file: `.cursor/rules/6A/6A_model_sop.md`
+3. Strictly follow the "Domain modeling and database design Architecture SOP" defined in that file
+4. Output the Domain model and table design

package/.cursor/commands/6A-new.md

@@ -0,0 +1,8 @@
+---
+description: 6A-new workflow
+alwaysApply: false
+---
+1. Immediate response upon activation: 6A-new workflow has been activated.
+2. Read file: `.cursor/rules/6A/6A_new_feature_sop.md`
+3. Strictly follow the "New Feature Architecture SOP" defined in that file.
+4. Output the Technical Design Document (TDD).

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

@@ -0,0 +1,8 @@
+---
+description: 6A-task workflow
+alwaysApply: false
+---
+1. Immediate response upon activation: 6A-task workflow has been activated
+2. Read file: `.cursor/rules/6A/6A_task_sop.md`
+3. Strictly follow the "Task Decomposition SOP" defined in that file
+4. Output the task list

package/.cursor/commands/6A-visual-logic.md

@@ -0,0 +1,10 @@
+---
+description: 6A-visual-logic workflow
+alwaysApply: false
+---
+1. Immediate response upon activation: 6A-visual-logic workflow has been activated.
+2. Read file: `.cursor/rules/6A/6A_visual_logic_sop.md`.
+3. Strictly follow the "Visual Logic Diagrams SOP" defined in that file.
+4. Output Mermaid diagrams as specified in the SOP.
+
+

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

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

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

@@ -0,0 +1,133 @@
+---
+description: 从Markdown文档提取表结构并生成Excel文件的标准操作流程 (Export table schema from Markdown to Excel SOP)
+alwaysApply: false
+---
+
+# 6A-export-table: 从Markdown文档提取表结构并生成Excel文件的标准操作流程
+
+## 角色
+你现在的角色是【文档处理专家 + 自动化工具执行者】，负责从Markdown文档中提取表结构设计信息，并自动生成标准化的Excel文件。
+
+## 目标
+从包含表结构设计的Markdown文档中提取所有表定义，为每个表生成一个格式化的Excel文件，便于后续的数据建模、开发参考和文档归档。
+
+## 规则
+1. **严格遵循脚本规范**：必须使用提供的Python脚本 `.cursor/script/md_to_excel.py`，不得自行编写或修改脚本逻辑
+2. **输入验证**：执行前必须验证Markdown文件存在且可读
+3. **输出验证**：执行后必须验证Excel文件是否成功生成
+4. **错误处理**：如遇到错误，必须提供清晰的错误信息和解决建议
+5. **路径处理**：所有文件路径必须使用绝对路径或相对于工作区根目录的路径
+
+## 输入要求
+- **必需输入**：
+  - Markdown文档路径（包含表结构设计的文档）
+  - 输出目录路径（可选，默认为当前目录）
+- **Markdown文档格式要求**：
+  - 表定义必须以 `##### 数字. 表名 (表英文名)` 格式开头
+  - 必须包含表信息表格（表中文名称 | 表英文名称）
+  - 必须包含字段信息表格（字段中文名称 | 字段英文名称 | 字段类型 | 是否必填 | 字段说明）
+
+## 标准操作流程 (SOP)
+
+### 第一步：确认输入参数
+1. **验证Markdown文件路径**
+   - 检查文件是否存在
+   - 确认文件路径格式正确（支持相对路径和绝对路径）
+   - 如果用户未提供完整路径，尝试在工作区中查找
+
+2. **确认输出目录**
+   - 如果用户指定了输出目录，验证目录是否存在
+   - 如果目录不存在，提示是否创建
+   - 如果未指定，使用当前目录或Markdown文件所在目录
+
+### 第二步：执行Python脚本
+1. **构建命令**
+   ```bash
+   python .cursor/script/md_to_excel.py <markdown_file_path> [output_dir]
+   ```
+   
+2. **执行要求**
+   - 使用绝对路径执行脚本
+   - 确保Python环境可用（Python 3.x）
+   - 确保所需依赖已安装（openpyxl）
+
+3. **执行脚本**
+   - 调用终端命令执行Python脚本
+   - 捕获并显示执行输出
+   - 检查返回码
+
+### 第三步：验证输出结果
+1. **检查执行状态**
+   - 验证脚本是否成功执行（返回码为0）
+   - 检查是否有错误输出
+
+2. **验证生成的文件**
+   - 确认Excel文件已生成
+   - 验证文件数量是否与提取的表数量一致
+   - 检查文件是否可读
+
+3. **输出结果摘要**
+   - 列出所有生成的Excel文件路径
+   - 显示每个文件对应的表名
+
+### 第四步：错误处理
+如果执行失败，按以下步骤处理：
+
+1. **分析错误类型**
+   - 文件不存在错误：提示检查文件路径
+   - 格式错误：提示检查Markdown格式是否符合要求
+   - 依赖缺失：提示安装openpyxl库
+   - Python环境错误：提示检查Python版本
+
+2. **提供解决建议**
+   - 针对具体错误提供修复建议
+   - 如果Markdown格式不符合要求，指出具体问题
+
+## 输出要求
+1. **执行过程输出**
+   - 显示读取的Markdown文件路径
+   - 显示提取到的表结构数量
+   - 显示每个Excel文件的生成状态
+
+2. **最终结果输出**
+   - 列出所有成功生成的Excel文件路径
+   - 提供文件位置摘要
+
+3. **格式要求**
+   - 使用清晰的中文提示信息
+   - 使用emoji图标增强可读性（✅、❌、📖、📊等）
+
+## 示例用法
+
+### 示例1：基本用法
+```
+用户输入：从 .docs/服务评价/MODEL_服务评价.md 生成Excel文件
+执行：python .cursor/script/md_to_excel.py .docs/服务评价/MODEL_服务评价.md
+输出：在 .docs/服务评价/ 目录下生成对应的Excel文件
+```
+
+### 示例2：指定输出目录
+```
+用户输入：从 MODEL_服务评价.md 生成Excel到 ./excel_output 目录
+执行：python .cursor/script/md_to_excel.py MODEL_服务评价.md ./excel_output
+输出：在 ./excel_output 目录下生成对应的Excel文件
+```
+
+## 注意事项
+1. **Python依赖**：确保已安装 `openpyxl` 库，可通过 `pip install openpyxl` 安装
+2. **文件编码**：Markdown文件必须使用UTF-8编码
+3. **表格式要求**：Markdown中的表必须严格按照脚本期望的格式编写
+4. **文件命名**：生成的Excel文件以表英文名命名（如：`rental_ServiceEvaluation.xlsx`）
+5. **覆盖行为**：如果输出目录中已存在同名Excel文件，脚本会覆盖该文件
+
+## 脚本功能说明
+Python脚本 `.cursor/script/md_to_excel.py` 的主要功能：
+- **提取表结构**：从Markdown中识别以 `##### 数字. 表名` 开头的表定义
+- **解析表信息**：提取表中文名、表英文名、表说明
+- **解析字段信息**：提取每个字段的中文名、英文名、类型、是否必填、说明
+- **生成Excel**：为每个表生成格式化的Excel文件，包含：
+  - 表基本信息（表中文名、表英文名、说明）
+  - 字段详情表格（字段中文名、字段英文名、字段类型、是否必填、字段说明）
+  - 格式化样式（表头背景色、边框、对齐方式等）
+
+

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

@@ -0,0 +1,91 @@
+---
+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

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