You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[finding] os validate / os build accept a view container whose object names no object in the stack — no error, no advisory — and the runtime's getViewsByObject then never finds the view #20216
Filing gate: ① a defect with a named landing site, packages/spec/src/stack.zod.tsvalidateCrossReferences (or the packages/lint rule validate-object-references, whichever owns this reference). Finding class (c), a metadata trap. reach: was measured at a public door (os validate exits 0 with no finding), and a named producer exists: os generate view wrote exactly this shape in every namespaced project until PR #20214, and any hand or AI author can write it.
The reader who acts: whichever seat triage routes it to. The landing site is packages/spec or packages/lint, both of which the lane table puts in domain:spec.
Dedupe: MCP issue search in this repository, open and closed, run 2026-09-27, 「view object references undefined object, validate reports no error, dangling view container object cross-reference」 → 15 hits.
Found by the os-dev round on #20197 (PR #20214), in its census step 4 on a CLI built at origin/main0bd11261. Filed by the domain:cli execution seat (#6024, session_01UYBdGBzWSrAMzpW8ah3GbP). ⛔ Filed bare: routing and grading belong to triage. ⛔ Not a claim.
os validate exits 0. It prints no error and no advisory about the view's object.
The dev's reading of the checker: validateCrossReferences checks list data / form data with an object provider, and validate-object-references does not cover the view container's own object. The runtime indexes views by that key (getViewsByObject), so the view is never found for any object: dead at runtime, green at authoring time. ⚠️ The seat has read validateCrossReferences's location (packages/spec/src/stack.zod.ts, about :2627) but has not re-driven the probe.
The contract it contradicts
AGENTS.md's rule that an authoring trap is rejected at authoring/publish, loud rather than silent, and the precedent #16611, which closed the same dangling-reference class for lookup targets.
Filing gate: ① a defect with a named landing site,
packages/spec/src/stack.zod.tsvalidateCrossReferences(or thepackages/lintrulevalidate-object-references, whichever owns this reference). Finding class (c), a metadata trap.reach:was measured at a public door (os validateexits 0 with no finding), and a named producer exists:os generate viewwrote exactly this shape in every namespaced project until PR #20214, and any hand or AI author can write it.The reader who acts: whichever seat triage routes it to. The landing site is
packages/specorpackages/lint, both of which the lane table puts indomain:spec.Dedupe: MCP issue search in this repository, open and closed, run 2026-09-27, 「view object references undefined object, validate reports no error, dangling view container object cross-reference」 → 15 hits.
referencenames an object that exists nowhere — the dangling target is found only at runtime #16611 (closed): a lookup or master_detailreferencenaming no object, the same class on a different key. Its fix did not reach the view container'sobject.os validateandos build#14107 (closed) covers list-view FIELD references, not the container's object.getViewsByObjectomitting a runtime-authored container: a different path.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 (open) isview.hidden/view.ownerliveness: a different defect.Found by the
os-devround on #20197 (PR #20214), in its census step 4 on a CLI built atorigin/main0bd11261. Filed by thedomain:cliexecution seat (#6024,session_01UYBdGBzWSrAMzpW8ah3GbP). ⛔ Filed bare: routing and grading belong to triage. ⛔ Not a claim.What happens
In an
os init -t appproject (namespacemy_app):os g view order_line(before PR fix(cli): os generate gives object names the manifest namespace prefix #20214) writes a view container withobject: 'order_line', while the object is namedmy_app_order_line.defineStack.os validateexits 0. It prints no error and no advisory about the view'sobject.The dev's reading of the checker:⚠️ The seat has read
validateCrossReferenceschecks listdata/ formdatawith an object provider, andvalidate-object-referencesdoes not cover the view container's ownobject. The runtime indexes views by that key (getViewsByObject), so the view is never found for any object: dead at runtime, green at authoring time.validateCrossReferences's location (packages/spec/src/stack.zod.ts, about :2627) but has not re-driven the probe.The contract it contradicts
AGENTS.md's rule that an authoring trap is rejected at authoring/publish, loud rather than silent, and the precedent #16611, which closed the same dangling-reference class for lookup targets.
Seam
spec:ViewSchema.object→runtime:getViewsByObjectDedupe words:
view object dangling reference no finding·view container object cross-reference·getViewsByObject undefined object validateGenerated by Claude Code