PACP 动态列表规格设计器

解决什么问题

动态列表是后台系统最常见的交互形态，但「用户想要的列表」和「平台能渲染的配置」之间存在鸿沟。直接让 AI 生成列表配置 JSON，往往因缺少平台渲染契约知识（列类型映射、宽度语义、查询条件词汇）而产出无法直接构建的配置。业务方也常用口语、截图或 Excel 描述需求，信息零散，构建前需要反复确认。

pacp-design-list 把「规格设计」和「配置构建」拆开：只负责把模糊需求收敛成结构化的 list-spec.md，显式化列类型、宽度、查询条件等决策并标记不确定项；生成列配置 JSON、调 save 接口、提交平台交给下游 pacp-build-list。每一份 spec 都是可读、可审、可迭代的文档，而不是没人敢改的 JSON。

如何工作

核心流程分六步，探查是可选的。

输入处理：支持纯文本、图片、Word/PDF/Excel。图片和文档按 references/doc-and-image-input.md 规范提取列名、显示名、查询条件和按钮，产出 spec 而非构建配置。

意图解析与草稿：从口语和表注释提取元信息（主表、关联表、关联关系、主键）、列定义、查询条件和操作按钮。AI 推断的列类型、宽度、查询条件主动标「⚠️ 推断」，减少来回确认。

可选探查：用户没给表名或列名时触发。探查表用 getTables 模糊匹配，探查列用 getColumns，结果存到 .pacp/active/{业务名}_{时间戳}/table-info.md。需要 session 时调 pacp-system-login（基于 chrome-devtools MCP）获取 JSESSIONID 写入 .pacp/session.json，供下游复用。

质量门自检：草稿产出后必须跑完整性自检清单，检查元信息、列定义、查询条件、操作按钮、系统列显式声明、选择框与批量删除配套关系等。缺项不落盘；代码集编号当场给不出允许标「待定」延后到 build 阶段。

用户核对至定稿：展示草稿，自然语言迭代，用户说「可以」即定稿。

落盘：写入 .pacp/specs/动态渲染/{业务名}__列表.md，返回业务名。列表 spec 统一加 __列表 后缀，与表单 spec 的 __表单 后缀区分。

关键约束与注意点

职责边界：只产出 spec，不构建列表、不调 save 接口、不提交平台、不打开列表页面。终点是 spec 落盘，并告知用户后续用 pacp-build-list 构建。

不读源码：数据来源是远程 API（按需探查）、SKILL.md 和用户输入。禁止读取本 Skill 的 lib/scripts 和项目业务代码。

工作根目录：所有 pacp-* skill 共用 .pacp/ 目录，定位在 AI 运行时 cwd 下。只读写工作文件，不触碰项目其他文件。

词汇表封闭性：列词汇、宽度语义、查询条件词汇都是封闭集合，build 阶段映射为精确配置。选择框列和批量删除按钮必须配套声明，缺一会导致制成品残缺。

平台知识权威源：列词汇背后的渲染契约、LX 类型机制在 pacp-dynamic-wiki skill，选词不确定时查 5x/list-render-contract.md 等文档。

选择器列表特殊规则：列表用途为「选择器」时必须写选择器配置段，声明可回填字段（能力声明，必须带括注）。隐藏列（如主键 XH）需以 显示：否 显式声明，供回填但不展示。