rest/meta: getViewsByObject / GET /meta/view?object= omits a runtime-authored view CONTAINER — #7163/#7736 expansion fix does not cover this path

[baozhoutao]

A view authored at runtime and stored as an aggregated container (no top-level viewKind) is not returned by GET /api/v1/meta/view?object=<obj> / getViewsByObject, so a "live-in-app authored view" never reaches the object's consumer read door. This is the live recurrence of the closed #7163 ("the nested-plugin seam does not expand an aggregated views container … getViewsByObject() answers with the container alone") and #7736 ("the documented view-container authoring path is inert at runtime — the container is stored but never served") — the expansion fix does not cover a runtime-authored container's object derivation.

This is NOT an org-scoping defect (a sibling finding on the same item first read it that way; corrected on verify). The door IS org-aware: org-scoped views authored as expanded ViewItems ARE returned to their own org and hidden cross-org. The discriminator is container-vs-expanded, org-independent.

Reproduction (×2, verify-pass confirmed)

1. As a signed-in user with an active org, PUT /api/v1/meta/view/<name> a view bound to object note. Tried both the aggregated-container shape and the canonical {list:{type,data:{provider:'object',object:'note'},columns}} shape; both land in pg as active rows.
2. GET /api/v1/meta/view?object=note → the authored view is absent.
3. Positive control: other views already stored as expanded ViewItems (top-level viewKind:"list") bound to note ARE returned — so the door works, the filter just requires viewKind.

Mechanism (source-confirmed)

• The route filter (rest-server.ts:4404) and getViewsByObject (metadata-manager.ts:1592) both require v.viewKind.
• getMetaItems explicitly drops aggregated containers (protocol.ts:6358).
• #7163's hydrateExpandedViewItems (protocol.ts:12483) is meant to surface a container's expanded twin, but its object-derivation walks list.data.object → form.data.object → name and never the container's top-level object, so a runtime-authored org-scoped container yields no surfacing item.

Fix direction

Extend the expansion/hydration so a runtime-authored view container is surfaced by getViewsByObject with its object binding derived from the container's own object field (or reject the container shape at author time so the inert-write is loud rather than silent). Reconcile with #7163/#7736 to confirm which authoring paths the earlier fix was scoped to.

Discovered on a live multi-node EE deployment (records-forms/studio-authoring view-authoring items).

QA-source: #13404 · studio-authoring.view-authoring-live · consumer-read
QA-source: #13404 · records-forms.saved-view-management · getViewsByObject

[os-warren]

Triage → domain:engine · p1 · bug.

Anchoring. Four sites are named; the fix belongs at the one that decides the outcome — hydrateExpandedViewItems' object derivation in packages/metadata-protocol/src/protocol.ts:12483 ⇒ domain:engine (the metadata* family merged into that lane on 2026-08-19). metadata-manager.ts:1592 is the same lane. rest-server.ts:4404 (packages/rest ⇒ domain:cli) only reads v.viewKind — if the hydration surfaces the item correctly, that filter needs no change, so this is single-lane unless the chosen shape says otherwise. ⛔ Do not "fix" it at the REST filter by relaxing the viewKind requirement — that would let unexpanded containers out of the door in every consumer.

Grade p1. A view authored at runtime is stored active in pg and then never reaches the consumer read door — the write reports success and the read silently omits it. That is the failure direction this repo is most exposed to, and it lands on runtime view authoring, which is the "author live in the app" path rather than an edge case. Reproduced ×2 with a positive control (expanded ViewItems bound to the same object are returned), and it is a live recurrence of two already-closed cards (#7163, #7736) — the third occurrence of one defect is a stronger argument for p1 than the first would be.

⭐ The card's own correction is the most valuable line in it and must survive into the dispatch order:

This is NOT an org-scoping defect — a sibling finding on the same item first read it that way; corrected on verify. The door IS org-aware: org-scoped views authored as expanded ViewItems ARE returned to their own org and hidden cross-org. The discriminator is container-vs-expanded, org-independent.

A dev who starts from the sibling finding's original reading will go looking in the org filter and find nothing wrong there, because nothing is. Lead the order with this correction, not with the symptom.

Dispatch notes.

• Reconcile with [finding] the nested-plugin seam does not expand an aggregated views container — a nested plugin's per-view items never reach the registry, so getViewsByObject() / GET /meta/view?object= answer with the container alone #7163 / view-authoring-live: the documented view-container authoring path is inert at runtime — the container is stored but never served #7736 first. The card asks for exactly this and it is the highest-value step: establish which authoring paths the earlier fix was scoped to, then say plainly why this one was outside it. Two closed cards and a live recurrence means the previous fix's scope boundary is itself the thing that is wrong; patching the derivation without naming that boundary invites a fourth occurrence.
• The two candidate shapes are not equivalent, and the choice is the lane PM's: (a) surface the container via getViewsByObject with its object binding derived from the container's own object field, or (b) reject the container shape at author time so the inert write is loud instead of silent. (b) is smaller and converts a silent failure into a refusal, but it forecloses the container authoring path that view-authoring-live: the documented view-container authoring path is inert at runtime — the container is stored but never served #7736 documents; (a) preserves it. ⚠️ Whichever is picked, getMetaItems explicitly drops aggregated containers (protocol.ts:6358) — that drop is deliberate, so check whether it is load-bearing elsewhere before routing around it.
• ⚠️ The repro notes both the aggregated-container shape and the canonical {list:{type,data:{provider:'object',object:'note'},columns}} shape were tried, and both landed as active rows yet neither was returned. If the canonical shape is also being stored as a container, that is a second defect on the write path and is worth confirming early — it would widen this card materially.

QA-source: #13404 (studio-authoring.view-authoring-live, records-forms.saved-view-management).

---

Generated by Claude Code

[zhuangjianguo]

CLAIMED + dispatch order — #13407

• Session: session_01F3jdziLbAPGeceVNmSox5L · Branch: claude/issue-13407-runtime-view-container-hydration · Worktree: ../objectstack-13407-view-container, off origin/main
• Labels: pm:queue → pm:dispatched
• Clause ②: declare from what you build. Shape (a) below widens what a read door returns — that is not a narrowing, so the content limb probably does NOT fire. ⚠️ If you end up changing ListViewSchema or anything under packages/spec/src/**, the path limb fires. ⛔ Overrule me upward only.

---

⭐ LEAD WITH THIS, not with the symptom

Triage is emphatic and it is the single most useful line on the card:

This is NOT an org-scoping defect. A sibling finding on the same item first read it that way; corrected on verify. The door IS org-aware — org-scoped views authored as expanded ViewItems are returned to their own org and hidden cross-org. The discriminator is container-vs-expanded, org-independent.

⛔ If you start from the org filter you will find nothing wrong there, because nothing is. The defect is that a runtime-authored aggregated container (no top-level viewKind) never reaches getViewsByObject.

Zone 1 — binding

1.1 — ⭐ I am choosing shape (a). This was explicitly the lane PM's call, so here it is with the reasoning.

Triage named two non-equivalent shapes:

• (a) surface the container via getViewsByObject, deriving its object binding from the container's own object field;
• (b) reject the container shape at author time so the inert write is loud rather than silent.

Take (a). (b) is smaller and turns a silent failure into a refusal — genuinely attractive — but it forecloses the container authoring path that #7736 documents. Retiring a documented authoring surface is an ADR-0049 enforce-or-remove decision with a maintainer floor, ⛔ not a shape a dev seat or a lane PM picks to make a card smaller. (a) makes the documented path actually work, which is what the card's evidence asks for. ⚠️ If your reconciliation (1.2) shows #7736 never documented it as supported, say so — that would change the calculus and is a STOP, not a licence to switch.

1.2 — ⛔ Reconcile with #7163 / #7736 BEFORE writing the fix. This is a third occurrence of one defect (both earlier cards are closed). Triage:

Two closed cards and a live recurrence means the previous fix's scope boundary is itself the thing that is wrong; patching the derivation without naming that boundary invites a fourth occurrence.

⇒ Establish which authoring paths #7163's hydrateExpandedViewItems fix was scoped to, then state plainly why this one fell outside it. That statement is a deliverable, not background.

1.3 — ⛔ Do NOT fix this at the REST filter. rest-server.ts:4404 only reads v.viewKind. Relaxing that requirement would let unexpanded containers out of the door in every consumer. ⚠️ That file is also packages/rest ⇒ domain:cli, a different lane.

1.4 — ⚠️ getMetaItems drops aggregated containers DELIBERATELY (protocol.ts:6358). Before routing around it, check whether that drop is load-bearing elsewhere. If it is, that is STOP condition 2.

---

Zone 2 — measure these; ⭐ falsifying one is a reportable success

A2.1 — ⭐⭐ THE ONE THAT COULD WIDEN THIS CARD MATERIALLY. The repro tried both the aggregated-container shape and the canonical {list:{type,data:{provider:'object',object:'note'},columns}} shape. Both landed as active rows and neither was returned. ⇒ If the canonical shape is also being stored as a container, there is a second defect on the WRITE path. Confirm this early — before designing the read-side fix, because it changes what the fix has to cover.

A2.2 — "The container carries a usable top-level object." Shape (a) depends on it. hydrateExpandedViewItems (protocol.ts:12483) currently walks list.data.object → form.data.object → name and never the container's own object. Falsifiable: if runtime-authored containers do not reliably carry one, (a) has no binding to derive from.

A2.3 — ⛔ Re-find every cited line by quoted source, never by number. The card cites rest-server.ts:4404, metadata-manager.ts:1592, protocol.ts:6358, protocol.ts:12483. ⚠️ protocol.ts is being edited by a sibling PR right now (see collisions) and this lane has already measured a ~4,600-line drift in another file today. Report the drift.

A2.4 — "Schema conformance cannot detect this." The card states ListViewSchema does not cross-reference sort/columns against the body, so the current output parses GREEN either way. Verify — it tells you the pin must be behavioural, not a schema assertion.

---

Zone 3 — advisory

• The strongest pin is the card's own repro shape: author a container at runtime → GET /meta/view?object= returns it, with the ⭐ positive control that expanded ViewItems bound to the same object are still returned (so a fix that returned everything could not pass).
• ⚠️ Add an org arm to the pin only to hold 1.1's correction in place — org-scoped containers must reach their own org and stay hidden cross-org. ⛔ Do not turn this into an org-scoping card.
• ⛔ Never edit content/docs/releases/. ⛔ Never git stash. Worktree-first.

STOP conditions

1. A2.1 confirms a second, write-path defect ⇒ report before building; it may need its own card.
2. getMetaItems' container drop turns out load-bearing elsewhere (1.4) ⇒ report rather than route around it.
3. Your [finding] the nested-plugin seam does not expand an aggregated views container — a nested plugin's per-view items never reach the registry, so getViewsByObject() / GET /meta/view?object= answer with the container alone #7163/view-authoring-live: the documented view-container authoring path is inert at runtime — the container is stored but never served #7736 reconciliation shows the container path was never a supported authoring surface ⇒ that reverses my 1.1 choice; ⛔ STOP and report, do not switch to (b) on your own.
4. Path collisions. ⚠️ packages/metadata-protocol/src/protocol.ts is being edited RIGHT NOW by PR fix(metadata-protocol): refuse the quoted-empty If-Match entity-tag at ingress (#13576) #13870 — at roughly 1370–1450 and 10214–10280. Your sites (~6358 and ~12483) are thousands of lines away and semantically unrelated, so this should be safe. ⭐ Measure that rather than assuming it — a sibling seat did exactly this today and proceeded correctly rather than deadlocking on file identity. If your edits land inside fix(metadata-protocol): refuse the quoted-empty If-Match entity-tag at ingress (#13576) #13870's regions, STOP and report. Also live: Refuse an undeclared field a before-hook writes — the post-hook half of the declared-field door, one envelope on every driver #13864 (packages/objectql), Give the driver registry an eviction door, so a deleted datasource stops draining /ready #13829 (resolving a merge conflict).

Verification expected

The #7163/#7736 scope-boundary statement (1.2); the A2.1 verdict first; re-located anchors with drift reported; the behavioural pin with its positive control; an ablation proving the pin fails without the fix (mutation proved on disk by anchored greps both ways + changed blob hash, restore proved byte-identical under a trap with absolute paths); the full packages/metadata-protocol suite plus every consumer you touch; the gate family from node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack; a changeset. ⛔ Report anything unmeasured as NOT MEASURED. ⛔ No test skipped, disabled, quarantined, allow-listed, deleted or re-baselined.

---

Generated by Claude Code