view-authoring-live: the documented view-container authoring path is inert at runtime — the container is stored but never served

[huangyiirene]

Symptom

Authoring a view through the runtime metadata door with the documented ViewSchema container shape succeeds at every step and produces nothing a consumer can see.

• PUT /api/v1/meta/view/<name>?mode=draft&package=<pkg> with {object, list:{…}, form:{…}} → 200 state:'draft'
• POST /api/v1/meta/view/<name>/publish → 200
• GET /api/v1/meta/view?object=<obj> → {"items":[]}
• GET /api/v1/meta/view/<name> → 200 with the full authored body

So the item is stored — it is just never served. The end-user list keeps rendering synthesized default columns. A deliberate full server restart does not help: the path is inert, not restart-required. Reproduced on two objects, and with the container stored under both an arbitrary name and under the object name.

Control that isolates it. Publishing the same list and form bodies as pre-expanded ViewItems ({name, object, viewKind, config}) makes the list columns and the authored form section render live, after a client reload only. Draft isolation is clean in both shapes (pre-publish, both consumer doors report absent; only ?preview=draft exposes it), and the edit loop is repeatable with zero restarts on the shape that works.

Root cause

Container expansion exists, but it is wired to exactly one path — the artifact/package boot load — and the runtime write door is not on it.

• packages/metadata/src/plugin.ts iterates ARTIFACT_FIELD_TO_TYPE over the built objectstack.json and, for a view item that isAggregatedViewContainer() accepts, registers the container under the bare object key and registers every expandViewContainer(viewObject, item) result as its own ViewItem (origin/main lines 634-668).
• The runtime write door stores the container verbatim. packages/metadata-protocol/src/protocol.ts imports isAggregatedViewContainer (line 60) and uses it only to skip containers in a list response (line 4405) and to leave container bodies untouched during identity normalization (normalizeViewMetadata, ~line 774). It never calls expandViewContainer — that symbol has zero references anywhere in packages/metadata-protocol.
• MetadataManager.getViewsByObject() (packages/metadata/src/metadata-manager.ts:1432-1444) filters v.viewKind && v.object === object. A container carries neither, so it is filtered out by design: its own docblock says it "Returns only expanded ViewItems (those carrying a viewKind) — never the legacy aggregated container".

The three facts compose into the measured behaviour: the write door accepts and persists the container, the expansion that would give it viewKind never runs off the boot path, and the by-object consumer drops anything without viewKind.

Stale-premise check: re-verified on objectstack origin/main (00e9196). All three sites are present and unchanged in substance; only line numbers moved from what the run recorded.

Neighbour: #7163 (closed) is the same missing-expansion class on a different seam — the nested-plugin loader. That one was fixed at its own seam; the runtime write door described here was not covered by it, so the shared question — where expansion belongs so every producer gets it — is worth answering once rather than a third time.

Reproduction

1. Boot the showcase with writable runtime packages.
2. PUT /api/v1/meta/view/<name>?mode=draft&package=<pkg> with a ViewSchema container: {object: '<obj>', list: {…}, form: {…}} → 200 state:'draft'.
3. POST /api/v1/meta/view/<name>/publish → 200.
4. GET /api/v1/meta/view?object=<obj> → {"items":[]}, while GET /api/v1/meta/view/<name> returns the full body.
5. Restart the server and repeat step 4 — still {"items":[]}.
6. Control: publish the same bodies as {name, object, viewKind, config} ViewItems; after a client reload the authored list columns and form section render.

Source

Extracted from the QA run #7695 (framework 92f26f7, console 09987b680).

[huangyiirene]

Deferred one round by the domain:metadata seat — hot-file serialization, not priority. Recording it so a later sweep does not read this card as simply unpicked. It is a strong card: symptom, three composing root-cause sites, a control that isolates the seam, and a stale-premise re-check already done.

Why deferred: the repair lands in packages/metadata-protocol/src/protocol.ts — the runtime write door has to reach expandViewContainer, and that door is in protocol.ts, which is held right now by #7774 (dispatched 04:03Z, metaItemKey discriminator). That file took 6 merges in a single day recently; two agents in it at once produce conflicts that cost more than the wait.

Serial queue on protocol.ts as of 04:0xZ: #7774 (in flight) → #7491 → #7736 → #6504 → #4716.

What is already established, so the next dispatch does not re-derive it:

• ⚠️ Anchor on function names, never line numbers. This card's own body already flags that its line anchors moved between the QA run and re-verification. protocol.ts drifts within hours. The named symbols are isAggregatedViewContainer, expandViewContainer, normalizeViewMetadata, MetadataManager.getViewsByObject.
• The shared question is worth answering once. [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 (closed) was the same missing-expansion class at the nested-plugin loader seam and was fixed at that seam. This is the third time the question "where does container expansion belong so every producer gets it" comes up. ⇒ Whoever dispatches this should decide deliberately between fixing this seam (cheap, consistent 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's precedent) and moving expansion to a single choke point every producer passes (fixes the class) — and if the second, that is a shape decision that should be ruled or escalated, ⛔ not left to the dev.
• getViewsByObject's filter is by design — its docblock says it returns only expanded ViewItems and never the aggregated container. So the repair is to make expansion happen, ⛔ not to loosen that filter. A fix that makes the container itself pass the by-object filter would be treating the symptom.

---

Generated by Claude Code