PACP 后端代码生成

要解决什么问题

在 PACP 体系里，一个业务往往拆成多个功能模块，每个模块又包含若干实体。手写 DDL、初始化数据、Controller/Service/DAO/Mapper 以及 JUnit，路径和接口还要和前端从同一份规格里对齐，重复劳动多，也容易在 import、占位符派生的 @RequestMapping、逻辑删除字段 SFSC 等细节上踩坑。

pacp-coding-backend 是面向「一个业务-模块」的后端生成执行者：读 modules/{业务}.{模块}.spec.md，产出该模块的 SQL 与 Java 测试代码，不负责 Vue/API/路由（由 pacp-coding-frontend 处理）。

如何工作

调用方可以是 pacp-spec（多模块、依赖排序）、pacp-coding（单模块快速协调），或 caller=standalone 只要后端。参数用 # 分隔：{spec_file_path}#{backend_project_dir}#{frontend_project_dir}#{database_type}#caller=...；路径里的 # 需写成 \#。

典型流水线：

• 读规格：模块元信息、实体清单、字段表、功能矩阵、占位符映射表（权威定义在 pacp-rules 的 system-module-path）。
• 模块级 SQL：聚合实体 DDL（DDL/{db_type}-{模块}.sql）、模块 init（DATA/...-init.sql）；被 pacp-spec 以 init#caller=pacp-spec 调用时，再生成项目级 shared 字典/菜单/附件/编号等 INSERT。
• 实体级 Java：按骨架生成 Controller（含 queryPage/getById/add/update/delete 等）、Service、DAO、Mapper XML、Exception 及 ServiceImplTest。
• 审核：静态 SQL 检查、零容忍规范（如 import 路径照抄骨架、接口与 spec 占位符一致）、与示例工程对照；standalone 时还要处理文件冲突 CHECKPOINT，禁止静默覆盖。

边界与注意点

• 强依赖 pacp-rules 查询技术栈基线与 Java/SQL 规范；database_type 必须由调用方传入（MySQL/PostgreSQL/Oracle/Dameng/Kingbase）。
• 前后端不靠会话传接口，而是各自从同一份 spec 的占位符映射派生 URL，改占位符规则必须查规则库，不能凭记忆改。
• v2.1 起从原全栈 pacp-coding 拆出；全栈协调与临时规格仍由 pacp-coding / pacp-spec 负责，本技能只落地后端目录结构（{所属业务}/{功能模块}）。