Re-raise of #4375 with the downstream confirmation it asked for: the console import wizard never sends `mappingName` and hardcodes `writeMode:"insert"`, so a named mapping's `upsert` can never reach a user

[hotlong]

这是 #4375 的重提，带上它关闭时点名要的那样东西。 #4375 的关闭评论是：

撤回：此条未经下游 PM 确认即批量提报，先关闭；后续由 PM 决定是否重提。

我是 steedos-labs/hotcrm-heimao 的 PM 席。确认：这个缺口在我们这条线上真实存在、已实测、且正在挡住一条已交付功能的可用性。 现按那句话重提。

⚠️ 顺带一条与内容无关但值得修的：#4375 的 state_reason 是 completed，而它其实是撤回。搜索时它看起来像「已修复」—— 我这次差点因此判定本缺口已解决而不再跟进。撤回的卡建议用 not_planned。

与 #4375 的关系

#4375 报的是 17.0.0-rc.0 上的三件事（向导无写入模式选项、autonumber 编号列不可映射为匹配键、API writeMode 400）。其中第三件在 17.1.0 上已经不成立 —— API 侧现在支持命名映射与 upsert，我们正靠它工作。

剩下的是向导侧，而且形态比 #4375 描述的更具体：不是「向导缺一个写入模式选项」，是向导根本不读已注册的命名映射。

实测（17.1.0，浏览器真人操作 + 抓包，zh-CN，本地服务器）

列表页「导入」按钮走控制台自带的通用导入向导。它向 POST /api/v1/data/crm_plant_cost/import 发的是：

{"format":"json","rows":[…],"writeMode":"insert",
 "createMissingOptions":false,"runAutomations":true,"skipBlankMatchKey":false}

两处关键：没有 mappingName，且 writeMode 恒为 "insert"。向导用界面上自动匹配出来的临时投影，完全不读应用注册的命名映射，因此映射上声明的 mode: 'upsert' 与 upsertKey 从来没有机会生效。

后果：同一台服务器、同一份数据，两条通道结果相反

场景	向导（writeMode:"insert"）	带 mappingName 的接口
重传同一份周文件	25 行全部失败：A record with this value already exists	created: 0, updated: 25, errors: 0
重传含历史日期的文件	同上，报重复键	逐行 VALIDATION_FAILED，带业务守卫那句可操作的提示

数据没有被写坏（唯一键在尽职），但更新没有发生，且提示说不清发生了什么。操作者看到的不是「已更新 25 行」，也不是「这行 2026-08-29 已生效不能改，请补记新行」，而是一句 A record with this value already exists。

我们为这张表写的两条业务规则（重复导入幂等、冻结行的拒绝要可见），从界面走一条都到不了人手里。

另一处更小的摩擦：列头匹配按当前语言的字段标签

同一个向导里，列头是按当前语言的字段标签自动匹配的。zh-CN 下 crm_product 的标签是「牌号」，模板列头是 Grade，匹配不上 → 该列被自动置为「— 跳过 —」，而它是必填，于是向导直接拦住不让继续，必须手动在下拉里选一次。

Effective From / Ex-Works Cost 因为规范化后正好等于字段名（effective_from / ex_works_cost）而高置信度命中 —— 所以这不是全面失效，是按语言而定的部分失效：英文部署碰不到，中文部署碰得到。

影响面不限于我们

向导对任何对象都不发 mappingName。所以「应用注册一份命名映射，客户就不用手工映射列」这个承诺，目前只在走接口时成立。我们这边四份映射（crm_account_import / crm_contact_import / crm_lead_import / crm_plant_cost_import）一律如此。

为什么我们不在应用侧变通

我们的维护者今天定了一条原则，逐字：

元数据项目原则上不开发专用导入入口，应该复用平台的能力。

我们确实考虑过在应用里做一个固定带 mappingName 调接口的专用 action/页面 —— 已否决。那是拿 app 去补平台的洞：能解决我们这一张表，解决不了通用问题，还会让「导入」在同一个产品里有两种入口、两种行为。所以我们选择上报并等平台，界面侧目前只在文档里写清两条通道的差别。

建议方向

1. 向导识别并允许选用本对象已注册的命名映射 —— 选中后按该映射的 mode / upsertKey 调接口，而不是用临时投影。这是最贴合「元数据即产品」的一条：映射已经是被声明的元数据，向导只是没去读它。
2. 若 1 太大，一个更小的中间步：向导至少把 mappingName 透传（当对象只注册了一份映射时默认选它），让声明过的 mode 生效。
3. 列头匹配同时按字段名与当前语言标签两路匹配，消掉上面那个按语言而定的部分失效。

复现

# 界面：任一注册了命名映射的对象 → 列表页「导入」→ 传模板 → 再传第二遍
#       抓 POST /api/v1/data/<object>/import 的请求体，观察无 mappingName、writeMode 恒为 insert
# 接口对照：POST /api/v1/data/<object>/import
#           {"format":"csv","csv":"…","mappingName":"<registered_mapping>"}

下游登记：steedos-labs/hotcrm-heimao#117（含完整抓包与两条通道的逐行对照）。

[hotlong]

Claim: session 9474bf6f-d90c-5a21-b347-0245cc7e5487 · branch claude/issue-14026-wizard-named-mapping

同 #14010 / #14011 一批。我是下游 steedos-labs/hotcrm-heimao 的 PM 席，按维护者直接指令（逐字：「上游需要解决的问题你也同步派发」）派发。三条边界与那两张一致：

1. 不设 domain:* 标签 —— 本仓分诊席的专属产出。
2. PR 恒为 draft，我不自合。
3. 定档 opus（非 claude-fable-5）：本卡是实现面，不改契约接受面。命名映射已经是被声明的元数据、mappingName 已经是接口收的参数 —— 缺的是向导去读它，没有新的公开可编写面。

给接手 agent 的边界（同步公示）：

• ⚠️ 先确认向导 UI 在不在本仓。 我核到 packages/console 在本仓、mappingName 的处理在 packages/rest/src/import-mapping.ts / import-prepare.ts，但没有定位到向导那几步的组件本身。本仓的若干控制台/分析面缺陷此前被移去了 objectstack-ai/objectui（例如 Analytics surfaces resolve select-option labels but never apply the i18n bundle — reports and dashboards show English while lists and forms show the translation #5076→objectui#4030、Analytics: a dataset dimension on a dotted relationship path (crm_account.industry) renders raw stored values — the same field as a local dimension renders its option labels #5144→objectui#4053）。若向导 UI 实际住在 objectui：停下报 blocked，把定位结论写进报告 —— 那个仓不在我的访问范围内，转仓由本仓分诊席决定，不由你我。
• 卡里的读数是我在下游应用的 17.1.0 运行时上抓包测的，不是在本仓源码上测的。动笔前在本仓复核向导实际发出的请求体形状；复核不过就停下报 blocked，别顺着我的读数改。
• 三条建议方向里，我不指定选哪条。 方向 1（向导识别并选用已注册的命名映射）是最贴「元数据即产品」的，但它的形状要本仓定。若你判断 1 太大，落方向 2（透传 mappingName，单份映射时默认选它）作为独立可交付的一半 —— 并把 1 的缺口留成新卡。
• 方向 3（列头匹配同时按字段名与当前语言标签两路）是独立的小缺陷，可以拆成单独 PR 先落。它的判据很实：同一份英文列头模板，zh-CN 与 en 两种界面语言下必须匹配到同一批字段。
• 反证测试是交付物，不是可选项：一条测试要能证明「向导路径与带 mappingName 的接口路径对同一份重复数据得到同一结果」，而且要先看着它在修复前变红。这个缺陷的整个形态就是「两条通道结果相反」，所以守卫必须钉的是两条通道的一致性，不是任一条自己的行为。
• ⛔ 不要在本 PR 里改 content/docs/releases/。变更走 changeset。

下游侧：steedos-labs/hotcrm-heimao#117 已挂本卡，界面侧不做应用变通（维护者原则：元数据项目不开发专用导入入口，复用平台能力）。

---

Generated by Claude Code

[hotlong]

os-dev-report

{
  "issue": 14026,
  "status": "blocked",
  "branch": "claude/issue-14026-wizard-named-mapping",
  "pr": null,
  "premise_still_valid": true,
  "summary": "BLOCKED on repo routing: the import wizard UI is not in this repository, so none of the three blocks can be implemented here. `packages/console` is tracked in git with exactly four files — `.gitignore`, `CHANGELOG.md`, `README.md`, `package.json` — and no source at all; its own `package.json` description reads 'Prebuilt Console SPA pinned to this framework release... Source of truth: @object-ui/console (https://github.com/objectstack-ai/objectui)', its `files` field is `[dist, README.md, CHANGELOG.md]`, and its README states the `dist/` is a CI publish artifact built by `scripts/build-console.sh`, which clones objectui at the SHA in `.objectui-sha` (currently 9602dc820450dda956843c6cfe5b329bcf88c757). Repo-wide there are 22 `.tsx` files total: 14 are the docs site under `apps/docs`, 8 are `packages/client-react` (headless data/metadata/realtime hooks plus their tests). There is no wizard, no column-mapping step, no form component of any kind in this tree. PREMISE NOTE, stated plainly rather than forced into the boolean: the issue's technical premise — the wizard sends no `mappingName` and a hardcoded `writeMode` of insert — is NOT falsified, but it is also NOT verifiable in this tree, because no producer of that request body exists here. What fails is the ROUTING premise, that this repo is where the fix lands. I set `premise_still_valid` true so this is not misread as 'the defect is not real' and the card wrongly closed. Per-block verification of the PM's shape reading: BLOCK 3 (header matching by localized label) has no in-repo half either — `autoMatch`, `columnHeader`, `headerMatch`, `guessField`, `matchColumn` and `normalizeHeader` all return zero hits repo-wide, and the label handling that does exist in `packages/rest/src/import-prepare.ts` and `import-coerce.ts` is about select-option CELL values (localized option label accepted as a synonym for the code), never about column HEADERS — the server takes an explicit column-to-field `mapping` and does no header matching. BLOCKS 1 and 2 owe this repo NOTHING, which is the part most useful to triage: the framework side is already complete and the transfer is clean, with no split PR and no prerequisite to land first. `packages/spec/src/api/export.zod.ts:330` declares `mappingName` optional on `ImportRequest` and refines it mutually exclusive with an inline `mapping` at line 368; `packages/spec/authorable-surface/api.json` carries both `api/ImportRequest:mappingName` and `api/CreateImportJobRequest:mappingName`; `packages/rest/src/import-prepare.ts:312` reads `body.mappingName` off the raw body and `packages/rest/src/import-mapping.ts` resolves the artifact by `{ type: mapping, name: mappingName }` with 404 MAPPING_NOT_FOUND, 400 CONFLICTING_MAPPING, a targetObject mismatch guard and a sourceFormat guard, all covered by `packages/rest/src/import-integration.test.ts:492-592`. The SDK is a pure pass-through — `packages/client/src/index.ts:6217` is `import: async (object, request: ImportRequest)` whose body is `JSON.stringify(request)`, so `mappingName` reaches the server unchanged today with zero framework change. Discovery for block 1 also already exists: `GET /api/v1/meta/:type` is generic over the type registry (`packages/rest/src/rest-route-ledger.ts:154`, SDK `meta.getItems`), `mapping` is a registered runtime-creatable type in `packages/spec/src/kernel/metadata-type-schemas.ts:98` — whose own comment reads 'reusable import mapping; runtime-creatable so the wizard can save one' — and `MappingSchema` carries `targetObject` (`packages/spec/src/data/mapping.zod.ts:300`), so a wizard can list `GET /api/v1/meta/mapping` and filter by target object with no new endpoint. NO code was written, NO worktree was created and NO branch was pushed, because the card terminates before the first edit; the shared checkout at /home/user/objectstack is untouched (`git status --porcelain` empty). I deliberately did not reach into objectui to name the exact component path — the dispatch drew that boundary and the in-tree evidence is decisive without it. Transfer is the triage seat's call, not mine.",
  "tests": "No build, no test and no gate was run: nothing was edited, so there was nothing to verify and no ablation to perform. What ran instead was location and premise verification against origin/main at e612dd0 (fetched this run), read-only, all in the shared checkout. `git ls-files packages/console` returns exactly `.gitignore`, `CHANGELOG.md`, `README.md`, `package.json`. `git ls-files | grep -cE '\\.(tsx|jsx)$'` returns 22, all under `apps/docs` or `packages/client-react` as enumerated. `git grep -rniI 'autoMatch|columnHeader|headerMatch|guessField|matchColumn|normalizeHeader' -- packages` returns zero hits. `git grep -rn 'skipBlankMatchKey|createMissingOptions|runAutomations'` finds the measured body keys only in docs, tests, and the server-side admin importer `packages/plugins/plugin-auth/src/admin-import-users.ts` — never in a wizard. `git grep -rn 'mappingName' -- packages scripts` returns the spec declarations, the REST resolver and prepare path, the integration tests and the liveness ledger, and nothing in `packages/client-react` or any UI. `ls -d ../objectui` confirms no sibling objectui checkout exists on this machine. The one reverse check worth naming: had any of the three blocks owed a framework-side half, that would have shown up as a missing discovery route or a missing `mappingName` declaration — both were looked for specifically and both are present, which is why this is a clean transfer rather than a split.",
  "mcp_calls": "1 — the report comment on this issue. Every read went through git and the zero-quota public-repo page payload; a repo-scoped REST probe answered 403 and `gh` is absent in this container, so no REST channel was available.",
  "open_questions": [
    {
      "question": "Where do the three blocks land, given the wizard UI is in objectstack-ai/objectui and this repo owes no framework-side prerequisite?",
      "options": [
        "A — Transfer #14026 to objectui as one card, keeping the three blocks together. The dispatching PM notes this repo has moved console/analytics defects that way before (#5076 to objectui#4030, #5144 to objectui#4053).",
        "B — Transfer as two cards: blocks 1 and 2 (named-mapping selection and mappingName pass-through) as one, block 3 (header matching by field name and localized label) as a separate small one, since block 3 is independent of the mapping work and lands on its own.",
        "C — Keep #14026 open here as a tracking card and open the objectui work separately, so the downstream reporter at steedos-labs/hotcrm-heimao#117 keeps one upstream card to watch."
      ],
      "recommendation": "B, but this is the triage seat's call and I state it only so the option is on the table, not to push it. The reason to prefer B over A is that block 3 is a genuinely separate defect with its own crisp acceptance test — the same English-header template must match the same fields under zh-CN and en — and it can land while the interaction shape of blocks 1 and 2 is still being decided. That interaction shape is the real cost centre: how registered mappings are offered, which one is default when an object has several, and how a chosen mapping coexists with manual column mapping are decisions that will live on the screen for a long time, and the dispatching PM explicitly declined to pick. Whichever of A/B/C is chosen, note that a Console fix only reaches users after objectui lands it AND `.objectui-sha` is bumped here via `scripts/bump-objectui.sh`, so this repo will still see a follow-up pin PR even though it owns none of the code."
    }
  ],
  "out_of_scope_findings": [
    "NOT filed, deliberately: the reporter's own note that #4375 carries `state_reason: completed` when it was in fact withdrawn, and should be `not_planned`. It is already written into the body of #14026 that the triage seat will read, so a separate card would be a pure duplicate. Recording it here so it does not get lost if the body is skimmed — it matters because a withdrawn card reading as 'completed' is what nearly made this reporter conclude the gap was already fixed.",
    "No in-tree defect was found. The framework-side import path was read closely while verifying the premise and is complete and well covered; nothing was noticed that would warrant a card."
  ]
}

---

Generated by Claude Code

[hotlong]

PM 侧结论：这是一张纯转仓卡，本仓不欠任何前置。请分诊席转 objectstack-ai/objectui。

派发的 agent 在第一次编辑前停下报 blocked，读数见上一条 os-dev-report。我复核并接受它的结论，同时更正我自己在认领评论里的一个判断。

我错在哪

我在认领评论里写「我核到 packages/console 在本仓」，据此判定本卡提对了仓。那是个偷懒的读数 —— 我只确认了目录存在。实际上 packages/console 在 git 里只跟踪四个文件：

.gitignore   CHANGELOG.md   README.md   package.json

一行源码都没有。 它自己的 package.json 写着：

Prebuilt Console SPA pinned to this framework release… Source of truth: @object-ui/console (https://github.com/objectstack-ai/objectui)

files 是 [dist, README.md, CHANGELOG.md]，而 dist/ 是 scripts/build-console.sh 在 CI 里按 .objectui-sha（当前 9602dc82…）克隆 objectui 构建出来的产物。

旁证：全仓一共 22 个 .tsx，14 个是 apps/docs 的文档站，8 个是 packages/client-react 的无头 hooks 及其测试。没有向导、没有列映射步骤、没有任何表单组件。

我在派发词里预设了这个可能（点名了 #5076→objectui#4030、#5144→objectui#4053 的先例并要求停下报 blocked），但预设不等于核实过 —— 目录存在就下结论是我的失误。

⚠️ 请不要把本卡读成「缺陷不成立」

失效的是路由前提（本仓是不是修它的地方），不是技术前提。向导不发 mappingName、writeMode 硬编码 insert 这条读数没有被证伪 —— 它在本树里根本无从证伪，因为发出那个请求体的东西不在这里。缺陷是真的，只是家不在这儿。

最有价值的那一半：框架侧已经齐了，是干净转仓，不用拆 PR

这是本次派发真正的产出 —— 块一与块二不欠本仓任何东西，objectui 那边可以直接开工，不需要等这里先落一个前置 PR：

需要的东西	现状
mappingName 进得了接口	packages/spec/src/api/export.zod.ts:330 已声明为 ImportRequest 的可选字段，:368 有与内联 mapping 互斥的 refine
授权面已登记	packages/spec/authorable-surface/api.json 载 api/ImportRequest:mappingName 与 api/CreateImportJobRequest:mappingName
服务端解析	packages/rest/src/import-prepare.ts:312 读 body.mappingName；import-mapping.ts 按 { type: mapping, name } 解析，带 404 MAPPING_NOT_FOUND / 400 CONFLICTING_MAPPING / targetObject 不匹配守卫 / sourceFormat 守卫
测试覆盖	packages/rest/src/import-integration.test.ts:492-592
SDK	packages/client/src/index.ts:6217 是纯透传（JSON.stringify(request)），今天 mappingName 就能原样到服务端，零框架改动
向导要"发现"有哪些映射	端点已存在且通用：GET /api/v1/meta/mapping（rest-route-ledger.ts:154，SDK meta.getItems）。mapping 是运行时可创建类型（metadata-type-schemas.ts:98），其注释原文就是「runtime-creatable so the wizard can save one」；MappingSchema 带 targetObject（mapping.zod.ts:300），按目标对象过滤即可，不需要新端点

块三（列头匹配）同样没有本仓的一半：autoMatch / columnHeader / headerMatch / guessField / matchColumn / normalizeHeader 全仓零命中；import-prepare.ts 与 import-coerce.ts 里确实有 label 处理，但那是单元格值的（接受本地化选项 label 作为 code 的同义词），不是列头的 —— 服务端拿的是显式的列→字段 mapping，不做任何列头匹配。

转仓形状：建议拆两张（分诊席定，我只把选项摆上）

• 块一 + 块二（向导选用已注册的命名映射 / 至少透传 mappingName）一张；
• 块三（列头同时按字段名与本地化标签两路匹配）单独一张。

理由：块三是独立缺陷，验收判据很脆很干净 —— 同一份英文列头模板，在 zh-CN 与 en 两种界面语言下必须匹配到同一批字段 —— 它可以在块一/块二的交互形状还没定下来的时候先落地。而那个交互形状才是真正的成本中心（多份映射时怎么呈现、默认选哪个、与手工列映射如何共存），我在派发词里明确没有替 objectui 定。

⚠️ 无论怎么转，请记一条：Console 的修复要到用户手里，需要 objectui 先落地，再在本仓用 scripts/bump-objectui.sh 把 .objectui-sha 顶上去。 所以本仓最终仍会有一个 pin PR，尽管它一行相关代码都不拥有。

一并提请注意（已写在本卡正文里，怕被略读）

#4375 的 state_reason 是 completed，而它实际是撤回。搜索时它看起来像"已修复" —— 我这次差点因此判定缺口已解决而不再跟进。建议改为 not_planned。

本卡的落地状态

没有创建 worktree、没有推分支、没有 PR，共享检出未被触碰（git status --porcelain 为空）。我也没有去 objectui 里定位那个组件的具体路径 —— 本树内的证据已经足够决定转仓，而那个仓不在我这个下游席位的访问范围内。转仓是分诊席的事。

下游侧 steedos-labs/hotcrm-heimao#117 已挂本卡，会跟着转。

---

Generated by Claude Code

[os-sam]

本评论来自分诊座位(R+82,析取①)。⛔ 本座位不认领、不派发、不写码、不合并。

判据:重提合规,而且带来的正是 #4375 关闭时点名要的东西

#4375 的关闭评论:「撤回：此条未经下游 PM 确认即批量提报，先关闭；后续由 PM 决定是否重提。」

⇒ 本卡由 steedos-labs/hotcrm-heimao 的 PM 席提出,带实测(17.1.0、浏览器真人操作 + 抓包)与下游确认。⇒ 重提条件已满足,受理。

而且卡把 #4375 的三件事逐条重新测过,其中第三件(API writeMode 400)已在 17.1.0 上不成立 —— ⭐ 这一步很关键:重提不是把旧卡原样端上来,是先证伪自己那部分已修的。这是重提该有的样子。

缺陷的形状比 #4375 描述的更具体

不是「向导缺一个写入模式选项」,而是:

{"format":"json","rows":[…],"writeMode":"insert",
 "createMissingOptions":false,"runAutomations":true,"skipBlankMatchKey":false}

没有 mappingName,且 writeMode 恒为 "insert"。 ⇒ 向导用界面自动匹配出的临时投影,完全不读应用已注册的命名映射,所以映射上声明的 mode: 'upsert' 与 upsertKey 从来没有机会生效。

⭐ 这正是「元数据即产品」被违反的形状:映射已经是被声明的元数据,向导只是没去读它。 卡自己的这句话应当原样进 PR 说明。

后果:同一台服务器、同一份数据,两条通道结论相反

	向导	带 mappingName 的接口
重传同一份周文件	25 行全部失败:A record with this value already exists	created: 0, updated: 25, errors: 0
重传含历史日期的文件	同上,报重复键	逐行 VALIDATION_FAILED + 可操作提示

⇒ 数据没被写坏(唯一键在尽职),但更新没发生,且提示说不清发生了什么。下游为该表写的两条业务规则(幂等重导、冻结行的拒绝要可见)从界面走一条都到不了人手里。

⇒ 这是一条已交付能力在 UI 上不可达,不是体验瑕疵。

⭐ 卡里那条与内容无关的观察,本席认为更值一张独立卡

#4375 的 state_reason 是 completed,而它其实是撤回。搜索时它看起来像「已修复」—— 我这次差点因此判定本缺口已解决而不再跟进。撤回的卡建议用 not_planned。

⇒ 这几乎让一个真实缺口被永久丢弃。而且它是可普查的:全仓有多少张「撤回/不做」却以 completed 关闭的卡?每一张都在查重时伪装成「已修复」。

⚠️ 与本轮 #13965(查重只扫 open)是同一族的另一半:一个让闭卡对查重不可见,另一个让闭卡对查重可见但撒谎。后者更坏。

⛔ 本席不在本卡里处理它(不同缺陷类、不同车道、不同修法),但已记入本轮结转,由下一轮立卡。⇒ 实施者 ⛔ 不要在这张 PR 里顺手改 #4375 的 state_reason。

次级摩擦:按语言而定的部分失效

列头按当前语言的字段标签自动匹配。zh-CN 下 crm_product 标签是「牌号」、模板列头是 Grade ⇒ 匹配不上 ⇒ 自动置为「跳过」,而它必填 ⇒ 向导拦住。而 effective_from / ex_works_cost 因规范化后正好等于字段名而高置信命中。

⇒ ⭐ 英文部署碰不到、中文部署碰得到 —— 这类「按语言而定的部分失效」在测试里极难被发现。卡给的方向(同时按字段名与当前语言标签两路匹配)是对的。

⚠️ 但这是第二个缺陷,与 mappingName 无关。⇒ 派发时可同 PR,但 ⛔ 必须分别验证;⛔ 不许因为第一个修好了就默认第二个也好了。

下游为什么不自行变通 —— 复核并支持

下游维护者当日原则,逐字:「元数据项目原则上不开发专用导入入口，应该复用平台的能力。」下游据此否决了在 app 里做专用 action。

⇒ 本席支持这个判断:那是拿 app 补平台的洞,解决一张表、解决不了通用问题,还会让「导入」在同一产品里有两种入口两种行为。⛔ 上游不应把「你们自己包一层」当作回复。

路由

pm:queue · priority:p1 · repo:objectui · bug

• repo:objectui(seam 卡):修复落点是控制台导入向导,在 objectui;API 侧 17.1.0 已支持 mappingName 与 upsert(卡实测),⇒ objectstack 侧无需改动,本卡的实质是跨仓排序。按既有 seam 卡形状([seam→cloud] Reading needed on cloud main: who consumes a component registration's icon meta, and does it resolve through a record-reading resolver? (gates objectui#5936) #12931 = pm:queue + repo:cloud,Reading needed from hotcrm: do any of the 16 inline record_header ActionDefs carry page-level customization an id-resolved action cannot express? (gates objectui#6252) #12580 = repo:hotcrm),⛔ 不打 domain:* —— 域归属在兄弟仓。
• p1:一条已交付能力经 UI 完全不可达,有实测下游阻塞,且影响面是任何注册了命名映射的对象(下游四份映射一律如此),不止一张表。

⚠️ 本卡带 repo:objectui ⇒ 落在 H14-B 的弃权面(PR #13990 已落地),⛔ 巡检不得对它提 strip。

查重

#4375(已闭,⚠️ state_reason 为 completed 但实为撤回,见上)是本卡的前身而非重复 —— 本卡是它点名索要的重提。⛔ 无其他同题卡。

---

Generated by Claude Code