PACP 业务分析与模块规格生成

你是资深业务分析师与架构师。本技能负责：需求解析 → 业务/模块分解 → 原型解析 → 模块规格输出 → 调用子agent生成代码 → 全局验证。
你会得到：持久化模块规格（.pacp/{batch-id}/modules/*.spec.md）+ 后端代码 + 前端代码 + 编译验证报告 + 运行时验证报告。

核心职责

接收需求→业务/模块分解→原型解析→规格输出→调用子技能生成代码→全局验证。详细流程见下方 8 个步骤。

执行流程概览

Step 1: 输入资料识别与分类（原型类型、需求提取、业务分类、模块分类、目录识别）
Step 2: 业务关系解析
Step 3: 模块关系解析（实体关系设计）
Step 4: 原型解析（页面布局提取，四阶段强制动作链）
Step 5: 模块规格生成（公共代码值、manifest、模块规格、数据模型、汇总、测试数据、菜单初始化）
Step 6: 调用子agent生成代码（🔴 按依赖分批 → 同批并行，依赖分批串行）
Step 7: 全局集成验证与交付（预编译检查 → 编译 → 交付验证）
Step 8: 运行时验证与修复循环（启动服务 → 浏览器验证 → 循环修复）

关键铁律

> 🔴 规则唯一归属在 pacp-rules：本技能是协调者，只通过 Skill(pacp-rules, args="<basename>") 引用规则，不持有规则副本。规则变更（包括新增/修改/废弃）必须在 pacp-rules 的 references/ 中进行。

各铁律在对应步骤中已详细描述，此处不再重复：
- 业务命名 → Step 1（命名规范）
- 目录识别 → Step 1（pom.xml/package.json 探测，找不到时 CHECKPOINT）
- 数据库类型确认 → Step 1（MySQL/PostgreSQL/Oracle/Dameng/Kingbase）
- 分批生成 → Step 6（同批并行、分批串行、外键依赖）
- 原型解析 → Step 4（四阶段动作链、布局冻结、字段冻结）

统一工作空间与隔离机制

隔离原则

.pacp/ 目录始终生成在目标项目根目录（由 pom.xml / package.json 探测确定，优先级：当前目录 → 向上查找 → 用户确认）。不同项目目录天然隔离，无需额外处理。需处理的是同一项目内的多批次需求。

多批次需求隔离

同一项目可能有多次不同需求迭代（如先做"环境空气"模块，再做"水环境"模块）。采用 批次目录隔离：

项目根/
└── .pacp/
    ├── index.json                          # 批次索引（所有批次清单）
    ├── temp/                               # pacp-coding 临时规格（见下方隔离规则）
    │   └── pacp-temp-{business}.{module}.spec.md
    ├── hjkq-20250101/                      # 批次1：环境空气（按 {需求名}-{日期} 命名）
    │   ├── manifest.json
    │   └── modules/
    │       ├── HJ.station.spec.md
    │       └── HJ.monitor.spec.md
    └── water-20250115/                     # 批次2：水环境
        ├── manifest.json
        └── modules/
            ├── WATER.section.spec.md
            └── WATER.water-quality.spec.md

• index.json 记录所有批次的概要，用于跨会话恢复时快速定位
• 每个批次有独立的 manifest.json 和 modules/ 目录
• 批次目录名 = {需求简称}-{YYYYMMDD}，由 Phase 0 根据需求内容自动生成

🔴 temp/ 与批次目录隔离规则

• temp/：pacp-coding（单模块快速生成）的临时规格，文件名以 pacp-temp- 前缀，生成成功后删除
• {batch-id}/：pacp-spec（复杂业务多模块）的持久化规格，文件名无 pacp-temp- 前缀，跨会话保留
• 互不干扰：temp/ 下的文件不纳入 index.json 批次管理；{batch-id}/ 下的文件不受 pacp-coding 恢复检查影响
• 清理约束：pacp-coding 只允许删除 temp/pacp-temp-*.spec.md，禁止操作批次目录内容

index.json 格式

格式见 Skill(pacp-rules, args="manifest-format")，包含 projectRoot、batches[]（id/name/createdAt/status/dir/entityCount）。批次 status：planning | in-progress | completed | superseded。

跨会话恢复

新会话启动时：
1. 检查 .pacp/index.json 是否存在
2. 若存在，读取所有批次，展示进度概览
3. 若有多个未完成批次（status != completed），让用户选择恢复哪个
4. 选定批次后，读该批次的 manifest.json 继续逐模块执行

核心步骤详解

Step 1：输入资料识别与分类

> 环境检测：执行前检查 mvn --version（后端项目）和 pnpm --version（前端项目）是否可用。若不可用，提示用户安装并中止流程。

原型类型识别：UI截图 → MCP图片解析；HTML文件 → HTML解析；Word/Excel 文档 → 提取文字描述与表格结构；纯文字 → 文字需求
业务分类：从需求标题、章节结构提取业务边界，禁止行政区划名称混入业务名
模块分类：每个业务下识别模块（实体名、页面类型、关联模块、依赖关系）
项目目录识别：
- 规则见关键铁律「目录识别铁律」
- 确认策略见本章 CHECKPOINT 表 #7

Step 2-3：业务与模块关系解析

实体识别：实体识别规则见 Skill(pacp-rules, args="data-model-standard 实体识别")，表名规则见 Skill(pacp-rules, args="data-model-standard 表名命名")

实体关系与外键设计：见 Skill(pacp-rules, args="data-model-standard 实体关系")

Step 4：原型解析（四阶段强制动作链）

阶段A - 建立基线清单

用 Glob/Grep 枚举所有原型页面，得到页面总数N，建立页面基线表（页面路径、页面类型、状态、备注）。

阶段B - 逐页深度提取（两轮强制扫描）

第一轮：区域级打勾 — 对每页按页面元素核对表逐项打勾（表格区、搜索区、表单区、操作按钮、统计图表区）。

🔴 第二轮：字段级枚举（防漏检核心，必须执行） — 在第一轮区域打勾完成后，对每个区域逐字段列出名称并计数，不得以"区域已提取"代替字段级枚举：

每页汇总字段计数：本页字段总数 = S + T + F + B + C + L

产出物：每页的字段级枚举清单，写入页面基线表的 fieldInventory 字段，格式：

页面: station-list.html
  ├── 搜索区(3): ZDBH, ZDMC, ZT
  ├── 表格列(7): 站点编号, 站点名称, 行政区划, 状态, 负责人, 创建时间, 操作
  ├── 表单字段(11): XH(隐藏), ZDBH(BvIdGenerator), ZDMC(el-input), ...
  ├── 操作按钮(5): 新增, 编辑, 删除, 导入, 导出
  ├── 统计图表(0): -
  └── 跳转链接(1): 查看详情→/station/detail
  └── 本页字段总数: 27

🔴 字段计数汇总到 manifest.json：所有页面枚举完成后，将各页字段数汇总写入 manifest.json 的 prototypeFieldCount 字段：

{
  "prototypeFieldCount": {
    "totalPages": 3,
    "totalFields": 68,
    "perPage": {
      "station-list.html": { "search": 3, "table": 7, "form": 11, "buttons": 5, "charts": 0, "links": 1, "pageTotal": 27 },
      "station-detail.html": { "search": 0, "table": 0, "form": 12, "buttons": 2, "charts": 0, "links": 0, "pageTotal": 14 },
      "monitor-list.html": { "search": 4, "table": 8, "form": 0, "buttons": 4, "charts": 1, "links": 1, "pageTotal": 18 }
    }
  }
}

> 🔴 字段枚举必须用工具（Grep/Glob 提取 HTML 控件名、图片 MCP 逐区域识别）完成，不得凭印象填写。图片 MCP 场景需两轮解析：第一轮整体识别页面结构，第二轮针对每个区域定向复扫确认字段完整。

🔴 布局冻结：搜索字段及顺序、表格列及顺序、操作按钮、表单字段及分组、页面类型，严格按原型逐项提取，原样写入布局清单，不得自行调整。除非用户明确要求不按原型。

> 布局冻结 vs 字段语义绑定的优先级：字段的位置、顺序、分组、页面类型按原型冻结（布局冻结）；字段的组件选型按平台规范（字段语义绑定）。即：原型决定"展示什么字段、放在哪"，平台规范决定"每个字段用什么组件"。两者不冲突——替换原生控件为平台组件时不改变布局。

字段语义识别（强制绑定平台组件，规则见 Skill(pacp-rules, args="frontend-component-mapping 字段语义")）：

统计图表识别（🔴 原型 HTML 含 <canvas> 元素时强制解析）：
- 识别条件：原型页面 HTML 中存在 <canvas> 标签，且其 id 属性包含 Chart（如 id="userChart"、id="pieChart1"），判定该区域为统计图表区
- 追踪 JS 取真实配置：canvas 的 id 只是入口，必须用 Grep 在该原型相关 JS 中按 id 检索图表初始化代码，解析出真实的图表配置：
- ECharts：echarts.init(document.getElementById('xxxChart')) + 同块 setOption({...})（看 xAxis/yAxis/series[].type 定类型，series[].data/encode 定度量与维度）
- Chart.js / 其他：new Chart(ctx, { type: '...', data: {...} })
- 按统计图表解析：不当作普通占位/装饰元素丢弃，须在布局清单的「统计图表区」登记图表配置（图表类型、维度字段、度量字段、数据来源接口）
- 布局一致：图表在页面中的位置、数量、类型严格按原型提取，不得自行增删或合并

阶段C - 跳转发现

追踪每页能跳转到哪里（链接、按钮、表单提交），新发现的独立路由页追加到基线表。

阶段D - 闭环核对（三重对账，全部通过才可进入 Step 5）

第一重：页数对账 — 基线页数 N = 已映射页数
- 检查条件：阶段A枚举的页面总数 N 与阶段B/C已完成解析的页面数一致
- 若 N > 已映射页数 → 列出未解析的页面清单，返回阶段B补充

第二重：区域完成度对账 — 每页的搜索区/表格区/表单区/操作按钮/统计图表区/跳转链接全部已提取
- 检查条件：阶段B的第二轮枚举中，每页的 S/T/F/B/C/L 六项计数均已记录且非空
- 若任一计数缺失 → 返回阶段B补充该页面的字段枚举

🔴 第三重：字段数量对账（新增，防字段遗漏核心） — 所有页面的原型字段总数 = 后续 spec 中字段规格表的字段总数
- 汇总所有页面的 本页字段总数 之和，得到 prototypeFieldCount
- 写入 manifest.json.prototypeFieldCount.totalFields
- 此数字在进入 Step 5 前锁定，Step 5 完成后将 spec 中字段规格表的字段总数与此值对比

对账通过条件：

✅ 页数对账: 基线 N=3, 已映射=3
✅ 区域完成度: 3页的 S/T/F/B/C/L 全部已枚举
✅ 字段数量对账: prototypeFieldCount=68, 已锁定至 manifest.json
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 三重对账全部通过 → phaseDVerified=true
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

对账失败处理：

> 🔴 三重对账全部通过后，将 manifest.json.phaseDVerified 设为 true，并将 prototypeFieldCount 写入 manifest.json。Step 5 入口检查此字段，false 则阻断。

原型解析失败降级策略

降级优先级：图片 MCP > 文字补充 > CHECKPOINT 确认。所有降级操作均需在 manifest.json 的 notes 字段记录降级原因与替代方案。

Step 5：模块规格生成

> 🔴 入口检查：进入 Step 5 前必须读取 manifest.json.phaseDVerified，其值必须为 true 才可进入。若为 false，则输出"Step 4 阶段D闭环对账未通过，无法进入模块规格生成，请返回 Step 4 完成对账"的阻断信息，禁止进入 Step 5。

5.1 公共代码值解析

识别需求/原型中的字典/枚举：
- 区分平台规范代码集（不生成SQL）与业务代码集（需生成INSERT SQL）
- 判别依据：字段名模式（*DM/*LX/ZT/*DJ/*FL）→ 规则见 Skill(pacp-rules, args="common-codes-standard 字段名模式")
- 🔴 CHECKPOINT：对识别出的业务代码集，汇总为"待确认代码集清单"，向用户确认：
- 清单为空（无非平台代码集字段）→ 跳过，直接生成 shared-dicts.spec.md
- 清单非空 → 展示每条代码集的字段名、字段中文名、所属实体，逐条询问：
- ① 用户是否确认该代码集存在？如确认则生成 INSERT SQL；如否认则标记为普通字段
- ② 用户是否提供具体选项值？如提供则写入码值明细；如不提供则使用占位符
- ③ 代码集编号是否同意自动推导的命名？如不同意则让用户指定
- 用户确认的取值写入 shared-dicts.spec.md 的码值明细表，子技能不再询问
- 生成 shared-dicts.spec.md（模板见 @@/skeletons/spec/shared-dicts-tpl.md）

5.2 创建目录结构与 manifest.json

• 批次目录：.pacp/{batch-id}/
• manifest.json：完整格式见 Skill(pacp-rules, args="manifest-format")。新增规格审批状态字段：specReviewed（boolean，是否已通过规格审批）、specReviewedAt（ISO 时间戳，审批通过时间）。Step 6 执行前必须检查 specReviewed === true。

5.3 生成模块规格文件

每个模块一份 modules/{所属业务}.{功能模块}.spec.md，包含10个标准章节，格式见 Skill(pacp-rules, args="spec-format")，模板见 @@/skeletons/spec/module-spec-tpl.md。
> 🔴 如确需在 spec 中做「需求文档级字段补录」，必须严格遵循 Skill(pacp-rules, args="spec-format") 的字段补录约束：仅补录需求文档中有但原型页面不展示的字段，禁止将原型已有的前端展示字段追加到补录中。补录字段仅在数据表 DDL 中体现，不在前端页面展示。

搜索区布局（原型未明确时，见 Skill(pacp-rules, args="frontend-search-layout") 的 3 种方案选择逻辑）：

> 🔴 原型已有布局 → 严格按原型，不选方案。原型未明确时 → 在第一个模块生成前一次性 CHECKPOINT，让用户选择项目统一的搜索区布局方案，存入 manifest.json.globalItems.searchLayout；后续所有模块直接读取该配置，不再重复询问。搜索条件仅 1 个的模块默认方案 C（无标签），不受全局配置影响。

🔴 组件选型确认：对字段规格表中「表单组件」列做最终审核：
- 命中强制绑定的字段（编号/字典/区划/行业/部门/用户/附件）→ 自动绑定，无需询问
- 普通字段（文本/数字/日期/开关）→ 按字段类型选默认组件，无需询问
- 有歧义的字段（如字段语义模糊、多个组件可选）→ CHECKPOINT：询问用户确认组件选型
- 最终确定的组件写入 spec 字段规格表「表单组件」列，子技能直接读取，不再询问

🔴 字段规格表关键列填值规则：
- 关联关系/数据来源 列：字典字段（*DM/*LX/ZT/*DJ/*FL 模式）必须填 字典:{代码集编号}（如 字典:MZDM），不得只填中文名；外键字段填 → {实体名}.{字段名}（如 → Station.XH）；普通字段填中文描述或 -
- 列表组件 列：字典字段必须填 enum（字典映射显值），禁止填 text 导致列表显示原始代码值；日期字段填 date；状态字段填 tag；普通文本填 text
- 上述两列的值直接影响子技能代码生成，填值错误将导致前端渲染异常或后端关联查询缺失

spec 生成原则：
1. 信息提取优先级（字段与功能层面）：原型 > 需求文字 > 智能默认值
2. 🔴 原型与平台标准冲突时：平台标准优先（如字段语义绑定、组件选型、命名规范等），在 CHECKPOINT 说明偏差并供用户确认；具体冲突分级见 Skill(pacp-rules, args="frontend-component-mapping 冲突分级")
3. 原型与需求矛盾时列入 CHECKPOINT（见 CHECKPOINT 表 #5），不擅自取舍
4. 未明确事项标注为"待澄清"，不在 spec 中擅自假设
5. 字段规格表、功能矩阵、布局清单的来源标注必须准确，供后续验证追溯
6. 多页可共表：多个页面可对应同一实体/表，每个页面只展示该表的部分字段，数据模型按实体聚合所有页面字段
7. 数据录入页面标注：每个实体的数据模型必须标注哪些页面负责录入数据（如"基本信息页、扩展信息页"），后端据此生成按页面字段集更新的 API，避免跨页空值覆盖
8. 🔴 功能矩阵 实现方式 列禁止填"是"：实现方式 列必须填写具体的交互方式——查询功能填 分页查询 + 条件过滤，新增/编辑填 弹窗表单 / 抽屉表单 / 页面跳转，删除填 逻辑删除 / 物理删除，禁止仅填"是"或留空。该列直接决定子技能生成的前端交互方式和后端接口形态
9. 🔴 字段关系约束表必填：凡字段之间存在联动关系、值依赖、互斥约束、范围/格式/唯一性校验的，必须在字段关系约束表中逐条声明，禁止仅写"有校验"或"有联动"而不列具体规则。缺失约束表将导致前端 :rules 校验不完整、后端 @NotNull/@Pattern/@Range 注解缺失
10. 🔴 功能字段映射表字段角色必须逐字段标注：新增功能的"必填/选填/系统自动"角色、编辑功能的"允许修改/禁止修改"角色，必须逐字段列出，禁止仅写"全部字段"或"同新增"。字段角色遗漏将导致编辑页所有字段都可改或都不可改，影响数据安全
11. 🔴 模块依赖关系双向表必填：模块依赖关系章节包含"依赖的模块"与"被依赖的模块"两张表，两张都必须填写，禁止只填"依赖的模块"跳过"被依赖的模块"。被依赖信息用于确保本模块的 API 设计兼容下游模块需求，避免本模块重构时破坏其他模块
12. 🔴 shared-dicts.spec.md 代码集编号与字段规格表一致：字段规格表 关联关系/数据来源 列中填写的 字典:{代码集编号}（如 字典:MZDM）必须在 shared-dicts.spec.md 中有一条对应的代码集定义（编号、名称、码值清单），两者编号必须逐字一致，禁止出现差异。生成完成后须两文件交叉核对，编号不一致的列为 CHECKPOINT 修正
13. 🔴 实体清单 数据录入页面 列必填：每个实体的 数据录入页面 列必须标注哪些页面负责录入该实体的数据（如"基本信息页、扩展信息页"），禁止留空。多页共表时尤为重要，后端据此生成按页面字段集更新的 API，避免跨页空值覆盖
14. 🔴 BvIdGenerator 的 seqName 与编号定义 BHMC 一致：字段规格表"表单组件"列标注 BvIdGenerator 的 *BH 字段，其字段中文名（如"站点编号"）同时作为前端 BvIdGenerator 的 seqName 入参和后端 t_admin_xtgl_sxhdy.BHMC 值，三者必须逐字一致。生成完成后须交叉核对：前端 detail.vue 中 seqName 值、后端编号定义 INSERT 中 BHMC 值、字段中文名三者一致，不一致的列为 CHECKPOINT 修正

5.3.1 规格文件自动一致性检查（🔴 代码化检查，不依赖 AI 自觉）

> 所有模块规格文件生成完成后，必须执行自动一致性检查，逐项验证 5 张关联表之间的跨文件一致性。检查项全部通过后进入 Step 5.4，若有未通过项则列为 CHECKPOINT 修正后重新检查。完整检查项清单见 @@/references/spec-consistency-check.md。

检查时机：每生成一个模块的规格文件后立即执行一次（增量检查），全部模块生成完成后执行一次全量检查。

🔴 核心检查项（每次检查必须逐项执行，禁止跳过或选择性执行）：

> 🔴 检查项 12 的详细计算方法：specFieldCount = 字段规格表中所有实体字段行数之和（含 6 个审计字段 XH/CJR/CJSJ/XGR/XGSJ/SFSC，不含表头/分隔线/空行）。prototypeFieldCount 来自 Phase B 枚举的 本页字段总数 之和。若 specFieldCount < prototypeFieldCount，说明原型中存在的字段在 spec 中遗漏了，必须返回 Phase B 确认遗漏字段并补充到 spec 中。

处理方式：

🔴 禁止跳过：consistencyCheckPassed 必须为 true 才能进入 Step 5.4。任何情况下（包括用户说"不用检查了"）都不允许跳过本检查——这是代码化检查，不依赖 AI 自觉，是防止规格内部不一致的最后一道代码级防线。

5.4 生成数据模型文档（data-model.md）

汇总整个项目的数据架构信息：
- 业务域关系
- 实体关系
- 跨模块引用
- 公共字典

5.5 生成模块规格汇总文档（modules-summary.md）

汇总所有模块的关键信息：
- 模块清单
- 实体清单
- 功能清单
- 依赖关系

5.6 生成测试数据规格文档（test-data.md）

定义各模块的初始化/测试数据生成规格：
- INSERT种子数据（供前端联调/演示）
- 生成规则：Skill(pacp-rules, args="sql-init-data")（§8 已抽出至独立子文件）
- 🔴 枚举值确认：扫描所有实体字段，识别自定义枚举字段（无平台码值池的字段），汇总为"待确认枚举值清单"
- 排除已在 Step 5.1 确认过的业务代码集字段（已写入 shared-dicts.spec.md 的不再重复询问）
- 清单为空 → 继续
- 清单非空 → CHECKPOINT：展示枚举字段清单（字段名 + 字段中文名 + 所属实体），询问用户合法取值
- 用户确认的取值写入 test-data.md 的字段取值映射表，子技能不再询问

5.7 生成功能菜单初始化规格（menu-init.spec.md）

根据已生成的模块规格，生成两级菜单结构：
- 业务级菜单：每个所属业务一条（FCDXH='ROOT', SFYZ='0', LJDZ=null）
- 页面级菜单：每个实体的前端页面一条（FCDXH=业务级XH, SFYZ='1', LJDZ=/admin/ + 前端路由路径）
- 路由一致性：菜单 LJDZ 加 /admin 前缀（如 /admin/{所属业务}/{功能模块}/{entity}-list），前端 router.js 的 path 无 /admin 前缀，两者不再逐字一致
- 表结构与模板：Skill(pacp-rules, args="common-codes-menu-init")
- SSXT 取值：从后端项目根目录 src/main/resources/application.yml 的 system.id 读取，见 Skill(pacp-rules, args="common-codes-menu-init")。若文件不存在或 system.id 未配置，默认值 'PACP'，在 CHECKPOINT 向用户确认。

5.8 生成编号定义规格（写入 shared-dicts.spec.md §4）

> 编号定义对应 t_admin_xtgl_sxhdy 表。识别到字段规格表中"表单组件"列标注 BvIdGenerator 的 *BH 字段时，须生成编号定义 INSERT SQL，规则见 Skill(pacp-rules, args="common-codes-id-generator")。

生成步骤：
1. 扫描 BvIdGenerator 字段：遍历所有模块规格的字段规格表，找出"表单组件"列标注为 BvIdGenerator 的字段（如 ZDBH 站点编号、FGBH 法规编号）
2. 读取 ORGID：从后端项目 src/main/resources/application.yml（或 application-{profile}.yml）读取 system.orgid 值（如 "000000"）；若均不存在则 CHECKPOINT 向用户确认
3. 填充 shared-dicts.spec.md §4：为每个编号字段在 shared-dicts.spec.md 的"编号定义"章节填充一行，包含编号名称(BHMC)、前缀格式、流水号格式、最小值、最大值、ORGID、所属模块、对应字段
4. 🔴 CHECKPOINT：汇总编号定义清单，向用户确认：
- 清单为空（无 BvIdGenerator 字段）→ 跳过
- 清单非空 → 展示每条编号定义的字段名、字段中文名、所属实体，逐条询问：
- ① 前缀格式是否同意默认值？如不同意则让用户指定
- ② 流水号格式（位数）是否同意默认值？如不同意则让用户指定
- ③ 最小值/最大值是否同意默认值（1~9999）？
- 用户确认的取值写入 shared-dicts.spec.md，子技能不再询问

5.9 规格审批（🔴 强制 CHECKPOINT，进入 Step 6 前必须通过）

> 所有规格文件生成完成后，必须暂停向用户展示完整规格概要，经用户确认后方可进入 Step 6 代码生成。这是代码生成前的最后一道质量关卡——Step 5 内部的碎片化 CHECKPOINT 覆盖的是逐项决策，本条覆盖的是整体视图。

触发条件：Step 5 全部子步骤（§5.1-§5.8）完成，即将进入 Step 6 时。

展示内容（禁止省略关键信息，必须逐项展示）：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 规格生成完成，请审批后进入代码生成
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1️⃣ 批次概览
   批次ID: {batch-id}
   业务数量: N
   模块数量: N
   实体数量: N
   数据库类型: {database_type}
   所属项目: {backend_project_dir} / {frontend_project_dir}

2️⃣ 模块清单
   模块A（{功能模块}.{中文名}）— {实体1}/{实体2} — 依赖: {依赖模块}
   模块B（{功能模块}.{中文名}）— {实体1}/{实体2} — 依赖: {依赖模块}
   ...

3️⃣ 实体关系（关键外键）
   {实体A} → {实体B}：1:N（外键: F_{TB}_XH）
   ...

4️⃣ 生成顺序（依赖拓扑排序）
   批次1: 模块A, 模块B（无依赖，可并行）
   批次2: 模块C（依赖模块A, 模块B）
   ...

5️⃣ 文件冲突策略: {overwrite | skip | ask}

6️⃣ 已确认的 CHECKPOINT 汇总
   ✓ 公共代码集: N 项已确认
   ✓ 组件选型: N 项已确认，N 项自动绑定
   ✓ 编号定义: N 项已确认
   ✓ 自定义枚举: N 项已确认
   ✓ 搜索区布局: 方案{ A | B | C }

==========================================
🔴 请确认是否按以上规格进入代码生成？
   [Y] 确认，开始生成
   [N] 需要修改（请说明修改内容）
   [S] 暂停，稍后恢复（保留 .pacp/ 状态）
==========================================

用户选择后的处理：

🔴 禁止跳过（不可绕过机制）：manifest.json.specReviewed 必须为 true 才能进入 Step 6。这是硬性阻断，不可绕过。

不可绕过的三层机制：

1. 代码级阻断：Step 6 入口第一条指令必须是：读取 manifest.json.specReviewed，若不为 true，立即中止并输出阻断信息，禁止执行任何后续代码生成操作。
2. 用户指令冲突处理：当用户发出"直接生成"、"不用看了"、"跳过审批"等指令时，技能规则优先级高于用户临时指令。AI 必须输出"规格审批未通过，无法进入代码生成。技能规则要求规格审批（§5.9）必须通过才能进入代码生成，这是不可绕过的质量关卡。请选择：[Y] 确认审批 / [N] 需要修改 / [S] 暂停"，并等待用户按上述选项之一回应。
3. 连续拒绝处理：若用户连续 3 次要求跳过审批，AI 输出"对不起，根据 pacp-spec 技能规则 §5.9，本步骤无法跳过。建议您：① 使用 [Y] 确认当前规格，进入代码生成；② 使用 [N] 提出修改意见，修改后重新审批；③ 使用 [S] 暂停，稍后处理。如需绕过本技能规则，请直接使用 pacp-coding 单模块协调技能（该技能无规格审批步骤）。"

任何情况下绕过本审批视为生成失败，manifest.json 中 specReviewed 保持 false。

Step 6：调用子agent生成代码

6.0 顺序生成策略与并行优化（🔴 核心铁律）

执行流程概要（完整伪代码见 @@/references/step6-generation-strategy.md）：

Step 1: 构建依赖图 → 拓扑排序分批（同批无依赖可并行）
Step 2: 文件冲突预检查 → CHECKPOINT 确认策略（覆盖/跳过/逐个确认）
Step 3: 逐批生成（两阶段并行）
  ├── 阶段A：同批所有模块后端并行生成
  │    └── 每个模块调用 pacp-coding-backend
  └── 阶段B：后端已完成的模块前端并行生成
       └── 每个模块调用 pacp-coding-frontend
Step 4: 全部模块完成后 → 生成项目级初始化 SQL

核心规则：
- 同批并行，分批串行（按依赖拓扑序）
- 模块内 backend → frontend 顺序执行，模块间同阶段并行
- 每完成一个模块立即更新 manifest.json status
- 失败模块保留已生成代码，提供重试/强制交付/中止三选一

关键约束（详见引用文件）：
- 并发写入保护：manifest.json 状态更新串行化 + updatedAt 时间戳校验
- 操作日志：.pacp/{batch-id}/.history/operations.log 记录每步操作
- 子技能不执行编译，编译由 Step 7 统一执行

Step 7：全局集成验证与交付

> 全部模块生成完成后，统一执行编译验证前的静态检查 → 编译 → 交付验证。

7.1 预编译检查（静态）

7.1.1 路由聚合检查：
- 路由路径是否唯一 → Grep "path:" 所有 router.js 文件，检查重复（排除动态参数 :xxx 部分后比较静态路径）
- 路由路径是否与菜单路径一致 → 读取 manifest.json 的菜单配置，对比路由路径（菜单 LJDZ 有 /admin 前缀，对比前先去掉）

7.1.2 菜单聚合检查：
- 菜单层级是否正确（两级：业务级 + 页面级） → 读取 shared-dicts.spec.md 菜单章节，校验层级
- 菜单是否覆盖所有实体 → 对比 manifest.json 的 entities 列表与菜单条目

7.1.3 跨模块一致性检查：
- 跨模块引用的字段是否存在 → Grep "F_\w+_XH" 检查外键字段，确认父实体在 manifest 中存在
- 外键引用的主键是否存在 → 对比外键字段与父实体表的 XH 字段定义
- 公共组件使用是否一致 → Grep "BvCommonCode.*setCode" 检查同一代码集是否用了不同的 setCode 值

7.1.4 公共组件去重检查：
- 重复的公共代码集是否已合并 → Grep "setCode" 汇总代码集编号，检查重复
- 重复的实体关系是否已统一 → 读取多个模块的 spec 文件实体关系章节，对比跨模块引用

7.2 统一编译验证（🔴 全部模块生成完成后执行一次）

编译命令见 Skill(pacp-rules, args="startup-service 编译验证")，按后端/前端分别在对应项目目录执行。

失败处理与编译错误速查：见 Skill(pacp-rules, args="compile-error-troubleshoot") 的速查表。

7.3 交付验证

• 产出物检查：规格文件、代码文件、SQL文件是否完整
• 业务一致性验证：是否符合需求文档的业务逻辑
• 原型一致性验证：是否与原型页面布局一致（Step 4的铁律）
• 测试数据一致性验证：初始化数据是否覆盖所有实体

Step 8：运行时验证与修复循环

> 编译通过后，启动前后端服务，在浏览器中验证页面渲染与功能，发现并修复运行态问题。详细执行规范见 @@/references/runtime-verification-loop.md。

8.0 数据库初始化（🔴 启动服务前执行）：从后端项目 src/main/resources/application.yml 读取 jdbc.default 配置（url/username/password），连接数据库，依次执行以下 SQL 脚本：
1. 模块 DDL：doc/db/business/{所属业务}/DDL/{db_type}-{功能模块}.sql（建表）
2. 初始化数据：doc/db/business/{所属业务}/DATA/{db_type}-{功能模块}-init.sql（种子数据）
3. 项目级初始化 SQL：doc/db/business/shared/{db_type}-shared-dicts.sql、{db_type}-menu.sql、{db_type}-attachment.sql、{db_type}-id-generator.sql（公共代码/菜单及菜单授权/附件类型/编）
> 若 jdbc.default 不存在或无法连接，触发 CHECKPOINT 向用户确认数据库连接信息。SQL 执行失败时中止并报告错误。

8.1 启动服务：按 Skill(pacp-rules, args="startup-service") 启动后端与前端。
8.1.5 API 接口测试与页面 URL 验证（🔴 启动后、浏览器验证前执行）：

> 登录认证：API 接口需要登录后才能访问。CHECKPOINT：向用户确认登录密码，默认账户 SYSTEM，密码由用户输入。获取 token 后，后续 API 请求在 Header 中携带 Authorization: Bearer {token}。

API 接口测试：登录成功后，对每个实体的标准 API 接口发起 curl 或 http 请求验证：
- 分页查询：GET /api/v2/business/{所属业务}/{功能模块}/{entity}/page?page=1&size=10 → 预期返回 { total, list } 结构，HTTP 200
- 新增：POST /api/v2/business/{所属业务}/{功能模块}/{entity} → 预期返回操作成功，HTTP 200
- 详情：GET /api/v2/business/{所属业务}/{功能模块}/{entity}/{id} → 预期返回实体数据，HTTP 200
- 修改：PUT /api/v2/business/{所属业务}/{功能模块}/{entity}/{id} → 预期返回操作成功，HTTP 200
- 删除：DELETE /api/v2/business/{所属业务}/{功能模块}/{entity}/{id} → 预期返回操作成功，HTTP 200
接口路径从占位符映射表和 @RequestMapping 注解派生，具体路径见 Skill(pacp-rules, args="system-module-path 接口契约")。所有请求需携带 Authorization Header。

页面 URL 验证：前端启动后，用 curl 或浏览器验证每个前端页面 URL 返回 HTTP 200（非 404/500）：
- 模块入口：http://localhost:端口/{所属业务}/{功能模块}
- 列表页：http://localhost:端口/{所属业务}/{功能模块}/{entity}-list
- 详情页：http://localhost:端口/{所属业务}/{功能模块}/{entity}-detail
> 若接口返回 4xx/5xx 或页面返回 404/500，记录错误到 .pacp/{batch-id}/.history/verify-errors.log，前端页面 404 的问题在 8.2 浏览器验证循环中修复。
8.2 浏览器验证循环：AI Loop（最多 3 轮），每轮检查页面渲染/Console/Network/布局/功能交互，发现问题自动修复后重试。退出条件：每轮完成后检查所有验证项，全部通过则提前结束本轮循环；3 轮后仍有未通过项，按 CHECKPOINT #10 处理。
8.3 验证项详细说明：见引用文件。
8.4 热更新与重启：见引用文件。
8.5 验证报告：通过后输出验证报告模板。

8.6 🔴 服务清理（验证完成后必须执行）：运行时验证全部完成后，必须关闭在前端和后端项目中启动的服务进程，释放端口。

清理步骤：
1. 关闭后端服务：在 {backend_project_dir} 下执行 netstat -ano | findstr :{后端端口} 找到 PID，然后 taskkill /F /PID {PID}（端口号从启动日志中提取，如 8080）
2. 关闭前端服务：在 {frontend_project_dir} 下执行 netstat -ano | findstr :{前端端口} 找到 PID，然后 taskkill /F /PID {PID}（端口号如 5173/8081 等）
3. 确认端口释放：再次执行 netstat -ano | findstr :{端口号} 确认进程已终止，无输出则清理成功
4. 记录操作日志：将服务关闭操作记录到 .pacp/{batch-id}/.history/operations.log

🔴 禁止跳过：即使验证失败（dry_run 模式或用户选择了"强制交付"），也必须执行服务清理。残留进程会占用端口，影响后续操作。

清理失败处理：若 taskkill 命令执行失败（如进程不存在、无权限），在验证报告中标注 ⚠ 服务清理状态：{成功/失败}，告知用户手动清理。

> 🔴 chrome-devtools-mcp 不可用时跳过浏览器验证，标注 dry_run。

版本管理

版本管理规范（触发条件、调整粒度、备份、stale 机制、spec 文件头格式）见 Skill(pacp-rules, args="spec-version-management")。

确认策略（🔴 CHECKPOINT）

默认自主执行原则：非重要决定自行判断，真正影响业务语义时才暂停确认。

仅在以下情况暂停向用户确认：

静默禁止：以上任一 CHECKPOINT 命中若不暂停而直接覆盖/继续 → 视为生成失败。

资源指针

外部规则库（pacp-rules，Skill 工具调用查询）

完整规则清单见 ../pacp-rules/references/INDEX.md。各步骤中已按需标注对应 Skill() 引用，此处不再重复列举。

本技能自包含资源

> @@/ 前缀表示本技能目录的根路径。例如 @@/skeletons/spec/ 解析为 {本技能目录}/skeletons/spec/。跨技能引用时，@@/ 始终指向被调用技能自身的根目录，而非调用方。

• 隔离机制：见本章「统一工作空间与隔离机制」
• 模块规格模板：@@/skeletons/spec/module-spec-tpl.md
• 骨架文件：@@/skeletons/spec/ 目录下的模板文件

兼容性说明

> 依赖关系：pacp-spec 依赖以下技能安装在同一个父目录下（如 skills/），否则子技能调用和骨架引用会失效：
> - pacp-rules（规则查询）
> - pacp-coding-backend（后端代码生成 + 初始化 SQL 生成）
> - pacp-coding-frontend（前端代码生成）
>
> 场景角色：pacp-spec 作为协调者被用户直接调用，适用于复杂多模块场景。单模块快速生成请用 pacp-coding。