@done-coding/admin-core 0.0.1-alpha.0

package/docs/specs/2026-05-09-055250-moderate-/345/210/227/350/241/250key/351/205/215/347/275/256/347/202/271/350/267/257/345/276/204/346/224/257/346/214/201/landing-authorizations/2026-05-09-080900-/346/234/2371-/345/205/245/345/256/236/346/226/275/346/216/210/346/235/203.md

@@ -0,0 +1,107 @@
+---
+task_type: 产研交付型
+task_subtype: 常规需求
+authorization_time: 2026-05-09 08:09:00
+---
+
+# 落地助理授权记录
+
+> 本次授权场景：批次一开发实施前入实施授权（整体 3 批次执行准备就绪）
+> 文件命名：2026-05-09-080900-期1-入实施授权.md（首次助理介入，目录此前为空）
+> 跨实例一致性：本次为该 specs 目录下首次授权记录，无历史授权可冲突，跳过冲突检查（按 ADR-T3-2 / REQ-1.3 规则 5）
+
+---
+
+## 第一部分：内部记录(完整留痕)
+
+| 字段 | 值 |
+|---|---|
+| 授权时间 | 2026-05-09 08:09:00 |
+| 授权对象 | packages/core/docs/specs/2026-05-09-055250-moderate-列表key配置点路径支持/ — 批次一开发实施前入实施授权（整体 3 批次执行准备就绪：批次一 core 类型工具+配置+文档；批次二 app 切源+table 改造；批次三 验证）|
+| 提交人 | pm-delivery |
+| 实际执行人 | 落地助理（boss-landing-assistant） |
+| 授权决定 | 放行 |
+| pre_guard_reject | false |
+| pm_self_check_deviation | false |
+
+### PM 自查 5 项风险检查结果（PM 提交时填）
+
+| # | 风险检查项 | 判定 | 依据 |
+|---|---|---|---|
+| 1 | 是否重大问题？ | 否 | 项目层（packages/core + packages/app）业务代码改造，未触发 M2 要件清单任一项：未新增/删除/重命名 agent 文件；未修改宪法；未新增 [MUST]/[MUST NOT] 体系层条款；未影响 ≥3 个 agent frontmatter；未引入新审核节点触发机制；未变更归档协议；未改变核心契约（glossary 术语定义）；影响角色 = 4（PM + 架构师 + 全栈开发 + 测试）属 Moderate 默认调度组合，未引入新协作流程 |
+| 2 | 是否不可逆？ | 否 | 所有改动 git 可回滚（新建 git rm / 修改 git checkout）；无 schema 迁移、无外部 API 调用、无数据持久化变更 |
+| 3 | 是否不可修复？ | 否 | 错误检测三道防线即时——vue-tsc 类型错误编译时立即可见 / pnpm build 失败立即可见 / 业务页 dev 启动错误立即可见；错误发现后可在 review 阶段或后续 TASK 修复 |
+| 4 | 是否可预见重大返工？ | 否 | 实现样例已在 requirements.md 全部锁定，design.md 未偏离；单 TASK ≤ 3 文件 ≤ 5 步骤，单 TASK 返工成本极低；最坏情况 BuildListParams 工具签名有边界 bug，影响范围仅本任务 7 文件，重做成本 ≤ 1 工作日 |
+| 5 | 是否不可搁置？ | 否 | 本任务是期 #2 table/list-page 迁移的前置，但期 #2 尚未启动；当前期内可搁置；任务内部 3 批次（core 工具 / app 切源 / 文档）相对独立，单批延迟不阻塞其他批次 |
+
+#### 重大问题判定要件清单（M2 - PM 自查"重大风险检查"逐项勾选结果）
+
+- [x] 是否新增 / 删除 / 重命名 `~/.claude/agents/` 下的 agent 文件？— **否**（仅 packages/core + packages/app 业务代码 + core/docs/ 项目级文档）
+- [x] 是否修改 `~/.claude/rules/company-constitution.md`？— **否**
+- [x] 是否新增或废止 `[MUST]` / `[MUST NOT]` 条款？— **否**（NG-1 ~ NG-7 是项目级约束，写在 requirements.md 中，不进入体系层规则文件）
+- [x] 是否影响 ≥3 个 agent 的 frontmatter 字段？— **否**
+- [x] 是否引入新的审核节点触发机制？— **否**
+- [x] 是否变更归档协议步骤？— **否**
+- [x] 是否改变核心契约（宪法 / glossary 中的术语定义 / 三层架构边界）？— **否**
+- [x] 是否影响 ≥3 个角色的协作流程？— **否**（4 个角色但属 Moderate 默认调度组合，未引入新协作流程）
+
+> 8 项要件全否 → 重大风险检查判定为"否"。
+
+### 5 项风险检查复核结果（助理填）
+
+| # | 风险项 | 助理判定 | 助理依据 |
+|---|---|---|---|
+| 1 | 重大风险检查（影响 ≥3 角色 / 改变核心契约 / 引入新协议触发机制） | 否 | 独立判定：(a) 任务范围严格限定项目层 packages/core + packages/app + core/docs/，未触达 ~/.claude/ 任一文件；(b) M2 要件清单 8 项逐项核查均否（与 PM 自查结论一致，独立验证）；(c) 影响角色 4 个均为 Moderate 默认调度组合（PM + 架构师 + 全栈开发 + 测试），未引入跨角色新协作机制；(d) NG-1 ~ NG-7 是项目级业务约束，写在 requirements.md 中，不外溢到体系层；(e) 设计审核简化路径是用户在本次 specs 内的特例裁决，未改变体系层默认设计审核五步流程，不构成"改变核心契约" |
+| 2 | 不可逆风险检查（执行后无法回滚） | 否 | 独立判定：(a) Direct Targets 8 处全为代码/文档变更——3 处新建（git rm 即可清除）+ 5 处修改（git checkout 即可恢复）；(b) 无 schema 迁移 / 无外部 API 调用副作用 / 无数据持久化变更 / 无依赖发布变更（lodash 已在 core peerDependencies）；(c) Self-Healing Rule 规定二次失败停下汇报，单步可控 |
+| 3 | 不可修复风险检查（错误产生后无路径修正） | 否 | 独立判定：错误检测路径完整——(a) 类型层错误由 vue-tsc 编译期捕获（TASK-3.1 验证）；(b) 构建错误由 pnpm build 立即捕获（TASK-3.2 验证）；(c) 运行时错误由 app dev + 业务页回归捕获（TASK-3.3 验证）；任一层错误均可定位到具体 TASK 重做修复，无"错误产生后无路径修正"风险 |
+| 4 | 重大返工风险检查（返工量不可接受） | 否 | 独立判定：(a) requirements.md 已逐 REQ 锁定实现样例（用户多轮确认记录见末尾表）；(b) design.md 未偏离 requirements.md，所有类型与运行时改造样例 1:1 对应；(c) tasks.md 拆分 11 TASK 每个 ≤ 1 文件 ≤ 5 步骤，单 TASK 返工成本极低；(d) 最坏返工范围（BuildListParams 工具签名 bug）仅 7 文件，重做 ≤ 1 工作日，可接受 |
+| 5 | 不可搁置风险检查（无并行任务可推进，搁置即硬阻塞） | 否 | 独立判定：(a) 本任务是期 #2 table/list-page 迁移前置，但期 #2 尚未启动，搁置不阻塞当前期下游；(b) 任务内部 3 批次（core 工具/app 切源/文档）相对独立，单批延迟不阻塞其他批次；(c) 用户随时可暂停转去做其他子项目工作，存在并行任务空间 |
+
+> 助理复核结论：5 项风险检查全否，与 PM 自查结论一致，无 pm_self_check_deviation 触发。
+
+### 前置守卫第 3 项：上游审核合规校验结果（助理填）
+
+| 字段 | 值 |
+|---|---|
+| 上游审核合规校验 | 已满足 |
+| PM 申请字段值 | 已通过（PM 提交内容含"上游审核状态: 已通过（用户 2026-05-09 整体通过）"，与 requirements.md frontmatter「状态: 已审核通过」+ design.md frontmatter「审核状态: 已通过」+ project-orchestration.md「上游审核状态: 已通过」三处一致） |
+| 合法值集合检测 | 通过（"已通过" ∈ {已通过, 未通过, 审核中}） |
+| 校验结论 | 通过 |
+
+> 设计审核简化路径合规性补注：design.md frontmatter `reviewer` 字段如实记录"architect 自查（用户 2026-05-09 裁决简化设计审核——不走 reviewer subagent，不走开发/测试/产品上下游预审）"——这是用户主动裁决的合规路径（按宪法第一章「务实」+「先起飞」原则——决策层范围裁剪范畴），合规性检测对字段存在 + 字段值合法集合做检验，不验证字段值真实性（按 boss-landing-assistant.md 前置守卫第 3 项规则）；本助理依规放行。
+
+### 决定路径
+
+- pre_guard_reject = false（前置守卫 3 项全通过）
+- 助理复核全为"否" + PM 自查全为"否" → **授权放行，通知 PM 继续推进**
+- pm_self_check_deviation = false（无偏差）
+
+### 前置守卫 3 项校验结果（汇总）
+
+| # | 检查项 | 校验结果 | 备注 |
+|---|---|---|---|
+| 1 | 格式校验（含 task_subtype 字段合规性检测）| 通过 | PM 提交内容含完整 5 项风险检查表 + 每条依据非空；frontmatter task_type=产研交付型 / task_subtype=常规需求（值 ∈ {常规需求, 重构需求} 集合）；授权对象描述明确（批次一开发实施前入实施授权）|
+| 2 | 漂移校验 | 通过 | PM 提交 5 项风险检查表条目数=5（与标准版一致）/ 条目原文与 boss-landing-assistant.md 5 项风险检查复核清单一致 / 顺序一致 / 任务路径与 design.md `Direct Targets` 范围一致（packages/core + packages/app + core/docs/，未越界）|
+| 3 | 上游审核合规校验 | 通过 | 详见上方"前置守卫第 3 项"专表 |
+
+### 助理 5 项复核 vs PM 自查一致性比对
+
+| # | 风险项 | PM 自查 | 助理复核 | 一致性 |
+|---|---|---|---|---|
+| 1 | 重大风险检查 | 否 | 否 | ✓ 一致 |
+| 2 | 不可逆风险检查 | 否 | 否 | ✓ 一致 |
+| 3 | 不可修复风险检查 | 否 | 否 | ✓ 一致 |
+| 4 | 重大返工风险检查 | 否 | 否 | ✓ 一致 |
+| 5 | 不可搁置风险检查 | 否 | 否 | ✓ 一致 |
+
+> 5/5 全一致，无 pm_self_check_deviation 触发。
+
+---
+
+## 第二部分：对外签字（脱敏）
+
+| 项 | 值 |
+|---|---|
+| 审核状态 | 审批通过 |
+| 审核时间 | 2026-05-09 08:09:00 |
+| 适用范围 | 列表 KEY 配置点路径支持任务 — 批次一开发实施前入实施授权（整体 3 批次执行准备就绪）|

package/docs/specs/2026-05-09-055250-moderate-/345/210/227/350/241/250key/351/205/215/347/275/256/347/202/271/350/267/257/345/276/204/346/224/257/346/214/201/project-orchestration.md

@@ -0,0 +1,58 @@
+---
+任务名称: 列表 key 配置点路径支持
+任务路径: packages/core/docs/specs/2026-05-09-055250-moderate-列表key配置点路径支持/
+任务等级: Moderate
+任务类型: 产研交付型
+任务子类型: 常规需求
+当前状态: 需求阶段
+日期: 2026-05-09
+PM: pm-delivery
+---
+
+# 项目调度文档
+
+## 一、调度状态
+
+| 字段 | 值 |
+|---|---|
+| 当前阶段 | 已归档 |
+| 当前批次 | — |
+| 下一动作 | （任务关闭，期 #2 已立项启动）|
+| 上游审核状态 | 设计审核已通过（架构师 2026-05-09 08:03 自查通过）|
+| 审核通过日期 | 2026-05-09 |
+| 设计审核路径 | 简化为架构师 agent 自查自纠（用户 2026-05-09 裁决）|
+| 落地助理授权 | ✓ 放行（2026-05-09 08:09，5 项风险检查全否，前置守卫 3 项全过）|
+| 授权记录路径 | `<specs>/landing-authorizations/2026-05-09-080900-期1-入实施授权.md` |
+
+## 二、进度概览
+
+| 批次 | 主题 | TASK 数 | 已完成 | 完成率 | 状态 |
+|---|---|---|---|---|---|
+| 批次一 | core 类型工具 + 配置下沉 | TBD（设计阶段确定）| 0 | 0% | 待启动 |
+| 批次二 | app 端切源 + table 运行时改造 | TBD | 0 | 0% | 待启动 |
+| 批次三 | core 文档（TECH_SNAPSHOT + README）| TBD | 0 | 0% | 待启动 |
+| **合计** | | **TBD** | **0** | **0%** | — |
+
+## 三、过程摘要（仅产研 PM）
+
+| # | 里程碑 | 时间 | 关键产出 | 风险信号 | 备注 |
+|---|---|---|---|---|---|
+| 1 | 需求阶段启动 | 2026-05-09 05:52 | requirements.md 起草完成（PM 整理多轮对话锁定的 7 REQ + 6 NG）| — | 用户已多轮锁定关键决策（KEY 取值 / core 单一来源 / pnpm patch 逃生 / 业务壳层禁下沉）；PM 整理为结构化文档 = 调度产物 |
+| 2 | 需求阶段完成 | 2026-05-09 07:58 | 7 REQ + 7 NG 全部 ✅；用户裁决简化设计审核与代码审查为「同 agent 自查自纠」；新增 NG-7（禁手写字面量）| — | 用户长期偏好已写入记忆：「先问原则，按原则推下游」 |
+| 3 | 设计阶段完成 | 2026-05-09 08:03 | design.md 5 ADR + 11 TASK 预案 + 6 风险 + 自查 8/8 | — | 架构师 agent 自查通过，frontmatter 标审核通过 |
+| 4 | 落地助理放行 | 2026-05-09 08:09 | 5 项风险检查全否 + 前置守卫 3 项全过 | — | 授权记录 `landing-authorizations/2026-05-09-080900-期1-入实施授权.md` |
+| 5 | 实施阶段完成 | 2026-05-09 08:21 | 11 TASK / 21 步骤 / 0 待办；vue-tsc + build core/app + dev app 全通过 | mock bug（按 Self-Healing 修复）+ app/config/index.ts barrel 追加（design §3.3 显式允许）— 均在 tasks.md 留痕 | 全栈开发自查 8/8 通过；待用户最终验收 |
+
+## 四、各角色非制度型反馈区
+
+### PM 反馈
+（暂无）
+
+### 架构师反馈
+（待派发）
+
+### 全栈开发反馈
+（待派发）
+
+### 测试反馈
+（待派发）

package/docs/specs/2026-05-09-055250-moderate-/345/210/227/350/241/250key/351/205/215/347/275/256/347/202/271/350/267/257/345/276/204/346/224/257/346/214/201/requirements.md

@@ -0,0 +1,238 @@
+# 需求文档：列表 key 配置点路径支持
+
+> 状态：已归档（用户 2026-05-09 同意立项期 #2 含本前置任务验收通过；RETROSPECTIVE 已落盘）
+> 任务等级：Moderate
+> 任务子类型：常规需求
+> 日期：2026-05-09
+> 参与角色：PM + 架构师 + 全栈开发专家 + 测试专家
+> 项目调度文档：`<specs>/project-orchestration.md`（PM 维护，派发批次前后写入）
+> 用户称呼：用户（本会话称呼约定，不使用「老板」）
+
+## 背景
+
+### 当前状态
+
+`packages/app/src/config/request.ts` 中维护 `APP_API_LIST_MODEL_KEY_CONFIG` 列表分页 KEY 平铺配置：
+
+```ts
+APP_API_LIST_MODEL_KEY_CONFIG = {
+  PAGE_SIZE_KEY: "pageSize" as const,
+  CURRENT_PAGE_KEY: "currentPage" as const,
+  TOTAL_KEY: "total" as const,
+  LIST_KEY: "list" as const,
+}
+```
+
+`TableMain.vue` 通过 `[KEY]` 直接索引：
+
+```ts
+[APP_API_LIST_MODEL_KEY_CONFIG.PAGE_SIZE_KEY]: pageSize.value
+res[APP_API_LIST_MODEL_KEY_CONFIG.LIST_KEY]
+```
+
+类型层 `AppApiListModel<T>` / `TableApiParams<SQ>` / `TableApiResult<T>` 通过 `[KEY]: V` 索引签名生成单层结构。
+
+### 真实接口契约
+
+本公司分页接口实际契约：
+
+- **请求**：`{ page: { page: number, pageSize: number, query?, orderBy?, ... }, ...业务参数 }`
+- **响应**：`{ items: T[], page: { totalRecord: number, pageSize: number, totalPage: number } }`
+
+当前平铺 KEY 配置无法表达「分页参数嵌入 page 子对象」这一结构，业务侧每个调用 table 的页面都需手工拼装嵌套结构 → 与 `props.query` / 表格组件分页参数传出脱节。
+
+### 目标
+
+升级 KEY 配置能力支持点路径写法（如 `"page.page"`），类型层与运行时同步改造：
+
+- 类型层：`"page.page"` → `{ page: { page: number } }`，多个 page.xxx 合并为同一 page 对象
+- 运行时层：通过 `lodash/get` / `lodash/set` 操作嵌套路径
+- 当 KEY 不含 `.` 时（如 LIST_KEY = `"items"`）退化为单层 `{ items: T[] }`，与现状等价 → 零行为破坏
+
+### 架构方向（用户已锁定）
+
+| 决策 | 取值 | 理由 |
+|---|---|---|
+| KEY 配置归属 | core 单一来源，app 直接 import | 取消双份维护，消除漂移根因 |
+| LIST_KEY 取值 | `"items"`（外层平铺）| 实际响应数据在外层 items |
+| 其他 3 个 KEY | `"page.page"` / `"page.pageSize"` / `"page.totalRecord"` | 嵌入 page 子对象 |
+| 类型工具归属 | core 提供，app + core 同用 | core 自身列表模型也用，不双份 |
+| 自定义分页字段 | pnpm patch 逃生通道 | 不引入 IoC，保持 core 简洁 |
+| TECH_SNAPSHOT 文档 | core 起步版新建 | 沉淀「分页 KEY 固化」约束与背景 |
+
+## 功能需求
+
+### REQ-1：dot-path 类型工具下沉 core
+
+WHEN core 包需要表达从字符串路径到嵌套对象类型的推导
+THE SYSTEM SHALL 在 `packages/core/src/types/dot-path.ts` 提供下列泛型工具并通过 `core/src/index.ts` re-export：
+
+| 工具 | 签名 | 行为 |
+|---|---|---|
+| `DotToObject<P, V>` | `<P extends string, V>` | `"a.b.c"` → `{ a: { b: { c: V } } }`；`"x"` → `{ x: V }` |
+| `UnionToIntersection<U>` | `<U>` | 联合类型转交叉，用于多个 DotToObject 结果合并 |
+| `BuildListModel<KC, T>` | `<KC, T>` | 基于 KEY_CONFIG 联合推导完整列表响应模型（高阶组合工具） |
+| `BuildListParams<KC, P>` | `<KC, P>` | 基于 KEY_CONFIG 联合推导列表请求参数模型 |
+
+- 验收标准：
+  - vue-tsc 通过
+  - 单元类型断言：`Equal<DotToObject<"page.page", number>, { page: { page: number } }>` 为 true
+  - 单元类型断言：`Equal<DotToObject<"items", T[]>, { items: T[] }>` 为 true
+  - 多 key 合并：`UnionToIntersection<{a:{x:1}} | {a:{y:2}}>` 推导为 `{a:{x:1,y:2}}`
+
+### REQ-2：列表 KEY 配置下沉 core 单一来源
+
+WHEN core 包统一维护列表分页 KEY 配置
+THE SYSTEM SHALL 在 `packages/core/src/config/list-model.ts` 提供 `APP_API_LIST_MODEL_KEY_CONFIG` 作为**唯一来源**，配置形态：
+
+```ts
+export const APP_API_LIST_MODEL_KEY_CONFIG = Object.freeze({
+  CURRENT_PAGE_KEY: "page.page" as const,
+  PAGE_SIZE_KEY:    "page.pageSize" as const,
+  TOTAL_KEY:        "page.totalRecord" as const,
+  LIST_KEY:         "items" as const,
+});
+```
+
+- 验收标准：
+  - `packages/app/src/config/request.ts` 中不再独立定义 `APP_API_LIST_MODEL_KEY_CONFIG` / `AppApiListModel` / `AppApiListParamsModel` / `AppApiListPageParamsKey` / `AppNoPageParamsKey` 5 项
+  - 上述 5 项通过 `from "@done-coding/admin-core"` re-export 维持 `@/config` 消费面不破
+  - app `request.ts` 中仅保留：`APP_REQUEST_CONFIG` / `APP_API_BUSINESS_MODEL_KEY_CONFIG` / `AppApiBusinessModel`（业务壳层 3 项）
+  - `pnpm build` 在 core 与 app 双向通过
+
+### REQ-3：列表参数与结果类型工具
+
+WHEN core 包对外提供列表请求/响应类型推导
+THE SYSTEM SHALL 在 `packages/core/src/config/list-model.ts` 提供：
+
+| 类型 | 推导结果（基于本次 KEY 配置）|
+|---|---|
+| `AppApiListModel<T>` | `{ items: T[]; page: { page: number; pageSize: number; totalRecord: number } }` |
+| `AppApiListParamsModel<P>` | `P & { page: { page: number; pageSize: number } }` |
+| `AppApiListPageParamsKey` | `typeof KEY.PAGE_SIZE_KEY \| typeof KEY.CURRENT_PAGE_KEY` 即 `"page.pageSize" \| "page.page"` |
+
+- 验收标准：
+  - 类型断言通过：`AppApiListModel<{id:1}>` 等价于 `{items:{id:1}[]; page:{page:number; pageSize:number; totalRecord:number}}`
+
+### REQ-4：TableApiParams / TableApiResult 类型重写
+
+WHEN table 组件类型描述请求/响应结构
+THE SYSTEM SHALL 在 `packages/app/src/components/table/types.ts` 中：
+
+- 移除 `[APP_API_LIST_MODEL_KEY_CONFIG.XXX_KEY]: V` 直接索引签名
+- 改用 core 提供的 `BuildListParams<KC, SQ>` / `BuildListModel<KC, T>` 工具推导
+
+最终行为：
+
+```ts
+// 推导后等价
+TableApiParams<SQ> = SQ & { page: { page: number; pageSize: number } }
+TableApiResult<T>  = { items: T[]; page: { totalRecord: number } }
+```
+
+- 验收标准：
+  - vue-tsc 通过
+  - 调用 table 的所有页面（如 Page1.vue 等）类型不破
+
+### REQ-5：TableMain.vue 运行时 lodash 改造
+
+WHEN table 组件读写分页参数与列表数据
+THE SYSTEM SHALL 通过 `lodash/set` 写入分页参数，通过 `lodash/get` 读取响应数据。
+
+具体改造点（4 处）：
+
+| 位置 | 当前写法 | 改造后 |
+|---|---|---|
+| `params` computed 构造 | `[KEY.PAGE_SIZE_KEY]: pageSize.value` | `_set(merged, KEY.PAGE_SIZE_KEY, pageSize.value)` 在 `_cloneDeep(props.query \|\| {})` 基础上累积 |
+| `params` computed 构造 | `[KEY.CURRENT_PAGE_KEY]: currentPage.value` | `_set(merged, KEY.CURRENT_PAGE_KEY, currentPage.value)` |
+| 响应数据读取 | `res[KEY.LIST_KEY]` | `_get(res, KEY.LIST_KEY)` |
+| 响应总数读取 | `res[KEY.TOTAL_KEY]` | `_get(res, KEY.TOTAL_KEY)` |
+
+- 验收标准：
+  - `pnpm build` 通过
+  - 业务页面表格分页/搜索/排序行为与改造前等价
+  - `props.query` 中已存在 `page.query` / `page.orderBy` 等字段时，组件 `_set` 不丢失原字段
+
+### REQ-6：core docs/TECH_SNAPSHOT.md 起步版
+
+WHEN core 包首次维护技术快照
+THE SYSTEM SHALL 新建 `packages/core/docs/TECH_SNAPSHOT.md`，至少含下列章节：
+
+1. **设计边界**：明确 core 范围（通用 admin 基础设施 / 通用分页结构 / dot-path 类型工具 ✓；业务壳层 / 业务枚举 / 业务路由 / IoC 注入 ✗）
+2. **已知约束**：分页 KEY 固化 + pnpm patch 逃生通道说明
+3. **类型工具说明**：DotToObject / UnionToIntersection / BuildListModel / BuildListParams 用法
+4. **架构决策记录 (ADR)**：本次任务关键决策的背景与否决方案
+
+- 验收标准：
+  - 文档结构完整，4 章节全在
+  - "禁止业务壳层下沉" 在设计边界节明文出现
+  - "pnpm patch 逃生通道" 在已知约束节明文出现并附最小步骤
+
+### REQ-7：core README.md 进阶用法节
+
+WHEN core 消费方需要自定义分页字段
+THE SYSTEM SHALL 在 `packages/core/README.md` 追加「自定义分页字段（pnpm patch 逃生通道）」节，提供：
+
+- 一句话定位：core 分页 KEY 配置固化，自定义需走工具链层 patch
+- pnpm patch 最小步骤示例
+- 警示：[MUST NOT] 通过业务运行时配置覆盖 KEY，理由——失去类型推导能力
+
+- 验收标准：
+  - 文档章节完整可阅
+  - 与 TECH_SNAPSHOT 「已知约束」节交叉引用
+
+## 非目标 (Non-Goals)
+
+| # | 内容 | 理由 |
+|---|---|---|
+| **NG-1** | [MUST NOT] 将业务壳层（`APP_API_BUSINESS_MODEL_KEY_CONFIG` / `AppApiBusinessModel` / code / message / data 类型/常量）下沉 core | 业务特征，必须留 app；core 设计边界硬规则 |
+| **NG-2** | [MUST NOT] 引入 IoC 注入式 KEY 配置（plugin install 选项注入 / createAdminCore 工厂等）| 用户裁决：一个月内不考虑；当前用 pnpm patch 逃生通道兜底 |
+| **NG-3** | [MUST NOT] 在本次任务迁移 table / list-page 组件本身（仍留 app 包内）| 期 #2 主体迁移任务，本次仅前置升级 KEY 配置能力 |
+| **NG-4** | [MUST NOT] 修改 KEY 值含义之外的 `request.ts` 业务码/消息体/拦截器配置 | 范围外，避免变更扩散 |
+| **NG-5** | [MUST NOT] 实际改 KEY 值为点路径之外的形态（如自动支持 `["a","b"]` 数组路径）| YAGNI；当前 lodash get/set 接受字符串路径已足够 |
+| **NG-6** | [MUST NOT] 为 core/app 双份配置漂移建 CI 检查 | 用户裁决：取消双份策略，根因消除，无需检查 |
+| **NG-7** | [MUST NOT] 在列表/分页相关类型（`AppApiListModel` / `AppApiListParamsModel` / `TableApiParams` / `TableApiResult` 等）中**手写嵌套字面量类型**（如直接 `{ items: T[]; page: { totalRecord: number } }`）；所有路径推导**必须**从 `typeof APP_API_LIST_MODEL_KEY_CONFIG.XXX_KEY` 读取 | 当前 4 KEY 取值并非永久不变——消费方可通过发新版或 `pnpm patch` 重写 runtime 取值；手写字面量会让 runtime 改而类型不跟进，等于自废 dot-path 推导能力。本约束适用 core 内部 + app 内部的所有列表/分页类型定义 |
+
+## 边界情况和约束
+
+### 兼容性
+
+- 当 KEY 不含 `.`（如 LIST_KEY = `"items"`）时，类型推导退化为单层 `{ items: V }`，运行时 `_get(obj, "items") === obj.items`、`_set(obj, "items", v)` 等价 `obj.items = v` → 与现状完全兼容
+- KEY 含 `.` 时（如 `"page.page"`），运行时通过 `_set` 自动创建中间对象 → 安全
+
+### lodash 依赖
+
+- `lodash/cloneDeep`、`lodash/omit` 当前 TableMain.vue 已依赖
+- 新增 `lodash/get`、`lodash/set` → 不引入新顶级 npm 依赖（lodash 已在 app）
+- core 包是否需要显式依赖 lodash？由架构师在 design 阶段评估（core 当前是否已通过 peerDependency 或 dependency 引用 lodash）
+
+### 跨包构建
+
+- core 修改后须 `pnpm build` 重新构建 d.ts，app 才能消费最新类型
+- dev 环境：vite-plugin-dts 是否支持 watch 模式？由架构师评估，否则 design 中给出本地开发流程（如 `pnpm -F core build` 后再启 app dev）
+
+### 期 #2 衔接
+
+- 当前 table 组件路径：`packages/app/src/components/table/`
+- 期 #2 迁到 `packages/core/src/components/table/` 后：
+  - import 路径从 `@done-coding/admin-core` 改为相对路径（`../../types/dot-path` / `../../config/list-model`）
+  - 这是机械改造，本次任务不预先处理
+
+## 需求确认记录
+
+| REQ | 确认 |
+|---|---|
+| REQ-1 dot-path 类型工具 | ✅ 已确认（按推荐：A→4 工具 2 层 / B→`core/src/types/dot-path.ts` 单文件 / C→命名按推荐 / D→4 工具全 re-export / E→接受实现样例）|
+| REQ-2 KEY 配置 core 单一来源 | ✅ 已确认（按推荐：A→`core/src/config/list-model.ts` / B→5 项单文件 / C→app `request.ts` 内 re-export / D→`BuildListParams<KC, Partial<P>>` / E→接受实现样例）|
+| REQ-3 列表参数/结果类型工具 | ✅ 已确认（由 REQ-2 实现样例隐式覆盖：`AppApiListModel<T>` = `BuildListModel<typeof KEY_CONFIG, T>` / `AppApiListParamsModel<P>` = `BuildListParams<typeof KEY_CONFIG, Partial<P>>`）|
+| REQ-4 TableApiParams/TableApiResult 重写 | ✅ 已确认（A→b 基础工具组合 / B→a `BuildListParams<typeof KEY,SQ>` / C→a 不改其他 7 类型 / D→a 走 `@/config` re-export / E→接受修订样例。遵循 DUCK 最小化 + typeof KEY_CONFIG 推导原则）|
+| REQ-5 TableMain.vue 运行时改造 | ✅ 已确认（A→a `_cloneDeep+_set` / B→a 业务侧 `as UnwrapRef<T[]>` / C→a 单独 `lodash/set` `lodash/get` import / D→接受样例）|
+| REQ-6 core TECH_SNAPSHOT.md 起步版 | ✅ 按原则推断锁定：4 章节（设计边界 / 已知约束 / 类型工具说明 / ADR）；内容由前几轮约束推出（业务壳层禁下沉 + pnpm patch 逃生 + 4 工具说明 + 本任务 ADR）|
+| REQ-7 core README.md 进阶用法节 | ✅ 按原则推断锁定：pnpm patch 逃生通道操作示例（最小步骤 + 警示「不通过业务运行时配置覆盖」）|
+| NG-1 业务壳层禁止下沉 | ✅ 已确认（用户多轮硬规则：code/data/message 业务特征留 app）|
+| NG-2 不引入 IoC | ✅ 已确认（用户裁决：一个月内不考虑）|
+| NG-3 不迁组件本体 | ✅ 已确认（用户明示「前置任务」性质，期 #2 处理 table/list-page 迁移）|
+| NG-4 不改业务码/消息体/拦截器 | ✅ 已确认（NG-1 引申 + 克制原则）|
+| NG-5 不支持数组路径 | ✅ 已确认（YAGNI；当前 lodash get/set 接受字符串路径已足够）|
+| NG-6 不建 CI 检查 | ✅ 已确认（取消双份策略后根因消除）|
+| NG-7 禁手写字面量，必须从 typeof KEY_CONFIG 推导 | ✅ 已确认（用户硬约束：KEY runtime 可经 pnpm patch 改写，类型必须随 typeof 自动跟进）|