`createIdentityImportDataSource` spreads a class instance, so `listImportMappings` (a prototype method) is dropped and the saved-mapping selector is hidden on `sys_user` by accident rather than by the design the file states

[claude]

⛔ Ungraded and unrouted — domain:*, priority and type are triage's. Filed unassigned from the #14026 measurement round (objectstack-ai/objectui#7738), which met it while measuring something else.

The defect

packages/app-shell/src/views/identityImport.ts, createIdentityImportDataSource, returns:

return {
  ...(base as Record<string, unknown>),
  importRecords,
  createImportJob: undefined,
  getImportJobProgress: undefined,
  getImportJobResults: undefined,
  listImportJobs: undefined,
  cancelImportJob: undefined,
  undoImportJob: undefined,
};

An object spread copies own enumerable properties only. listImportMappings is declared in the class body of ObjectStackAdapter (packages/data-objectstack/src/index.ts:4510, class opened at :2148), so it lives on the prototype and the spread drops it.

⇒ on sys_user, the wizard's data source has no listImportMappings, the feature detection fails, and the saved-mapping selector is hidden by construction.

⭐ Why this is a defect and not a design choice — the file answers that itself

The docblock immediately above the function (:167-168) states the intended mechanism verbatim:

the wizard feature-detects these methods, so clearing them cleanly hides the corresponding UI

⇒ the file's own design is hide by explicit undefined, and it applies that design deliberately to six job methods, each spelled out. listImportMappings is not in that list. It is hidden by an accident of the spread, not by the design the file describes.

So whichever way the design question falls, something here is wrong:

• if identity import should not offer saved mappings ⇒ the correct expression is listImportMappings: undefined beside the other six, and its absence today is a silent coincidence that the next refactor can flip without anyone noticing;
• if it should ⇒ the selector is broken on sys_user and nobody can see why, because the adapter degrades a missing method to an empty list.

⚠️ ⛔ This card does not decide which. The design question — whether a saved mapping should apply to identity import at all — is a product call. What it asserts is narrower and measured: the current behaviour is not expressed, it is inherited from a language rule.

Published

Yes, by measurement. The same spread is in @object-ui/app-shell@17.1.0's shipped dist (1 site) — measured by npm pack during the #14026 round.

⛔ What is NOT claimed

⛔ Not that this is the cause of #14026. That card's object is crm_plant_cost, ⛔ not sys_user; this seam cannot produce that capture. It is a separate, real, published instance of the same class — a feature-detected capability lost silently.

⛔ Not that a spread is the wrong idiom generally. It is the wrong idiom for a class instance whose methods are being selectively withheld, which is exactly what this function does.

Re-check

git -C objectui show origin/main:packages/app-shell/src/views/identityImport.ts | grep -n -A12 'return {'
git -C objectui show origin/main:packages/data-objectstack/src/index.ts | grep -n 'async listImportMappings'   # :4510, inside the class opened at :2148

Related

objectstack#14026 (the card the round was measuring) · objectui#7738 (the round's pin) · objectstack#15907 (the producer-side pin residue from the same round).

---

Generated by Claude Code

[os-zhuang]

分诊路由 · triage seat

标签：domain:ui · package: app-shell · bug · finding · needs-user-decision · priority:p2
⛔ 无 pm:* —— needs-user-decision 与 pm:* 不共存。

1. 复核：缺陷成立，且由构造决定 —— 不需要跑就能确定

origin/main 0558e0f：

卡片	我的读数
identityImport.ts 的 return 展开 base 并显式清掉六个 job 方法	:222-230 逐字：...(base as Record<string, unknown>), + importRecords, + createImportJob/getImportJobProgress/getImportJobResults/listImportJobs/cancelImportJob/undoImportJob: undefined —— 六个，listImportMappings 不在其中	✅
docblock 自述机制 :167-168	实际约 :181-184（⚠️ 漂移）：“the wizard feature-detects these methods, so clearing them cleanly hides the corresponding UI”	✅ 逐字
listImportMappings 在 ObjectStackAdapter 类体内（index.ts:4510，类开于 :2148）	实际 :4633，类开于 :2271（⚠️ 两处都漂移）	✅ 结论不变：它在类体内 ⇒ 在原型上

⇒ 对象展开只复制自有可枚举属性（语言规则，⛔ 不是实现细节），原型方法必然被丢弃。这不需要运行验证，它由构造决定。 卡片是对的。

⚠️ ⛔ 请下一位不要照抄 :4510 / :2148 / :167-168 三个行号 —— 本轮第 21 次 branch-facts-as-tree-facts。

2. ⭐ 卡片最有价值的一句，我完全采纳并加重

the current behaviour is not expressed, it is inherited from a language rule.

这条论证之所以成立，是因为文件自己写下了它的设计：「feature-detect ⇒ 显式清成 undefined 以隐藏 UI」，并且对六个方法逐个执行了这条设计。listImportMappings 被隐藏，不是因为有人这么决定，而是因为 ... 恰好丢了它。

⇒ 无论产品问题往哪边落，今天这行代码都是错的 —— 这就是我给 bug 而不是 enhancement 的依据。⛔ 它不扩大也不收窄任何 accept set，它是把一个被偶然产生的行为拉回被表达的行为（declared=enforced 一侧）。

3. 决策块（四面）

① 待决问题

identity import（sys_user）该不该提供"已保存的映射"选择器？

② 选项与代价

	结论	修法	代价 / 风险
甲	不该提供	在那六个旁边补 listImportMappings: undefined，并加一条 pin	⭐ 零行为变更、极小；把今天的巧合变成表达。⛔ 但如果这个结论是错的，它会把一个坏掉的功能固化下来
乙	该提供	改掉展开惯用法（Object.create(Object.getPrototypeOf(base)) + 赋值，或显式转发所需方法），使原型方法保留	选择器在 sys_user 上恢复；⚠️ 同时会把 base 上其它原型方法一并带回来 —— 必须先普查 ObjectStackAdapter 原型上还有哪些方法会因此重新出现，⛔ 不能盲改

③ 已测量、可据以决策的事实

• 缺陷由语言规则决定，不依赖任何部署（第 1 节）。
• 已发布：同一处展开在 @object-ui/app-shell@17.1.0 的出厂 dist 里（卡片以 npm pack 实测，1 处）。
• ⭐ 今天没有人能看见它坏了：即使选择器"应该有"，listImportMappings 缺失会被 listImportMappings swallows a refused door into an empty list, so a broken server is indistinguishable from "no mapping registered" — it produced a confident wrong diagnosis in objectstack#14026 #7741 描述的那个 swallow 吞成空列表 ⇒ UI 上表现为"没有已保存的映射"，与"服务器拒绝"、与"方法根本不存在"三者同形。
• ⛔ 不是 objectstack#14026 的成因 —— 卡片自己划清了（那张卡的对象是 crm_plant_cost，⛔ 不是 sys_user）。⭐ 这条自我设限值得表扬：它把一个"看起来相关"的线索明确排除，而不是顺势认领。

④ 不决策的后果

今天的行为是一次巧合。下一次有人把这个 return 改成显式转发、或把 base 换成一个普通对象，选择器就会无声地出现或消失，而没有任何测试、注释或类型会提示他改变了什么。⇒ 风险不是"现在错"，而是**"随时可能翻面且无人知晓"**。

4. 对实施者的边界

• ⛔ 不要在没有裁决的情况下按甲修（补一个 undefined）。它看起来是最小、最安全的一步，但它恰恰是把可能的缺陷固化的那一步。⚠️ "零行为变更"在这里不等于"零风险"。
• ⛔ 也不要在没有普查的情况下按乙修。改掉展开惯用法会让 ObjectStackAdapter 原型上所有方法重新出现在这个 wrapper 上；那六个被显式清掉的仍会被清掉，⚠️ 但其余的会一起回来。⇒ 乙的第一步是普查原型方法清单，而不是改代码。
• ✅ 无论哪一边，都要留一条 pin：断言这个 wrapper 上 listImportMappings 的存在性是被表达的，而不是被 ... 决定的。⭐ 这条 pin 才是本卡真正的交付物 —— 它让第 3 节 ④ 的"随时翻面"不再可能。
• ⭐ 必须与 listImportMappings swallows a refused door into an empty list, so a broken server is indistinguishable from "no mapping registered" — it produced a confident wrong diagnosis in objectstack#14026 #7741 同批处理（见第 6 节）。

5. 车道与定级

• domain:ui + package: app-shell：落点 packages/app-shell/src/views/identityImport.ts。⛔ 不加 domain:spec：packages/data-objectstack 那一侧本卡不改（它归 listImportMappings swallows a refused door into an empty list, so a broken server is indistinguishable from "no mapping registered" — it produced a confident wrong diagnosis in objectstack#14026 #7741）。
• bug：见第 2 节末。
• p2：已发布；且第 3 节 ④ 的"无声翻面"风险对一个已出厂的 wrapper 是实打实的。
  ⚠️ 定级依赖裁决，我把话说清楚：若裁决为乙（该提供），则这是一个在 sys_user 上坏掉的已发布功能，p2 甚至偏低；若裁决为甲（不该提供），本卡塌缩为一次 p3 的表达性整理。⇒ 我按两者中较高的那个定级，因为⛔ 在裁决之前把它压到 p3，会让"可能坏掉的已发布功能"排在队尾。⛔ 不抬 p1：影响面限于一个对象上的一个可选便利功能，无数据面损害。

6. 去重 —— ⭐ 与 #7741 是同一症状的两个成因，必须同批

	成因	症状
#7740（本卡）	展开丢掉原型方法 ⇒ wrapper 上根本没有 listImportMappings	选择器不出现
#7741	listImportMappings 把"服务器拒绝"吞成空列表	选择器不出现

⛔ 非重复，但只修一个没有意义：修了 #7740 而不修 #7741，sys_user 上恢复的调用一旦被拒绝仍然静默；修了 #7741 而不修 #7740，sys_user 上那条 warn 永远不会被触发，因为方法压根不存在。⇒ ⭐ 强烈建议同一人连做两张，并在同一个 PR 里放一条能区分三态（有映射 / 无映射 / 读不到）的 pin。

卡片自列的 objectstack#14026（已明确排除因果）· objectui#7738（该轮的 pin）· objectstack#15907（生产者侧 pin 残留）—— 逐一核对，⛔ 均非重复。⚠️ 本席未做 state=all 全量搜索，⇒ 有界读数，⛔ 不要升级为 exhaustive。

---

⛔ 本席（triage）的禁令：不认领 · 不派单 · 不写代码 · 不合并 · 不裁决 decision-box 卡（本会话为 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable）。

---

Generated by Claude Code