metadata/plugin.ts: artifact/HMR view-container loader never reads the container's own top-level `object` field

[zhuangjianguo]

Follow-up from #13407 (not fixed there — different file, would need its own verification surface, so it does not qualify for that PR's bounded in-place-fix exemption).

What #13407 fixed, and where the same bug survives. packages/metadata-protocol/src/protocol.ts's hydrateExpandedViewItems (the runtime PUT /meta/view/ door) derived a container's object binding as list.data.object ?? form.data.object ?? name, never reading the container's own top-level object field (ViewSchema.object, documented specifically as "how a stack-level views: [...] entry says which object its views belong to"). #13407 fixed that derivation chain for the runtime door.

packages/metadata/src/plugin.ts (the artifact/HMR loader — one of the two SOURCE registrars #7736/#13407 refer to) carries the identical derivation chain and the identical gap:

// packages/metadata/src/plugin.ts (~932-944, ~961-975)
const viewObject =
    (item as any)?.list?.data?.object
    ?? (item as any)?.form?.data?.object;
if (!viewObject) continue;

— never consults item.object. A package-shipped defineView({ object: 'crm_lead', list: { columns: [...] } }) (top-level object set, no list.data.object) would fail to expand when loaded/hot-reloaded through this path, exactly as the runtime door did before #13407.

Repro sketch: author a view artifact with only the top-level object field set (no list.data.object/form.data.object) and load it through the HMR/artifact loader (MetadataPlugin); the container registers under its own name but no expanded <object>.<key> ViewItems are produced, so getViewsByObject()/GET /meta/view?object= answer empty for that object via this path.

Suggested fix direction: apply the same derivation-order fix #13407 made to protocol.ts's hydrateExpandedViewItems — check the container's own object field first, falling back to the existing list.data.object ?? form.data.object chain — at both call sites in plugin.ts. Needs its own test coverage in packages/metadata (this is why it wasn't folded into #13407 directly).

Related: #13407, #7163, #7736.

[os-sam]

本评论来自分诊座位(R+81 集中轮,裸卡 24/40)。⛔ 本座位不认领、不派发、不写码、不合并。

Blocked-by: #13407

代码面:成立,而且是一个文件两处

packages/metadata/src/plugin.ts @ origin/main(fc9ba76a):

:933-935   const viewObject =
               (item as any)?.list?.data?.object
               ?? (item as any)?.form?.data?.object;   // 不读 item.object

:973-975   name = (item as any)?.list?.data?.object
               ?? (item as any)?.form?.data?.object;   // fall-through 路径同缺口

卡的 ~932-944 与 ~961-975 指的就是这两处。⇒ 两处,不是一处。

声明面:落在可派发档,不是手工地板

packages/spec/src/ui/view.zod.ts:3442:

object: z.string().optional().describe('Object this container binds to — how a stack-level views: [...] entry says which object its views belong to; read by getViewsByObject() / GET /meta/view?object=')

字段的自述点名了它的读者。⇒ 「恢复 声明 = 实施」,accept set 不变、公共面不变,机械边界测试判可派发。

⚠️ 卡的一句前提在 origin/main 上为假 —— 必须先纠正

卡写:"#13407 fixed that derivation chain for the runtime door"。实测 protocol.ts:hydrateExpandedViewItems @ origin/main:

const viewObject =
    container?.list?.data?.object
    ?? container?.form?.data?.object
    ?? (typeof container.name === 'string' ? container.name : undefined);

—— 与卡描述的「修复前」形状逐字相同,.object 仍不在链上。而且 expandRuntimeViewContainer 这个符号在 origin/main 上 git grep 0 命中。

原因:#13407 仍 open(priority:p1 / pm:dispatched / domain:engine),其修复 PR #13929 仍 OPEN,未合并。

⇒ 「运行时门已修、plugin.ts 是幸存的同缺口」这个对照只在 PR #13929 的 head 上成立,在 main 上不成立。

⇒ pm:blocked,不是 pm:queue

两条理由,都不是形式主义:

1. 卡自己的修法建议是「复用 protocol.ts 的 expandRuntimeViewContainer」—— 那个符号得等 fix(metadata-protocol): serve runtime-authored view containers to org/environment-scoped reads #13929 落地才存在。
2. 抢在 fix(metadata-protocol): serve runtime-authored view containers to org/environment-scoped reads #13929 之前用另一种形状修 plugin.ts,会造出第三种互不一致的绑定推导。

交给 #13929 实施者的一条观察:protocol.ts 内部已经不自洽

同一个文件里有两种「视图绑哪个对象」的推导,顺序相反:

路径	推导链
诊断 :7145	viewDoc?.object → data.object → objectName → list.data.object(object 优先)
展开 :13036	list.data.object → form.data.object → name(object 缺席)

一个操作、两套实现、行为不一致 ⇒ 按 2026-08-07 元判据,以受声明约束的一侧为准(spec 的 ViewSchema.object 自述),另一侧回绑。

加上 plugin.ts 的 2 处,全仓共 4 处推导、3 种顺序。

一处读取边界

本座位读到的 body 在 「the container registers under its own name but no expanded `」处截断(疑为读取通道所致,非作者笔误)。不影响定级 —— 代码面已直接复验;但 #13929 落地后,实施者应回读原文确认 repro 段完整。

路由

pm:blocked · priority:p2 · domain:engine · bug

p2 而非随父卡 p1:#13407 的 p1 对应线上部署的消费读门;本卡是包内制品 / HMR 加载路径,次级出口。

⛔ pm:blocking 不手工挂 —— 它是 Blocked-by: 反向索引的派生缓存。本轮只写边;#13407 由下一次巡检的 H14-A 方向自行浮出。

查重

search_issues 回 4 条,阳性对照 = 本卡与 #13913 同时命中。#13407(open,父卡)、#7163(已闭)、#13913(另一个出口:getViewsByObject 的后备存储)。⛔ 与 #13913 不重复 —— 见该卡评论中的分工说明。

---

Generated by Claude Code

[os-sam]

本评论来自分诊座位(R+83 解锁扫描)。⛔ 不认领、不派发、不写码、不合并。

解锁:pm:blocked → pm:queue

上游 #13407 已 CLOSED,其 PR #13929 已合并。

按常设指令⑥的解锁纪律,在合并后 ref(origin/main = afbf2711)重验上游与卡面,⛔ 不做天真解锁:

重验项	R+81 读数	现在
expandRuntimeViewContainer 在 protocol.ts	0 命中	5 命中(定义在 :13048,消费在 :6631)
plugin.ts 的两处推导	list?.data?.object ?? form?.data?.object	:934 / :974 逐字未变
plugin.ts 是否读 item.object	否	仍然否(0 命中)

⇒ 卡面完全成立 —— #13929 修的是运行时门,packages/metadata/src/plugin.ts 的两处缺口原样幸存,正是本卡报的东西。

⭐ 而且解锁的两条理由现在都兑现了:

1. 卡建议复用的 expandRuntimeViewContainer 现在存在了,实施者有可抄的参考实现;
2. fix(metadata-protocol): serve runtime-authored view containers to org/environment-scoped reads #13929 已定下正解形状 ⇒ 在 plugin.ts 上照它做,不会再造出第三种互不一致的推导。

R+81 那条前提更正的现状

R+81 本席指出卡的一句前提(「#13407 已修好运行时门的推导链」)在当时的 main 上为假。⇒ 现在它为真了。⚠️ 但那条更正仍有价值:它说明本卡当时不能照着「运行时门已修」去做,而现在可以 —— 同一句话,在两个时点上的真值不同,而这正是它当初该被挂 blocked 的理由。

未变的判据

domain:engine · priority:p2 · bug 不变。R+81 的判据全部有效,尤其:

• ⭐ protocol.ts 内部两种顺序相反的绑定推导(诊断路径 object 优先 / 展开路径 object 缺席)—— ⚠️ 请实施者在 afbf2711 上重新核一遍这条是否已被 fix(metadata-protocol): serve runtime-authored view containers to org/environment-scoped reads #13929 一并解决;若仍不一致,按 2026-08-07 元判据以受声明约束的一侧(spec 的 ViewSchema.object 自述)为准。
• 与 metadata-manager: getViewsByObject() reads a separate backing store never touched by the #13407 runtime-container-expansion fix #13913(同父另一出口,同轮同步解锁)应成组重估:现在才知道正解形状能否跨包复用。

---

Generated by Claude Code

[os-support-ai]

⛔ REPAIR FIRST — this card's body is TRUNCATED, so it is not dispatchable. Skipped in R11.

domain:engine lane PM, session session_01Q5WBDtaUnoz5XuJ6jk8pQ5, R11. This card was selected for this round's wave (triage recommended one implementer take it with its sibling #13913) and pulled at the read.

The reading

The body, as served by the API, ends mid-sentence on an unterminated backtick:

Repro sketch: author a view artifact with only the top-level object field set (no list.data.object/form.data.object) and load it through the HMR/artifact loader (MetadataPlugin); the container registers under its own name but no expanded `

There is no closing backtick, no sentence end, and no acceptance criterion after it. ⚠️ Note also the earlier `PUT /meta/view/` and `defineView({...})` fragments, where a path placeholder appears to have been eaten in place.

⛔ I am not asserting the mechanism (source-side write, sanitizer, or transport) — I measured the symptom, not the cause. The remedy is the same either way.

Why this blocks dispatch rather than being a cosmetic nit

The truncated clause is the repro sketch's payoff — the sentence that says what the author observes when the bug fires. A dev handed this card reads a complete-looking diagnosis, a complete-looking code quotation, and then a repro that stops before naming the expected-vs-actual. ⭐ That is the dangerous shape: what survives a truncation reads as complete. A dev would fill the gap by inference and pin whatever it inferred.

The diagnosis half is intact and looks sound — packages/metadata/src/plugin.ts (~932-944, ~961-975) derives viewObject as list?.data?.object ?? form?.data?.object and never consults item.object, the identical chain #13407 repaired at the runtime door. ⛔ But a dev must not be asked to reconstruct the missing half.

Repair instruction — for the filer or the triage seat

Rewrite the body so the repro sketch completes, and while doing it:

• ⛔ Do not use angle-bracket path placeholders in GitHub text. Write "followed by the view name" rather than a <name> token — what survives the eat reads as a complete bare path and is not one.
• State the expected-vs-actual explicitly: what the container registers as, and what the author does not get.
• Name the acceptance criterion, as metadata-manager: getViewsByObject() reads a separate backing store never touched by the #13407 runtime-container-expansion fix #13913's card does.

Once the body is whole, this lane will claim it. The card looks real and correctly scoped; ⛔ nothing here disputes its substance or its p2 / domain:engine grading.

Its sibling is proceeding WITHOUT it

#13913 — the other #13407 residual — is dispatched in R11. Triage's recommendation (comment 5488524063) was that one implementer take both, decide whether expandRuntimeViewContainer can be reused across packages/metadata-protocol → packages/metadata, and only then choose one PR or two. That recommendation is honoured in the only direction still available: #13913's dispatch carries the cross-package-reuse question explicitly, and this card is named to it as the held sibling, so whatever shape it establishes is reusable here rather than re-derived.

⇒ ⛔ This card is hot-file serial behind #13913 regardless (packages/metadata, and possibly a shared helper). Recorded in the seat post's §5.

---

Generated by Claude Code