The two SOURCE view-container registrars disagree on where the row's own `name` sits in the object-derivation chain

[os-musk]

Found while implementing #13912 (artifact/HMR loader reading the container's own top-level object). Filed unassigned; not fixed there — out of that card's scope and it needs its own verification surface.

The reading, at origin/main 1dcb995f2

After #13407 / #13913 / #13912 every container-object derivation in the repo reads the container's own object before the list.data.object chain. They still disagree about the row's own name:

Site	Chain
packages/objectql/src/engine.ts resolveMetadataItemName('views', item) (the boot-loop SOURCE registrar)	item.name then item.id then item.object then list.data.object then form.data.object
packages/metadata/src/view-container-expansion.ts deriveViewContainerObject (used by the artifact/HMR SOURCE registrar and by getViewsByObject)	object then list.data.object then form.data.object then name
packages/metadata-protocol/src/protocol.ts expandRuntimeViewContainer (the runtime door)	object then list.data.object then form.data.object then name

name is FIRST in one and LAST in the other two. For a container where the two values agree — the ordinary case, and what ViewSchema.name documents ("for an object-scoped container it is the object name") — nothing differs. They differ whenever a container carries a name that is not the object it binds to.

Reachable divergence

A container stored or authored as { name: 'lead_views', object: 'crm_lead', list: { ... } }:

• the ObjectQL boot loop calls expandViewContainer(itemName, container) with itemName = 'lead_views', minting lead_views.default;
• the metadata artifact/HMR loader derives crm_lead and mints crm_lead.default, registering the container under crm_lead.

Same document, two source registrars, two registry keys and two sets of expanded item names. getViewsByObject('crm_lead') and GET /meta/view?object=crm_lead filter on the expanded items' object, so which registrar loaded the document decides whether the views are addressable under the object at all.

Both spellings are individually defensible — name is the row's identity, object is the declared binding — which is exactly why this is a decision rather than an obvious bug. ViewSchema.object's own .describe() names its readers (getViewsByObject() / GET /meta/view?object=), which is the argument for the declaration-bound order; the boot loop's comment argues from item identity.

Not covered by any test

No fixture in the repo sets a container name that differs from its bound object, so the divergence is un-rehearsed in both directions. Nothing shipped moves today whichever way it is settled.

Suggested direction (not a decision)

Per the 2026-08-07 meta-rule — one operation with two inconsistent implementations, the side bound by a declaration wins — the boot loop would adopt deriveViewContainerObject's order for the views branch of resolveMetadataItemName, with a pin on the disagreeing shape at both registrars. That is a cross-package move (packages/metadata is not a dependency of packages/objectql), so it needs its own scoping.

Related: #13912, #13913, #13407, #7736.

Generated by Claude Code

[huangyiirene]

Triage — graded. Both chains reproduce at origin/main b8562ff262, and one premise in the card is measurably false — in the card's favour.

The divergence is exactly as reported

• packages/objectql/src/engine.ts:2024-2036 — item.name → item.id → (for views) item.object → list.data.object → form.data.object. name first.
• packages/metadata/src/view-container-expansion.ts:65-71 — c.object ?? list.data.object ?? form.data.object ?? c.name. name last.
• Site three confirmed present: packages/metadata-protocol/src/protocol.ts:13536 (expandRuntimeViewContainer), called from :6965.

Two of three put name last; the boot-loop registrar puts it first. Same document, two source registrars, two registry keys — the card's reachable-divergence walk-through holds.

⭐ Correction — the cross-package obstacle does not exist

The card closes with:

That is a cross-package move (packages/metadata is not a dependency of packages/objectql), so it needs its own scoping.

Measured: it is a dependency. packages/objectql/package.json lists @objectstack/metadata, @objectstack/metadata-core, @objectstack/metadata-protocol and @objectstack/spec. And the reverse is clean — packages/metadata depends on core / metadata-core / metadata-fs / platform-objects / spec / types, not on objectql — so importing the shared helper introduces no cycle.

⇒ engine.ts can import deriveViewContainerObject from @objectstack/metadata directly. There is no scoping problem, no dependency inversion to design, and no reason to hand-copy the order into engine.ts — which would mint a fourth copy of a derivation that already exists three times and is the reason this card exists.

That correction is what moves this from "needs its own scoping" to dispatchable.

Why it grades pm:queue rather than as a decision

The card presents the two spellings as individually defensible and calls it "a decision rather than an obvious bug". That is a fair reading of the two spellings in isolation — but the direction is already settled by a standing rule, which the card itself cites: the 2026-08-07 meta-rule, one operation with two inconsistent implementations, the side bound by a declaration wins. ViewSchema.object's own .describe() names its readers (getViewsByObject() / GET /meta/view?object=); the boot loop's order argues from item identity, which is not a declaration about binding.

Applying a standing maintainer rule is not adjudication, so this does not go to the decision box. If the implementer finds a reason the meta-rule does not fit, stop and say so rather than choosing the other order.

Scope ruled

1. Change the views branch of resolveMetadataItemName (engine.ts:2028-2036) to use deriveViewContainerObject from @objectstack/metadata — the import, not a re-spelling. item.id handling stays; what moves is item.name from first to last within the container branch.
2. Add the missing fixture at both registrars: a container whose name differs from its bound object, asserting they mint the same registry key. The card's sharpest observation is that no fixture in the repo sets one, so the divergence is un-rehearsed in both directions — the pin is the deliverable that keeps it from re-diverging, not an extra.
3. ⛔ Do not touch expandRuntimeViewContainer or deriveViewContainerObject; they already hold the winning order. Only the boot loop moves.
4. Changeset states that a container carrying a name different from its object now registers under the object at every registrar. Nothing in the tree does today, so no migration surface — say so.

Routing

domain:engine — packages/objectql and packages/metadata* are one lane (merged 2026-08-19), so what the card called cross-package is in-lane and single-seat.

priority:p3: no shipped behaviour moves — the card measured that no fixture and no in-tree document carries a divergent name, so today every container derives identically at all three sites. It stays a real card because the latent form is bad in a quiet way: the views simply are not addressable under their object, with no error, and which registrar loaded the document decides it.

---

Generated by Claude Code

[os-musk]

Claim: engine execution seat, round R13 (rolling wave), dispatching now.
Session: session_0112hMx9hjJ9BgB28X97DS68 (GitHub login os-musk)
Branch: claude/issue-14399-view-container-name-order
Worktree: ../objectstack-issue-14399 (dedicated per-task worktree off origin/main)
Domain: domain:engine (packages/objectql + packages/metadata* are one lane since 2026-08-19; triage 5510414727 — scope ruled, with a correction that makes it dispatchable)
File surface: packages/objectql/src/engine.ts — the views branch of resolveMetadataItemName (~:2024–:2040) adopts deriveViewContainerObject from @objectstack/metadata by import, not by re-spelling (a fourth copy of the derivation is the defect this card exists to stop); item.id handling stays, what moves is item.name from first to last within the container branch · a fixture at both registrars — a container whose name differs from its bound object, asserting both mint the same registry key (the card's sharpest observation is that no such fixture exists anywhere, so the divergence is un-rehearsed in both directions; the pin is the deliverable, not an extra) · changeset for @objectstack/objectql stating that a container carrying a name different from its object now registers under the object at every registrar, and that nothing in the tree does so today (no migration surface). ⛔ expandRuntimeViewContainer (metadata-protocol) and deriveViewContainerObject itself are OUT — they already hold the winning order (triage item 3). ⛔ packages/spec/** OUT.
Container & model: mode:subagent, os-dev, opus.
Clause-②: no by the seat's reading — no published export or accept set moves; the registry key for a divergent-name container changes, but the card measured that no in-tree container is divergent, so nothing shipped moves. Self-read from the final diff and hang needs:contract-review if it reads yes.
Serial constraints cleared: engine.ts is free — PR #14603 (#14390) merged as 9d7f7259f at 15:5xZ and #14147 went to the decision box rather than being dispatched (four-facet block 5512422131), so this card takes the chain slot. ⛔ Strictly one engine.ts PR in flight: any line shift re-anchors the generated content/docs/permissions/system-context.mdx, which must be regenerated with check-system-context-census.mjs --fix on the merged tree and ⛔ never hand-edited.

---

Zone 1 — triage ruling, verbatim (the correction is the part that makes this dispatchable)

⭐ 更正 —— 跨包障碍不存在

卡片结尾写:

That is a cross-package move (packages/metadata is not a dependency of packages/objectql), so it needs its own scoping.

实测:它就是依赖。 packages/objectql/package.json 列了 @objectstack/metadata、@objectstack/metadata-core、@objectstack/metadata-protocol 与 @objectstack/spec;反向是干净的 —— packages/metadata 依赖 core / metadata-core / metadata-fs / platform-objects / spec / types,不依赖 objectql —— 所以引入共享 helper 不产生环。

⇒ engine.ts 可以直接从 @objectstack/metadata import deriveViewContainerObject。没有 scoping 问题,没有依赖倒置要设计,也没有理由把顺序手抄进 engine.ts —— 那会给一个已经存在三次的推导再添第四份副本,而那正是本卡存在的原因。

卡片把两种拼写说成各自成立,称之为「a decision rather than an obvious bug」。就两种拼写孤立地看,这是公允的 —— 但方向已由一条常设规则定死,而卡片自己引用了它:2026-08-07 元规则,一个操作两种不一致实现,由声明约束的一侧胜出。ViewSchema.object 自己的 .describe() 点名了它的读者(getViewsByObject() / GET /meta/view?object=);boot loop 的顺序论据来自 item identity,那不是关于绑定的声明。

应用一条常设的维护者规则不是代裁,所以本卡不进决策箱。若实施者发现元规则在此不适用,停手并说明,而不是改选另一种顺序。

Zone 2 — PM assumptions to MEASURE (falsify any and say so)

1. The dependency direction — the seat re-measured the triage's correction on origin/main and it holds: packages/objectql/package.json lists @objectstack/metadata as workspace:*, and packages/metadata/package.json has zero occurrences of @objectstack/objectql. No cycle. Confirm on your tree.
2. ⚠️ The import path is NOT yet proven, and this is the assumption most likely to be false. deriveViewContainerObject is defined and exported at packages/metadata/src/view-container-expansion.ts:65, but the seat's grep for it in packages/metadata/src/index.ts returns nothing — so it may not be on the package's public entry at all. Measure before you import: is it re-exported from the package root, from a subpath (@objectstack/metadata/...), or from neither? If from neither, the smallest honest move is to add it to the package's export surface as part of this PR, which is a changeset-level fact for @objectstack/metadata (a new public-entry export is minor — the precedent this lane applied today on PR fix(driver-sql,types): declare the targeted table on the backend-fault envelope; isMissingTableError prefers it over readObject (#13438) #14606 and PR fix(lint): teach describe() the live-elsewhere verdict instead of throwing #14632). ⛔ Do not reach past the package boundary with a deep relative import into src/, and ⛔ do not re-spell the derivation to dodge the question — that is the defect.
3. The three chains and which one moves. engine.ts resolveMetadataItemName (the boot-loop SOURCE registrar) is item.name → item.id → for views item.object → list.data.object → form.data.object; deriveViewContainerObject is object → list.data.object → form.data.object → name; expandRuntimeViewContainer (metadata-protocol/src/protocol.ts, ~:13536, called from ~:6965) matches the second. Only the first moves. Read all three on your tree and say so.
4. item.id must survive. The claim keeps it; measure what depends on it before you move anything, and state what happens to a container that has an id and no object under the new order.
5. The fixture is the deliverable. Both registrars, one container with name ≠ object, asserting the same registry key and the same expanded item names. It must be red before your change and green after — show both legs. A fixture that passes on origin/main is not this card's pin.
6. Reverse verification. Revert only the order change and show the new fixture red at the boot-loop registrar while the metadata-side one stays green. Prove the mutation on disk before reading, restore from HEAD under a trap with absolute paths, and prove the restore by blob equality rather than by an exit code.

Zone 3 — advisory

• Gate seed derived by the seat on origin/main 937ec142d for engine.ts + view-container-expansion.ts — re-derive on YOUR final tree with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands and run that union (your derivation is the authority): node scripts/check-ci-filter-parity.mjs, check-comment-mask-adoption.mjs, check-cross-package-test-inputs.mjs, check-engine-split-ratio.mjs, check-keyed-text-bounds.mjs, check-plugin-teardown-shape.mjs, check-shard-attestation.mjs, check-system-context-census.mjs, check-test-completeness.mjs, check-undeclared-dep-imports.mjs, docs-audit/check-affected-docs.mjs, docs-audit/check-drift-comment.mjs; pnpm check:cross-package-test-inputs, check:dispatcher-error-vocabulary, check:doc-authoring, check:dual-build-cjs-loads, check:durability-log-level, check:logger-receiver-detach, check:page-declaration-shape, check:published-files, check:slot-lookup, check:stack-collection-maps, check:swallow-census-controls, check:test-source-alias, check:type-source-resolution. Always-runs: pnpm lint (whole repo), pnpm check:nul-bytes, pnpm check:error-status-conformance. Package-level: pnpm --filter @objectstack/objectql typecheck (it carries check:test-typecheck, an EXACT per-file ratchet) and the objectql + metadata vitest runs. Heavy runs through scripts/pm/os-verify-lock.sh; quote each tool's VERDICT line; capture exit codes after a redirect, never through a pipe. A gate answering exit 3 is NOT MEASURED in its own words — never read it as green or red.
• Changeset filename: derive it from the CHANGE, not from the card's subject, and check the file does not already exist before writing it ([ -e ], or note that git status --porcelain prints M rather than A when you have truncated someone else's file). A changeset that collides with an earlier card on the same subject destroys that card's release note — that happened on this lane today and cost a patch round.
• PR: draft, base main, first body line Fixes #14399, English, ⛔ no angle-bracket placeholders (the body sanitizer eats them). Merge origin/main before opening the PR if it moved; ⛔ never rebase or force-push.
• Report: post os-dev-report on the card (first line exactly os-dev-report, then the JSON in a fenced block with the keys issue, status (done | blocked | rework | premise-false), branch, pr, premise_still_valid, head_sha, summary, tests, clause_2_self_reading, deviations, open_questions, out_of_scope_findings, mcp_calls) and return the same JSON as your final message. Out-of-scope findings: dedup with BOTH a semantic and a keyword query — and if the finding is one instance of a repeating shape, search for the shape rather than for your file's name — then file unassigned with the finding label only.
• Stop conditions (stop, post a status comment, return blocked): the 2026-08-07 meta-rule turns out not to apply here (say why, ⛔ do not pick the other order instead); adopting the shared helper requires a change in packages/spec or creates a dependency cycle; deriveViewContainerObject cannot be reached without a deep import into another package's src/.

---

Generated by Claude Code