# MES PRD to Code Schema
# 功能文档 → 技术文档 → 完整代码
# 工件流: parse → confirm-scope → tech-design → tasks → test-gen → code

name: mes-prd-to-code
description: |
  MES 项目专属 Schema：从业务功能文档端到端生成技术文档和完整代码。

  输入：功能文档（*.md + *-流程图.drawio + *.html）
  输出：技术设计文档 + 实施任务清单 + 完整可编译代码

  核心能力：
  - 自动解析结构化功能文档（字段表、DDL、业务逻辑、接口定义）
  - 苏格拉底式对话确认模块归属、实施范围、实现细节
  - 适配 MES 项目规范（Oracle + BaseModel + ResponseWrapper + Vue2/ViewUI）
  - 支持多模块文档（识别子模块、依赖图、用户选择范围）
  - 不预定义模式，跟随功能文档描述生成对应代码

  项目结构（相对路径，相对于项目根目录）：
  - 后端: mom-master/（Spring Boot + MyBatis-Plus + Oracle）
  - 前端: implat-ui/（Vue2 + ViewUI + VXETable）
  - 功能文档: 由用户提供文件路径

apply:
  requires:
    - code    # 实施前必须完成所有工件

artifacts:
  - id: parse
    name: 功能文档解析
    description: 解析功能文档，提取结构化信息，识别子模块和依赖关系
    requires: []
    template: parse.md
    instruction: |
      读取用户提供的功能文档文件，完成以下解析工作：

      ## 1. 文件识别
      - 读取 *.md 文件（主功能文档）
      - 读取 *-流程图.drawio 文件（如有，提取流程逻辑）
      - 读取 *.html 文件（如有，提取原型界面信息）

      ## 2. 子模块识别
      - 扫描文档中的"模块一/模块二/..."或"功能一/功能二/..."标记
      - 如果没有显式分模块，将整份文档视为单个模块
      - 对每个子模块提取：名称、类型（新建CRUD/修改已有/外部接口/记录表）

      ## 3. 每个子模块的信息提取

      ### 3.1 功能简介
      - 菜单路径 → 推断前端目录归属
      - 使用人员 → 权限设计参考
      - 功能描述 → 模块概述

      ### 3.2 字段/数据提取
      - 主表字段表 → Entity 字段列表
      - 子表字段表（如有）→ 子表 Entity 字段列表
      - 字段类型映射：
        - VARCHAR → String
        - INT/BIGINT → Long
        - DECIMAL → BigDecimal
        - DATETIME/DATE → Date
        - TINYINT → Integer

      ### 3.3 数据表结构
      - 提取表名、字段、类型、约束
      - 标记需要适配的项：
        - AUTO_INCREMENT → 雪花算法
        - MySQL 类型 → Oracle 类型
        - 非标准审计字段 → BaseModel 审计字段

      ### 3.4 业务逻辑
      - 提取"补充逻辑"/"特殊逻辑"/"业务逻辑"章节
      - 提取校验规则（唯一性、非空、格式校验等）
      - 提取导入/导出规则
      - 从流程图提取状态流转（如有）

      ### 3.5 接口定义
      - 提取外部接口（如有）的方法、路径、请求/响应格式
      - 标记调用方向（设备→MES / MES→外部系统）

      ### 3.6 按钮/操作
      - 提取按钮清单 → API 接口清单
      - 映射：新增/编辑/查看/删除/导入/导出 → 标准 CRUD 接口

      ## 4. 依赖关系分析
      - 分析子模块之间的数据依赖（A 模块的表被 B 模块引用）
      - 分析子模块之间的功能依赖（B 模块修改 A 模块创建的功能）
      - 绘制依赖关系图（ASCII）

      ## 5. 输出格式
      按 parse.md 模板输出解析报告，包含：
      - 模块清单表
      - 每个模块的字段清单、表结构、业务逻辑摘要
      - 依赖关系图
      - 需要用户确认的疑问点

      注意：此阶段只做解析，不做任何技术决策。技术决策在后续对话中完成。
    output: parse.md

  - id: confirm-scope
    name: 范围确认
    description: 苏格拉底式对话确认模块归属、实施范围、架构决策
    requires: [parse]
    template: confirm-scope.md
    instruction: |
      基于解析报告，以苏格拉底式对话与用户确认以下内容。
      逐个问题提问，不要一次问多个。

      ## 必须确认的问题

      ### Q0: 项目根目录
      - 提问："项目根目录在哪里？（mom-master 和 implat-ui 所在的目录）"
      - 说明：后续所有代码路径将基于此目录生成
      - 使用 codegraph_explore 或 ls 验证目录结构是否正确

      ### Q1: 实施范围（仅多模块时）
      如果解析出多个子模块：
      - 展示模块清单和依赖关系图
      - 提问："识别到 N 个子模块，依赖关系如下: ... 本次实施哪些？"
      - 等待用户选择

      ### Q2: 后端模块归属
      - 提问："后端代码归属哪个 center？"
      - 给出建议（根据功能文档的菜单路径推断）
      - 选项参考：modules-center 下的 material-center / production-center / quality-center 等

      ### Q3: 后端包路径
      - 提问："后端包路径？"
      - 给出建议：com.twsz.mom.{module}.{sub-package}
      - 参照已有代码的包结构

      ### Q4: 前端目录
      - 提问："前端页面和 API 放在哪个目录？"
      - 给出建议：
        - API: src/api/{domain}/
        - 页面: src/views/{domain}/{entity}/

      ### Q5: 已有代码影响
      - 使用 codegraph_explore 扫描是否已有相关代码
      - 如果有：展示已有代码，提问是否需要修改
      - 如果没有：标注为全部新建

      ### Q6: 特殊技术决策
      根据解析结果自动判断是否需要询问：
      - 如果有"单据编号"字段 → 确认是否使用 @AutoGenCode
      - 如果有状态字段 → 确认是否需要状态流转（审核/弃审）
      - 如果有外部接口 → 确认接口鉴权方式
      - 如果涉及已有模块修改 → 确认修改范围和回归测试

      ### Q7: 表名前缀
      - 提问："表名的模块前缀是什么？例如 pcba_（PCBA）、mm_（仓储）、wip_（生产）、bd_（基础数据）"
      - 根据模块推断建议值，等待用户确认
      - 所有新建表将使用此前缀，如 `{prefix}_cad_data`

      ### Q8: 表空间选择
      - 提问："数据表归属哪个业务模块？（决定表空间）"
      - 表空间映射规则：
        - 生产/车间数据 → MES_DATA_WORKS（数据）/ MES_IDX_WORKS（索引）
        - 仓储/物流数据 → MES_DATA_WMS（数据）/ MES_IDX_WMS（索引）
        - 基础/通用数据 → MES_DATA_COM（数据）/ MES_IDX_COM（索引）
      - 默认根据模块推断，等待用户确认

      ### Q9: 索引策略
      - 根据解析结果中的业务规则，分析需要建索引的字段，提出建议：
        - 唯一性校验字段 → 唯一索引（U1, U2...）
        - 高频搜索字段 → 普通索引（N1, N2...）
        - 外键关联字段 → 普通索引
      - **唯一索引规范**：必须以 `org_id` 作为首列，组成联合唯一索引，格式：`(org_id, 业务字段1, 业务字段2...)`
      - 向用户展示建议的索引清单，等待确认或调整
      - 这是持续交互过程，用户可以增减索引字段

      ## 确认结果记录
      将所有确认结果写入 confirm-scope 记录中，作为技术文档的输入。
      格式：
      ```
      ## 确认结果
      - 实施范围: [模块列表]
      - 后端 center: xxx
      - 后端包路径: com.twsz.mom.xxx
      - 前端 API 目录: src/api/xxx/
      - 前端页面目录: src/views/xxx/
      - 表名前缀: {prefix}_
      - 表空间: MES_DATA_xxx（数据）/ MES_IDX_xxx（索引）
      - 编号生成: @AutoGenCode / 无
      - 状态流转: 有(审核/弃审) / 无
      - 已有代码影响: [列表]
      - 索引策略: [索引清单]
      ```

  - id: tech-design
    name: 技术设计文档
    description: 基于确认结果生成完整技术设计文档
    requires: [parse, confirm-scope]
    template: tech-design.md
    instruction: |
      基于解析报告和确认结果，生成完整的技术设计文档。

      生成代码模板前请先读取本 schema 目录下的 comment-rules.md，遵循其中的 Java 注释规范（类/方法/字段/行内注释格式）。

      ## 文档结构

      ### 1. 数据库设计
      - 读取 confirm-scope 中的表名前缀、表空间、索引策略
      - 将功能文档的 DDL 适配为 Oracle 语法
      - 适配规则：
        - INT/BIGINT AUTO_INCREMENT → NUMBER(19) 雪花算法
        - VARCHAR(n) → NVARCHAR2(n)
        - DATETIME → DATE
        - CURRENT_TIMESTAMP → SYSDATE
        - 审计字段统一为: created_by, created_date, last_updated_by, last_updated_date
        - 去除 is_deleted 逻辑删除字段（MES 使用物理删除）
        - 每张表必须包含 org_id NUMBER(19) NOT NULL 字段（多租户字段）
          **重要**: org_id 仅在 DDL 中定义（用于唯一索引组合列），不在 Entity 中声明。
          MyBatis-Plus TenantLineInnerInterceptor 已配置多租户，INSERT/SELECT 自动注入 org_id，业务代码无需显式处理。
      {{rules}}
      - 包含完整 DDL + 索引 + 注释 + 表空间
      - **表名**: 使用 confirm-scope 确认的模块前缀，如 `{prefix}_cad_data`
      - **索引命名规范**（严格遵守）:
        - 主键索引: `{tableName}_PK`
        - 普通索引: `{tableName}_N1`, `{tableName}_N2`, ... `{tableName}_N5`
        - 唯一索引: `{tableName}_U1`, `{tableName}_U2`, ... `{tableName}_U5`
        - 唯一索引必须以 `org_id` 为首列: `UNIQUE INDEX xxx_U1(tableName, org_id, 业务字段1, ...)`
      - **表空间**（使用 confirm-scope 确认的值）:
        - 数据段: TABLESPACE {data_tablespace}
        - 索引段: USING INDEX TABLESPACE {index_tablespace}
      - 标注建表方式: dbx MCP（优先）/ SQL 脚本

      ### 2. API 接口设计
      - 标准 CRUD 接口（根据功能文档的按钮/操作推导）：
        - POST /{entity}/search — 分页查询
        - POST /{entity}/add — 新增
        - PUT /{entity}/update — 修改
        - DELETE /{entity}/delete — 批量删除
        - POST /{entity}/export — 导出
        - POST /{entity}/uploadExcel — 导入（如有），由 BaseAnalysisEventListener 承载批量校验与入库
      - 外部接口（如功能文档有定义）：
        - 按功能文档定义的路径和方法
        - 请求/响应格式按功能文档
      - 每个接口给出：
        - 请求示例 JSON
        - 响应示例 JSON
        - 错误码

      ### 3. 后端代码结构
      对每个 Entity 给出：

      #### Entity（完整代码模板）
      - 继承 BaseModel（com.twsz.mom.ds.model.BaseModel，不是 com.twsz.mom.common.base.BaseModel）
      - @TableName, @Data, @EqualsAndHashCode(callSuper=true)
      - @JsonInclude(JsonInclude.Include.NON_NULL)
      - @TableId(type=IdType.ASSIGN_ID) + @JsonSerialize(ToStringSerializer) — id 字段必须在 Entity 中显式声明
      - BaseModel 已提供审计字段(createdBy/Date, lastUpdatedBy/Date)，Entity 中禁止重复声明
      - ViewModel 已提供 opt 字段，Entity 中禁止重复声明
      - org_id 禁止在 Entity 中声明（多租户 TenantLineInnerInterceptor 自动处理）
      - @ExcelProperty("中文名")（每个业务字段，支持导入导出）
      - 非数据库字段: @TableField(exist = false) + @ExcelIgnore
      - Long 类型字段: @JsonSerialize(using = ToStringSerializer.class)（防止 JS 精度丢失）
      - @AutoGenCode（如有编号字段）
      - 主子表: @TableField(exist = false) private List<DetailEntity> details
      - 给出完整 Java 代码
      {{rules}}

      #### Mapper（完整代码模板）
      - 接口继承 BaseMapper<T>
      - 方法: pageSearch + list
      - XML: Columns/Where 片段 + 查询语句
      - 给出完整代码

      #### Service（方法签名 + 关键逻辑）
      - 接口方法签名
      - 关键业务逻辑用伪代码描述：
        - 校验规则
        - 唯一性检查
        - 事务控制
        - 导入逻辑
      - 不要求完整实现代码

      #### Controller（完整代码模板）
      - @RestController + @RequestMapping("/api/v1/entity-kebab-case")（含版本号 /api/v1/）
      - @Autowired 或 @Resource 字段注入（项目惯例，非构造器注入）
      - 统一返回 ResponseWrapper<T>（com.twsz.mom.core.common.ResponseWrapper）
      - 标准方法: search(POST) / save(POST) / delete(DELETE) / list(POST) / export(POST)
      - Controller 只做参数校验和结果封装，禁止写业务逻辑
      - 给出完整代码
      {{rules}}

      ### 4. 前端代码结构
      对每个页面给出：

      #### API 文件
      - 完整 JS 代码（import + 各方法）

      #### 列表页（配置描述）
      - 搜索条件字段
      - 表格列定义（列名、key、slot）
      - 工具栏按钮
      - 组件: search-table + indexPage mixin

      #### 表单页（配置描述）
      - 表单字段列表（控件类型、必填、校验规则）
      - 组件: master-sub + Form
      - 提交逻辑

      ### 5. 业务逻辑流程
      - 用 ASCII 流程图描述核心业务操作
      - 标注校验点和异常处理
      - 如有状态流转，画出状态机

      ### 6. 集成点 + 菜单权限
      - 被其他模块调用的方式
      - 菜单注册 SQL（c_sys_resource）

      ## 对话 2: 实现确认
      生成技术文档初稿后，以苏格拉底式对话确认：
      - 表名和字段名是否确认？
      - API 路径是否正确？
      - 前端组件选型是否符合预期？
      - 特殊校验规则是否完整？
      - 用户确认后更新技术文档

      ## 输出
      最终版 tech-design.md

    output: tech-design.md

  - id: tasks
    name: 实施任务清单
    description: 基于技术文档拆分实施任务，每个任务含完整代码
    requires: [tech-design]
    template: tasks.md
    instruction: |
      基于技术设计文档，拆分为可执行的实施任务列表。

      生成代码前请先读取本 schema 目录下的 comment-rules.md，遵循其中的 Java 注释规范（类/方法/字段/行内注释格式）。

      ## 任务拆分原则
      1. 每个任务足够小（2-5 分钟完成）
      2. 包含精确的文件路径（匹配 MES 项目包结构）
      3. 包含完整的代码（从技术文档的模板中提取）
      4. 包含验证步骤
      5. 任务之间尽量独立

      ## 任务顺序
      按以下顺序排列：

      ### 数据库任务
      1. 建表 DDL（标注 dbx MCP 或 SQL 脚本）

      ### 后端任务（每个 Entity 一组）
      2. Entity 实体类（完整代码）
      3. Mapper 接口（完整代码）
      4. Mapper XML（完整代码）
      5. Service 接口（完整代码）
      6. ServiceImpl 实现（完整代码，含业务逻辑）
      7. Controller（完整代码）

      ### 前端任务（每个页面一组）
      8. API 文件（完整代码）
      9. 列表页 index.vue（完整代码）
      10. 表单页 form.vue（完整代码）
      11. 子表页 table-form.vue（如有主子表，完整代码）

      ### 测试任务（每个 ServiceImpl 一组）
      12. ServiceImpl 单元测试（XxxServiceImplMockTest.java）

      ### 配置任务
      13. 菜单注册 SQL

      ### 如有外部接口
      12. 外部接口 Controller（独立路径）
      13. 外部接口 Service 逻辑

      ## 任务格式
      ```
      - [ ] Task-NNN: <标题>
        文件: <精确路径>
        描述: <具体实现指令>
        代码:
        ```java/vue/js/sql
        <完整代码>
        ```
        验证: <验证步骤>
        依赖: Task-XXX
      ```

      ## 任务依赖图
      用 ASCII 图展示任务依赖关系

    output: tasks.md

  - id: test-gen
    name: 测试代码生成
    description: 基于 ServiceImpl 生成单元测试代码
    requires: [tasks]
    template: test-gen.md
    instruction: |
      基于 tasks.md 中的 ServiceImpl 代码，生成对应的单元测试。

      生成前请先读取本 schema 目录下的 references.md，了解可用的公共工具类和方法，测试中 Mock 的依赖方法签名需与 references.md 一致。
      生成代码前请先读取本 schema 目录下的 comment-rules.md，遵循其中的 Java 注释规范（类/方法/字段/行内注释格式）。

      ## 测试规范
      - 测试类名 = 原类名 + MockTest（如 PcCadDataServiceImpl → PcCadDataServiceImplMockTest）
      - 框架: JUnit 5 + Mockito
      - @ExtendWith(MockitoExtension.class)
      - @Mock 模拟依赖（Mapper、其他Service）
      - @InjectMocks 注入被测类
      - setUp 中使用 ReflectionTestUtils.setField 注入 baseMapper
      - 使用 @Nested 类按方法分组，@DisplayName 描述场景
      - 测试方法命名: should_预期行为_when_条件()

      ## 必须覆盖的场景
      - saveModel: 新增成功、编辑成功、乐观锁冲突
      - deleteByIds: 批量删除+级联
      - search: 分页查询
      - list: 列表查询
      - uploadExcel: BaseAnalysisEventListener.handle() 内批量校验、跳过统计（如有）

      ## 文件路径
      测试文件放在: src/test/java/{与ServiceImpl相同的包路径}/

      ## 输出
      - 每个 ServiceImpl 对应一个测试文件
      - 包含完整可编译的测试代码
      {{rules}}
    output: test-gen.md

  - id: code
    name: 代码生成
    description: 按任务清单生成完整代码文件
    requires: [tasks, test-gen]
    template: code-generation.md
    instruction: |
      按任务清单逐个生成代码文件。

      生成前请先读取本 schema 目录下的 references.md，了解可用的公共工具类和方法，优先复用已有方法，避免重复实现。
      生成代码前请先读取本 schema 目录下的 comment-rules.md，遵循其中的 Java 注释规范（类/方法/字段/行内注释格式）。

      ## 执行方式
      1. 按任务依赖顺序执行
      2. 每个任务：
         a. 从 tasks.md 中取出代码
         b. 写入精确的文件路径
         c. 验证文件创建成功
      3. 数据库任务：通过 dbx MCP 或输出 SQL 脚本

      ## 代码规范检查
      生成的代码必须符合以下 MES 规范：
      - Java 8 语法，不使用 Java 9+ 特性
      - Lombok 注解（@Data, @EqualsAndHashCode(callSuper=true) 等）
      - SLF4J 日志（@Slf4j），不用 System.out.println
      - LambdaQueryWrapper，不用字符串字段名
      - ResponseWrapper<T> 统一响应
      - BaseModel 继承（com.twsz.mom.ds.model.BaseModel）
      - Entity: callSuper=true, 不重复声明 id/orgId/opt/审计字段
      - Controller: @Autowired, @RequestMapping("/api/v1/kebab-case")
      - 数据库字符串字段使用 NVARCHAR2
      - Vue 2 Options API
      - View Design 4 组件
      - indexPage mixin / master-sub / tw-table 组件
      {{rules}}

      ## 输出
      - 所有代码文件已写入磁盘
      - 生成文件清单
      - 标注需要用户手动执行的操作（如建表 SQL、菜单注册 SQL）

    output: code-generation.md