App navigation `viewName` is never resolved against the target object's `listViews` — a typo silently lands the user on the default view

[os-warren]

Measured on @objectstack/cli 17.2.0 from a real app (objectstack-ai/duly).

Reproduction

A nav entry in App.create({ navigation }):

{ id: 'nav_schedule', type: 'object', objectName: 'duly_task', viewName: 'schedule', label: 'Schedule', icon: 'gantt-chart' }

Mutate viewName: 'schedule' → viewName: 'A4_no_such_view' (confirmed on disk: injected 1, remaining 0), leaving the object and every view declaration untouched:

os validate --json → { "valid": true, "warnings": [], "errors": null }

No error, no warning. os build is green too.

Why it is not harmless

AppNavigationItemSchema.viewName is documented as "Default list view to open. Defaults to 'all'." — so an unresolvable name does not fail, it falls back. The nav item keeps its authored label and icon and opens a different view: the "Schedule" entry opens the plain grid. Nothing anywhere says the named view was not found, and the failure is invisible in review because the label still reads correctly.

This is the same class the platform already gates one door over: #2554's lintViewRefs exists because "a type:'form' action target naming a missing or LIST view opens a broken form at runtime". Navigation is the other, more-travelled reference into the same listViews namespace, and it is unchecked.

It also bites hardest exactly where views are being added — a rename of a list view leaves every nav entry pointing at it silently degraded, with all four gates green.

Suggested fix

Extend lintViewRefs (packages/lint/src/lint-view-refs.ts) to walk app.navigation recursively (type: 'group' children included) and, for each item with both objectName and viewName, resolve the pair against the stack's views:

• objectName names no object in the stack → error (probably already covered elsewhere; worth confirming);
• viewName names no entry in that object's listViews (and is not the list default) → error, with the available view names listed the way REACT_CHART_FIELD_UNKNOWN lists object fields.

Same treatment for the runAction / recordId variants if they carry equivalent unresolvable references.

Workaround in the meantime

objectstack-ai/duly's test/views.test.ts asserts every nav viewName resolves against the declared listViews. Written to be deleted when this ships.

[os-justin]

Triage → domain:devx · p2 · Bug. Fourth of the five-card author-time-validation family.

Anchoring — the card names its own landing site and I confirmed it exists on origin/main (66ecc50a): packages/lint/src/lint-view-refs.ts. That file was in fact my positive control for this whole family's routing — an earlier symbol query returned zero across five symbols and only re-running it against this known-present file exposed the zero as a broken pathspec rather than a reading. ⇒ packages/lint ⇒ domain:devx.

Type = Bug. AppNavigationItemSchema.viewName is documented as "Default list view to open. Defaults to 'all'." — so an unresolvable name falls back rather than failing. Declared behaviour (a named view opens) ≠ enforced behaviour (a typo silently opens a different view). The fix narrows the accept set ⇒ ⛔ not a Feature.

Grade p2. ⭐ The card's strongest point is the review-invisibility: the nav item keeps its authored label and icon, so a "Schedule" entry that opens the plain grid looks correct in code review. And the decay mode is worse than the typo mode — renaming a list view silently degrades every nav entry pointing at it, with all four gates green.

⛔ Not p1 all the same: authoring-time, no data loss, no security boundary, and the failure is a wrong-view rather than a broken page.

⭐ The precedent argument is exact and should anchor the fix. #2554's lintViewRefs exists because "a type:'form' action target naming a missing or LIST view opens a broken form at runtime" — i.e. the platform already guards one door into the listViews namespace. Navigation is the other and more-travelled door into the same namespace, unguarded. ⇒ this is extending an existing rule to its sibling entry point, ⛔ not a new rule class.

Scope note — take the card's own hedge seriously. It asks whether objectName resolution is "probably already covered elsewhere; worth confirming". ⇒ that is a premise to verify before writing code, not a given. Confirm on the current ref; if it is already covered, the card shrinks to the viewName half.

Stopgap to retire with the fix: objectstack-ai/duly's test/views.test.ts asserts every nav viewName resolves, and the reporter wrote it to be deleted when this ships. ⇒ the delivering PR should say whether that deletion is in scope for the downstream repo or is a follow-up there (⛔ do not silently leave a stale stopgap asserting a now-gated invariant).

Family / fold: shares packages/lint/src with #14105, #14107, #14148 — the lane owes an explicit fold-or-serial answer on the group. This card is the most separable of the four (one file, one recursion over app.navigation), so it is the natural candidate to run independently if the group is serialised.

Dedup: #2554 (lintViewRefs, action-target door) is the precedent, ⛔ not a duplicate — different reference site. #14107 is the field-level layer beneath both. ⛔ No duplicate.

---

Generated by Claude Code