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

Activity

1. huangyiirene

   added

   bugSomething isn't workingSomething isn't working

   pm:queue

   domain:metadata

   on Aug 11, 2026
2. huangyiirene commented on Aug 12, 2026

   

   huangyiirene

   on Aug 12, 2026 – with Claude

   CollaboratorAuthor

   More actions

   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
3. huangyiirene

   added

   pm:dispatched

   and removed

   pm:queue

   on Aug 12, 2026
4. huangyiirene

   self-assigned this

   on Aug 12, 2026
5. huangyiirene

   closed this as completedin #8257on Aug 13, 2026
6. huangyiirene commented on Aug 13, 2026

   

   huangyiirene

   on Aug 13, 2026 – with Claude

   CollaboratorAuthor

   More actions

   Dev report relayed by the PM (its container is 403 on the whole GitHub API — the second attempt returned the sharper "org admin must connect the Claude GitHub App"). It read this card in the web UI via WebFetch, so its verdict is against the full body.

   ⚠️ Disclosure: I merged PR #8257 against the dev's stated instruction

   Its report ends "Open the PR as draft; I did not enable auto-merge and did not flip ready." I never saw that — the dev could not open a PR, so I created #8257 myself from its pushed branch with a body I wrote, reviewed the diff, and merged it as 0e1f6679b4.

   This is now the second time in one shift (the same happened on #8258/#8037), which makes it a process gap rather than an accident: a 403-blocked dev puts its merge conditions in the PR body, and reconstructing that body from the branch loses them. ⇒ Recorded on the seat post: when opening a PR on a blocked dev's behalf, ask for its intended PR body first, and treat "draft" as the default until the dev says otherwise.

   On the merits the merge stands — the diff was reviewed, CI was fully green, and the report below confirms the change is what I judged it to be. But the instruction existed and I overrode it unknowingly, so it goes on the record.

   The verdict: wrong-source bug — ⛔ not an unbuilt capability

   premise_still_valid: true, and every claim reproduced independently before the dev read the card.

   Probe	Result
   Write a defineView container via saveMetaItem	accepted
   Stored body	verbatim — list, listViews, name; no object, no viewKind
   getMetaItem by name	present, badged _diagnostics: {valid: true}
   getMetaItems({type:'view'})	0
   Switcher predicate (viewKind && object===)	0
   Control — flat ViewItem written the same way	1 served, 1 switcher match ✅
   Well-formedness — expand the stored body	2 items, both would match the switcher

   ⭐ That last row is what decides the triage. The stored container is well-formed — it expands cleanly into exactly the items the switcher wants. So this is neither a malformed write nor #7893's "read path never built": the read path exists and demonstrably works (the control proves it), and the expansion capability exists too, applied at two of three entry points (objectql/engine.ts boot loop, metadata/plugin.ts artifact/HMR loader — both green). The runtime door is the third seam and skipped it. That is the #7163 shape this card itself named.

   ⭐ It also reports correcting itself: it initially leaned toward a design exit, on the grounds that expandViewContainer hard-codes scope:'package' while sys_view_definition forbids that value at runtime. Reading the card corrected it — the repro is a writable runtime package, where package scope is right and sys_view_definition is the wrong store to reason about. Stating the abandoned hypothesis is worth as much as the conclusion.

   ⭐ The trap it avoided — and this is the valuable part

   Two tempting wrong fixes, both rejected with reasons:

   1. Loosen the getMetaItems container filter. That filter drops containers from enumeration on a stated invariant — "the registrar expands it into independent ViewItems" — true for source-registered rows, false for runtime-written ones. Loosening it would surface the legacy wrapper to every list consumer while still showing the switcher nothing. Filter left untouched.
   2. Fix at a read exit. There are two independent object-bound readers: REST /meta/view?object= goes through getMetaItems, but getViewsByObject() reads MetadataManager.list. Fixing either one fixes the literal repro and leaves its sibling empty — exactly Object-extension overlay fields are missing from GET /meta/object/:name (present in the list route) — the overlay's fields can never be set through the UI #7556's shape.

   So the fix went to hydrateOverlayIntoRegistry, documented in-repo as "the ONE choke point all three hydration callers (boot, read-side, write-through) already share." One expansion there serves every reader, survives restart (the card noted restart didn't help), and preserves read-your-writes. ⛔ Nothing extra is persisted — one byte-identical row, expansion derived on hydration, so an edited container leaves no stale rows.

   Reverse-verification (fix disabled at the call site)

   Case	Fix on	Fix off	Attribution
   Serves expanded ViewItems	✓	🔴	headline
   Serves the stored container, not a default	✓	🔴	anti-substitution
   No-container object stays empty	✓	🔴¹	anti-vacuity
   Container never enumerated (ADR-0017)	✓	✓	filter untouched
   Independent ViewItem unchanged	✓	✓	not "serve whatever exists"
   Container stored byte-identical	✓	✓	nothing extra persisted

   ¹ red on its positive half (crm_lead → 2); its anti-vacuity half (crm_account → empty) holds under both arms — which is what proves the fixtures distinguish authored-container from no-container.

   Gates, all post-merge and after a completed build (⛔ never concurrent with dogfood): metadata-protocol 76/1102 · metadata 31/603 · objectql 192/3400 · rest 103/1731 · runtime 145/2195 · dogfood 99 files/673 · check:type-check-debt exit 0 on a built closure, no ledger entry raised, nothing --lowered · check:nul-bytes OK · check:empty-changeset OK · eslint clean.

   Out-of-scope finding, now filed

   #8285 — ADR-0017 §3.4 cites packages/platform-objects/src/metadata/sys-view-definition.object.ts, which does not exist; the object is at packages/metadata-core/src/objects/sys-view-definition.object.ts. Out of the dev's region, so reported not fixed; it cited no number in the commit rather than invent one.

   ⭐ This card is the sixth instance of "a 200 that means nothing happened" — publish succeeded at every step and produced nothing a user could see. That family (#7893, #8018, reassignOrphanedMetadata, #7823, #7736, #8284) is carried on the seat post as an open convention question for the maintainer.

   ---

   Generated by Claude Code
7. akarma-synetal

   added a commit that references this issue on Aug 17, 2026

   fix(metadata-protocol): expand a runtime-authored view container so i…

   ...

   0e1f667
8. akarma-synetal

   added a commit that references this issue on Oct 7, 2026

   docs(qa): re-point eight checklist items the 17.6.0 release-verificat…

   ...

   5fd4855