Filing gate: ① a defect with a named position: two read doors disagree. reach: measured in-process at the protocol, the method the REST by-name door calls. It is not measured over REST on a real environment-scoped server.
Filed by domain:engine#1 (seat post #6367, session_017xfMoEjKUuSh2xYB8sCozp), from #21334's dev report (patch round 1, open_questions[0] and out_of_scope_findings[0]) and the seat's answer on #21334. Reader who acts: triage grades and routes. ⛔ Not a claim. This predates #21334, which neither causes nor changes it.
Measured
At PR #21430's head 8976a86f94, in-process, on an env_local kernel (the standalone stack's stamp) and on an unscoped kernel. Containers were package-scoped, environment-wide and organization-scoped, on showcase_task.
getMetaItems('view', { object }), the object door GET /api/v1/meta/view?object=…, lists the container's expanded views. For example, showcase_task.CONTAINER_NAME.in_progress, with _diagnostics.valid: true.
getMetaItem('view', 'showcase_task.CONTAINER_NAME.in_progress'), the by-name read GET /api/v1/meta/view/…, answers:
- the same row only on an unscoped kernel, for a package-scoped or environment-wide container, through registry hydration (
hydrateExpandedViewItems);
- nothing on an
env_local kernel, and nothing for an organization-scoped container on either kernel.
- The by-name read answers the container's OWN name, the stored row, on every kernel.
Mechanism (read)
- No stored row carries an expanded name.
getMetaItem expands no container, so on a kernel that does not hydrate, an expanded name has no by-name answer.
- The dev reports the same mechanism for a same-package runtime container (for example
crm_lead.pipeline). This is a code reading on this card's evidence and was not separately measured.
Governing text
Scope for whoever takes it (⛔ not a ruling)
Dedupe
Through mcp__github__search_issues, repo-scoped, open and closed:
None names the by-name answer for an expanded name.
Dedupe words: expanded view by-name 404 · getMetaItem container expansion · runtime view container listed not fetchable · env_local by-name expanded name
Generated by Claude Code
Filing gate: ① a defect with a named position: two read doors disagree.
reach:measured in-process at the protocol, the method the REST by-name door calls. It is not measured over REST on a real environment-scoped server.Filed by
domain:engine#1(seat post #6367,session_017xfMoEjKUuSh2xYB8sCozp), from #21334's dev report (patch round 1,open_questions[0]andout_of_scope_findings[0]) and the seat's answer on #21334. Reader who acts: triage grades and routes. ⛔ Not a claim. This predates #21334, which neither causes nor changes it.Measured
At PR #21430's head
8976a86f94, in-process, on anenv_localkernel (the standalone stack's stamp) and on an unscoped kernel. Containers were package-scoped, environment-wide and organization-scoped, onshowcase_task.getMetaItems('view', { object }), the object doorGET /api/v1/meta/view?object=…, lists the container's expanded views. For example,showcase_task.CONTAINER_NAME.in_progress, with_diagnostics.valid: true.getMetaItem('view', 'showcase_task.CONTAINER_NAME.in_progress'), the by-name readGET /api/v1/meta/view/…, answers:hydrateExpandedViewItems);env_localkernel, and nothing for an organization-scoped container on either kernel.Mechanism (read)
getMetaItemexpands no container, so on a kernel that does not hydrate, an expanded name has no by-name answer.crm_lead.pipeline). This is a code reading on this card's evidence and was not separately measured.Governing text
Scope for whoever takes it (⛔ not a ruling)
expandRuntimeViewContainer). Its layers, history and diff semantics for a row-less name need a decision.expandRuntimeViewContainer. PR fix(metadata-protocol): a bare-list view container on another package's object expands under its own name #21430 does not touchgetMetaItem.Dedupe
Through
mcp__github__search_issues, repo-scoped, open and closed:namecontradicts its row name and registers it under both keys; the two source registrars refuse the same document #21412 are open and on other defects of the same container family (a shadowed packaged name; a contradicting body name at save);viewscontainer — a nested plugin's per-view items never reach the registry, sogetViewsByObject()/GET /meta/view?object=answer with the container alone #7163 and view-authoring-live: the documented view-container authoring path is inert at runtime — the container is stored but never served #7736 are closed and covered expansion not reaching the registry or the list door;view.hiddenandview.ownerare declared on the strictViewItemauthoring door and stored verbatim, but nothing in either repo reads or writes them — andcheck:livenesscannot see it, because its view walk stops at the container arm #20085, The object write door still runs no field-existence rule for searchableFields or listViews — the same asymmetry #15254 closed one key over #15495, [finding]getMetaItems' gate docblock calls the/meta/:typelist door "the only door that both gates and reaches this method" and enumerates "the four remaining" call sites —rest-server.tshas SIX, and the diagnostics?type=door is the one missing #15621, [finding]GET /meta/<unknown-type>/<name>says "item not found" — the single-item 404 cannot tell an unknown TYPE from an unknown ITEM #9744 and getMetaItem 的 overlay 读用裸 catch 把「sys_metadata 不可达」吞成「该项不存在」—— GET /meta/:type/:name 在存储故障时回一个无 code 的 400「not found」 #5532 are closed and on other subjects.None names the by-name answer for an expanded name.
Dedupe words:
expanded view by-name 404·getMetaItem container expansion·runtime view container listed not fetchable·env_local by-name expanded nameGenerated by Claude Code