PACP单模块代码生成协调者

解决什么问题

单模块需求最容易死在"对话式生成"上：一句"给我做一个站点管理模块"，模型可能直接开始写代码，结果是表结构对不上、前后端字段命名不一致、编译失败又没人兜底。

pacp-coding 把这件事拆成协调者 + 子技能的结构：它自己不生成骨架代码，而是负责理解需求、产出一份临时规格文件，再按模式调度 pacp-coding-backend 和 pacp-coding-frontend，最后统一做编译验证。对你来说，最大的价值是生成前有一份可确认的规格，生成后有一份验证报告，而不是一堆需要你自己拼装的片段。

核心能力与执行流程

需求解析与模式判定：从自然语言中提取业务、模块、实体、功能清单、字段清单，并按关键词判定 backend、frontend 或 fullstack 三种模式。

目录识别：通过 pom.xml 定位后端项目，通过 package.json 定位前端项目；找不到就停下来问你，而不是瞎猜路径。

临时规格构建：在 {项目根目录}/.pacp/temp/ 下生成 pacp-temp-{business}.{module}.spec.md，包含模块元信息、实体清单、字段规格表、功能矩阵等 10 个标准章节。包含后端或全栈模式时，还会确认数据库类型，并在规格末尾追加测试数据章节（默认每实体 10 条种子数据）。

子技能调度：以 {spec_file_path}#{backend_dir}#{frontend_dir}#{database_type} 的格式传参调用后端或前端子技能，全栈模式下先后端后前端。子技能只做静态审核，不负责编译。

统一编译验证：用 mvn 或 pnpm 编译并跑测试，失败时给出错误类型、文件、行号和原因，再询问你是修复重试、强制生成还是中止。

中断恢复：临时规格放在项目目录下而非 /tmp/，会话中断后可通过检查该目录恢复；正常完成才删除，中止或编译失败会保留。

适用边界与注意点

它明确面向简单业务、单模块场景。多模块、需要原型解析和依赖排序的需求，应该用 pacp-spec，后者的规格持久化到 .pacp/ 批次目录，支持多批次隔离和跨会话恢复。

七种场景它会强制暂停确认：业务分类不确定、模块划分不确定、字段清单不完整、组件绑定冲突、公共代码值缺失、数据库类型无法确定、编译失败。这是有意为之——宁可多问一句，也不要生成一套字段名互相打架的前后端代码。

它依赖 pacp-rules、pacp-coding-backend、pacp-coding-frontend 安装在同一个父目录（如 skills/）下，否则骨架路径引用会失效。项目目录路径中如果包含 # 字符，需要转义，建议直接避免。