动态列表构建器

解决什么问题

pacp-build-list 处理的是一个反复出现、却容易翻车的运维动作：在远程 PowerData 平台上创建或修改列表查询配置。这类配置散落在平台侧——表结构、字段元数据、代码集、查询条件、列展示规则——本地代码库里没有任何线索。让 AI 像写业务代码那样先 ls、rg 探查项目，只会读到一堆无关源码，既浪费 token，又容易基于错误假设产出跑偏的配置。

更隐蔽的坑是"凭感觉构建"。一个列表看起来只有几列，似乎可以直接生成，但列类型、列宽、查询条件、主键没确认前，生成的配置大概率在线上查询报错或展示错乱。这个技能用一道硬门槛堵住这条路：新增列表必须从 list-spec.md 出发，禁止从口语或图片直接推断。

核心能力与关键步骤

技能把工作拆成两条入口，启动时先分流：

• 新增入口（spec 驱动）：唯一输入是 list-spec.md。AI 读 spec → 产出列对照表 field-mapping.md → 生成 list-config.json → 喂给 CLI。
• 修改入口（XH 驱动）：用户给列表 XH 和修改意图。有 spec 时改 spec 后重建覆盖线上；没有 spec 时直接拉线上配置修改，不回写 spec，并提示后续用 pacp-design-list 补 spec。

两条入口都遵循"spec → config 在会话内完成映射"的约定，AI 产出列对照表保证过程可审计。构建前有一道轻量闸门：校验 spec 的元信息段和列定义段存在且非空。

列组件方面，技能内置了自包含的列工厂：seq、checkbox、operate、commonCode、date、普通数据列。CLI 根据 DATA_TYPE 自动推断 colType，只有需要覆盖推断时才显式指定。列宽有参考规则：2 字以内 5%，日期列 12%，长文本列 18-20%，总宽约 100%。

复杂查询在 spec 层解决：

• 多表 JOIN：spec 元信息记录主表、关联表、关联关系（字段对应），构建时据此拼接 sqlSelect 和 ON 条件。表别名自动派生，关联关系缺失时停止询问，不靠命名猜测。
• 聚合查询：SUM/COUNT/MAX 列必须用 AS 别名，sqlGroupBy 必须包含所有非聚合列，聚合列需显式指定 colType。

关联表单的 templateId 不是设计阶段填的——spec 的「关联表单」字段填的是表单 spec 文件名，构建前再去该表单 spec 的「构建记录」段取 templateId，把依赖推迟到构建阶段。

边界与注意点

这是远程配置任务，不是本地代码开发。几条硬约束值得记住：

• 不读源码。数据源只有远程 API、SKILL.md 和用户输入。lib/、scripts/ 下的 .js 是运行时代码，不需要也不允许用 read_file 查看。
• 只用 CLI。所有操作必须通过 list_creator.js 或 BwaiClient API 完成，不允许自行编写脚本绕过。CLI 报错就直接报告。
• 代码集编号必须用户给。dmjbh 由用户明确指定，spec 标「待定」就停下来问，不允许 AI 根据字段语义推断。
• sqlWhere 默认 1=1。除非用户明确要求，不自行添加过滤条件——不确定表中是否存在该列。
• SQL 方言敏感。sqlSelect / sqlWhere / sqlOrderBy 使用 ANSI SQL 通用写法，方言语法需先确认目标数据库类型。
• 重建覆盖线上前需确认。列表曾被绕过 spec 直接在线上改过时，"走 spec 重建"会用 spec 覆盖线上手工改动。
• 临时文件只在工作区。所有生成的文件写入 .pacp/active/{业务名}_{时间戳}/。
• Excel 导入后端资源不编造。jsonFilePath / importExcelService / templatePath 必须由用户提供。

会话层面，所有 pacp-* skill 共用 .pacp/ 作为工作根目录，通过 .pacp/session.json 共享 JSESSIONID。