Guard every metadata binding: views, datasets and app nav resolve against dulyObjects

[os-warren]

Fixes#51

Adds test/metadata-bindings.test.ts — one guard walking dulyViews, dulyDatasets and dulyApps and resolving every reference against dulyObjects. Labelled a stopgap pending objectstack#14105 / #14107 / #14108, written to be deleted rather than maintained, per the test/flow-predicates.test.ts convention.

Scope taken is the widened scope from the PM comment on the card (views + nav + datasets), not the datasets-only scope in the body.

Two things the reviewer should read first

1. No dangling reference exists in shipped metadata. The guard resolves 204 references — 145 view, 34 dataset, 25 nav — and all 204 resolve. So no metadata file is touched by this PR; the only change is the test. That is a real result, not a skipped check: the per-surface counters and the joined-path assertion below are what stop "green" from meaning "the walk did nothing".

2. The card's premise that "nothing has ever checked the five view files or the app nav" is wrong.test/views.test.ts (landed in #49) already resolves the simple view surface and the nav objectName / viewName pair. The card is still real — but the value is in the superset, not in first coverage. The remaining holes it closes:

Hole	Where it was
Datasets not covered at all	datasets.test.ts pins caliber / date-macros / absences, never that a field path names anything real
Dotted paths resolved by nothing	views.test.ts opens its checker with if (!name || name.includes('.')) return — so duty.frequency, the one joined path this app ships, was unchecked everywhere
Hand-copied system-column list	views.test.ts carries business_unit_id (not a platform column) and omits owning_business_unit_id, tenant_id, user_id, deleted_at (which are). This file imports the spec's own SystemFieldName
A view bound to a platform object would false-positive	its bound object had to be in dulyObjects; platform names now resolve from isPlatformProvidedObjectName
No self-test on either file	24 synthetic-fixture cases here pin both directions

The overlap is declared in the file header rather than resolved by deleting another card's guard — that is a follow-up, filed as #58. Until then it is benign: this file is the strict superset, so any disagreement reds here first.

What is checked

• Views — columns[] (both the bare-string and { field } spellings), columns[].summary.field, columns[].prefix.field, filter[].field, sort[].field (plus the legacy "field desc" string), grouping.fields[].field, rowColor.field, the searchableFields / filterableFields / hiddenFields / fieldOrder lists, and every binding block — kanban, calendar, gantt, timeline, gallery, tree, map.
• Datasets — base object, every include path, every dimension and measure field, and every filter key (the column is the key; the walk recurses $and / $or / $not and never mistakes an operator for a column). Also that a joined path's relationship is actually in include — every segment can name something real and still have no join to travel (ADR-0071).
• Joined paths — through a reference-carrying field to a real field on the target. Hopping through a scalar is reported as its own, more legible failure.
• Nav — every objectName, every viewName against the views declared on that object (a view of the right name on the wrong object is a finding), filters keys, and the no-viewName case when the object has no default list.

Beyond the card's enumerated list, and flagged because it is an addition: bulkActionDefs with operation: 'update' write fields — the static patch keys and the collected params[].name, which BulkActionDefSchema documents as merged over the patch. Same defect class, one layer down. Only update; on a custom def those are action params, not fields.

Narrowings, stated rather than hidden

• A hop into a platform object is a boundary, not a resolution.@objectstack/spec exports the platform object name registry but no field lists, so owner.some_typo cannot be judged. The hop is verified, the path is recorded, and a test fails the day one is authored — the hole is loud rather than silent.
• Field-bearing slots are hand-listed (the spec exports no slot table for view field references, unlike FLOW_NODE_EXPRESSION_PATHS for flow predicates), and the list polices itself: a tripwire scans the metadata for field-ish slots and fails on any the walk cannot read.
• Form views are not walked. This app declares none; a tripwire fails the day one appears.
• Tripwires likewise cover unknown nav item types and lookups targeting a name that is neither declared nor platform-provided.

Proving it can fail — four ablations, one per surface

Each leg: anchor asserted to occur exactly once before the edit, both the injected and the removed literal grepped afterwards, a non-empty git diff --stat required, and a trap … EXIT INT TERM restoring from HEAD (the guard was committed first, so this is a real restore point and not the index).

#	Mutation	pnpm validate	guard
1	view column category → categoree_typo	exit 0 — ✓ Validation passed (338ms)	exit 1
2	dataset filter keylast_update_at → last_update_attt	exit 0 — ✓ Validation passed (334ms)	exit 1
3	nav viewName: 'stalled' → 'not_moving'	exit 0 — ✓ Validation passed (430ms)	exit 1
4	joined path duty.frequency → duty.frequencee	exit 0 — ✓ Validation passed (432ms)	exit 1

Leg 3 is the one worth reading — the guard prints exactly what makes #14108 nasty:

app duly_app · nav 'nav_stalled' · viewName: "not_moving" — duly_task declares no list view named "not_moving" — the shell SILENTLY falls back to the default view and keeps this entry's authored label.

The label stays "Not moving". The screen looks right and shows the wrong rows.

Observed direction, not the template one: leg 4 reddened two tests, not one — the finding, plus the non-vacuity assertion that the joined path was reached at all. Diagnostics went up, which is the correct reading here: mutating the app's only multi-hop path both produces a finding and removes the evidence that the multi-hop walk runs.

All four restored; tree verified byte-identical to HEAD afterwards (git status --porcelain empty, git diff HEAD empty, all four anchors back at count 1).

Gates

main moved while this was in flight (#54 source defaults, #56 hierarchy-security — both touch objects this guard resolves against). It is merged in at 27d31a0; no field was renamed or removed, only default: flags on select options.

Gates re-run on the final commit 27d31a0, after the merge:

pnpm validate exit 0 ✓ Validation passed (400ms)
pnpm typecheck exit 0 tsc --noEmit
pnpm test exit 0 Test Files 13 passed (13) · Tests 407 passed (407)
pnpm build exit 0 Artifact: dist/objectstack.json (96.2 KB)

Exit codes captured before any pipe. 407 tests = 375 on merged main + 32 added. (The pre-merge reading at cf62af9 was 402 = 370 + 32; #54 and #56 added five.)

No changeset: this repo carries no changeset tooling, and the change is test-only.

---

Generated by Claude Code

[os-warren]

Fixes#51

Adds test/metadata-bindings.test.ts — one guard walking dulyViews, dulyDatasets and dulyApps and resolving every reference against dulyObjects. Labelled a stopgap pending objectstack#14105 / #14107 / #14108, written to be deleted rather than maintained, per the test/flow-predicates.test.ts convention.

Scope taken is the widened scope from the PM comment on the card (views + nav + datasets), not the datasets-only scope in the body.

Two things the reviewer should read first

1. No dangling reference exists in shipped metadata. The guard resolves 204 references — 145 view, 34 dataset, 25 nav — and all 204 resolve. So no metadata file is touched by this PR; the only change is the test. That is a real result, not a skipped check: the per-surface counters and the joined-path assertion below are what stop "green" from meaning "the walk did nothing".

2. The card's premise that "nothing has ever checked the five view files or the app nav" is wrong.test/views.test.ts (landed in #49) already resolves the simple view surface and the nav objectName / viewName pair. The card is still real — but the value is in the superset, not in first coverage. The remaining holes it closes:

Hole	Where it was
Datasets not covered at all	datasets.test.ts pins caliber / date-macros / absences, never that a field path names anything real
Dotted paths resolved by nothing	views.test.ts opens its checker with if (!name || name.includes('.')) return — so duty.frequency, the one joined path this app ships, was unchecked everywhere
Hand-copied system-column list	views.test.ts carries business_unit_id (not a platform column) and omits owning_business_unit_id, tenant_id, user_id, deleted_at (which are). This file imports the spec's own SystemFieldName
A view bound to a platform object would false-positive	its bound object had to be in dulyObjects; platform names now resolve from isPlatformProvidedObjectName
No self-test on either file	24 synthetic-fixture cases here pin both directions

The overlap is declared in the file header rather than resolved by deleting another card's guard — that is a follow-up, filed as #58. Until then it is benign: this file is the strict superset, so any disagreement reds here first.

What is checked

• Views — columns[] (both the bare-string and { field } spellings), columns[].summary.field, columns[].prefix.field, filter[].field, sort[].field (plus the legacy "field desc" string), grouping.fields[].field, rowColor.field, the searchableFields / filterableFields / hiddenFields / fieldOrder lists, and every binding block — kanban, calendar, gantt, timeline, gallery, tree, map.
• Datasets — base object, every include path, every dimension and measure field, and every filter key (the column is the key; the walk recurses $and / $or / $not and never mistakes an operator for a column). Also that a joined path's relationship is actually in include — every segment can name something real and still have no join to travel (ADR-0071).
• Joined paths — through a reference-carrying field to a real field on the target. Hopping through a scalar is reported as its own, more legible failure.
• Nav — every objectName, every viewName against the views declared on that object (a view of the right name on the wrong object is a finding), filters keys, and the no-viewName case when the object has no default list.

Beyond the card's enumerated list, and flagged because it is an addition: bulkActionDefs with operation: 'update' write fields — the static patch keys and the collected params[].name, which BulkActionDefSchema documents as merged over the patch. Same defect class, one layer down. Only update; on a custom def those are action params, not fields.

Narrowings, stated rather than hidden

• A hop into a platform object is a boundary, not a resolution.@objectstack/spec exports the platform object name registry but no field lists, so owner.some_typo cannot be judged. The hop is verified, the path is recorded, and a test fails the day one is authored — the hole is loud rather than silent.
• Field-bearing slots are hand-listed (the spec exports no slot table for view field references, unlike FLOW_NODE_EXPRESSION_PATHS for flow predicates), and the list polices itself: a tripwire scans the metadata for field-ish slots and fails on any the walk cannot read.
• Form views are not walked. This app declares none; a tripwire fails the day one appears.
• Tripwires likewise cover unknown nav item types and lookups targeting a name that is neither declared nor platform-provided.

Proving it can fail — four ablations, one per surface

Each leg: anchor asserted to occur exactly once before the edit, both the injected and the removed literal grepped afterwards, a non-empty git diff --stat required, and a trap … EXIT INT TERM restoring from HEAD (the guard was committed first, so this is a real restore point and not the index).

#	Mutation	pnpm validate	guard
1	view column category → categoree_typo	exit 0 — ✓ Validation passed (338ms)	exit 1
2	dataset filter keylast_update_at → last_update_attt	exit 0 — ✓ Validation passed (334ms)	exit 1
3	nav viewName: 'stalled' → 'not_moving'	exit 0 — ✓ Validation passed (430ms)	exit 1
4	joined path duty.frequency → duty.frequencee	exit 0 — ✓ Validation passed (432ms)	exit 1

Leg 3 is the one worth reading — the guard prints exactly what makes #14108 nasty:

app duly_app · nav 'nav_stalled' · viewName: "not_moving" — duly_task declares no list view named "not_moving" — the shell SILENTLY falls back to the default view and keeps this entry's authored label.

The label stays "Not moving". The screen looks right and shows the wrong rows.

Observed direction, not the template one: leg 4 reddened two tests, not one — the finding, plus the non-vacuity assertion that the joined path was reached at all. Diagnostics went up, which is the correct reading here: mutating the app's only multi-hop path both produces a finding and removes the evidence that the multi-hop walk runs.

All four restored; tree verified byte-identical to HEAD afterwards (git status --porcelain empty, git diff HEAD empty, all four anchors back at count 1).

Gates

main moved while this was in flight (#54 source defaults, #56 hierarchy-security — both touch objects this guard resolves against). It is merged in at 27d31a0; no field was renamed or removed, only default: flags on select options.

Gates re-run on the final commit 27d31a0, after the merge:

pnpm validate exit 0 ✓ Validation passed (400ms)
pnpm typecheck exit 0 tsc --noEmit
pnpm test exit 0 Test Files 13 passed (13) · Tests 407 passed (407)
pnpm build exit 0 Artifact: dist/objectstack.json (96.2 KB)

Exit codes captured before any pipe. 407 tests = 375 on merged main + 32 added. (The pre-merge reading at cf62af9 was 402 = 370 + 32; #54 and #56 added five.)

No changeset: this repo carries no changeset tooling, and the change is test-only.

---

Generated by Claude Code

[os-warren]

Fixes#51

Adds test/metadata-bindings.test.ts — one guard walking dulyViews, dulyDatasets and dulyApps and resolving every reference against dulyObjects. Labelled a stopgap pending objectstack#14105 / #14107 / #14108, written to be deleted rather than maintained, per the test/flow-predicates.test.ts convention.

Scope taken is the widened scope from the PM comment on the card (views + nav + datasets), not the datasets-only scope in the body.

Two things the reviewer should read first

1. No dangling reference exists in shipped metadata. The guard resolves 204 references — 145 view, 34 dataset, 25 nav — and all 204 resolve. So no metadata file is touched by this PR; the only change is the test. That is a real result, not a skipped check: the per-surface counters and the joined-path assertion below are what stop "green" from meaning "the walk did nothing".

2. The card's premise that "nothing has ever checked the five view files or the app nav" is wrong.test/views.test.ts (landed in #49) already resolves the simple view surface and the nav objectName / viewName pair. The card is still real — but the value is in the superset, not in first coverage. The remaining holes it closes:

Hole	Where it was
Datasets not covered at all	datasets.test.ts pins caliber / date-macros / absences, never that a field path names anything real
Dotted paths resolved by nothing	views.test.ts opens its checker with if (!name || name.includes('.')) return — so duty.frequency, the one joined path this app ships, was unchecked everywhere
Hand-copied system-column list	views.test.ts carries business_unit_id (not a platform column) and omits owning_business_unit_id, tenant_id, user_id, deleted_at (which are). This file imports the spec's own SystemFieldName
A view bound to a platform object would false-positive	its bound object had to be in dulyObjects; platform names now resolve from isPlatformProvidedObjectName
No self-test on either file	24 synthetic-fixture cases here pin both directions

The overlap is declared in the file header rather than resolved by deleting another card's guard — that is a follow-up, filed as #58. Until then it is benign: this file is the strict superset, so any disagreement reds here first.

What is checked

• Views — columns[] (both the bare-string and { field } spellings), columns[].summary.field, columns[].prefix.field, filter[].field, sort[].field (plus the legacy "field desc" string), grouping.fields[].field, rowColor.field, the searchableFields / filterableFields / hiddenFields / fieldOrder lists, and every binding block — kanban, calendar, gantt, timeline, gallery, tree, map.
• Datasets — base object, every include path, every dimension and measure field, and every filter key (the column is the key; the walk recurses $and / $or / $not and never mistakes an operator for a column). Also that a joined path's relationship is actually in include — every segment can name something real and still have no join to travel (ADR-0071).
• Joined paths — through a reference-carrying field to a real field on the target. Hopping through a scalar is reported as its own, more legible failure.
• Nav — every objectName, every viewName against the views declared on that object (a view of the right name on the wrong object is a finding), filters keys, and the no-viewName case when the object has no default list.

Beyond the card's enumerated list, and flagged because it is an addition: bulkActionDefs with operation: 'update' write fields — the static patch keys and the collected params[].name, which BulkActionDefSchema documents as merged over the patch. Same defect class, one layer down. Only update; on a custom def those are action params, not fields.

Narrowings, stated rather than hidden

• A hop into a platform object is a boundary, not a resolution.@objectstack/spec exports the platform object name registry but no field lists, so owner.some_typo cannot be judged. The hop is verified, the path is recorded, and a test fails the day one is authored — the hole is loud rather than silent.
• Field-bearing slots are hand-listed (the spec exports no slot table for view field references, unlike FLOW_NODE_EXPRESSION_PATHS for flow predicates), and the list polices itself: a tripwire scans the metadata for field-ish slots and fails on any the walk cannot read.
• Form views are not walked. This app declares none; a tripwire fails the day one appears.
• Tripwires likewise cover unknown nav item types and lookups targeting a name that is neither declared nor platform-provided.

Proving it can fail — four ablations, one per surface

Each leg: anchor asserted to occur exactly once before the edit, both the injected and the removed literal grepped afterwards, a non-empty git diff --stat required, and a trap … EXIT INT TERM restoring from HEAD (the guard was committed first, so this is a real restore point and not the index).

#	Mutation	pnpm validate	guard
1	view column category → categoree_typo	exit 0 — ✓ Validation passed (338ms)	exit 1
2	dataset filter keylast_update_at → last_update_attt	exit 0 — ✓ Validation passed (334ms)	exit 1
3	nav viewName: 'stalled' → 'not_moving'	exit 0 — ✓ Validation passed (430ms)	exit 1
4	joined path duty.frequency → duty.frequencee	exit 0 — ✓ Validation passed (432ms)	exit 1

Leg 3 is the one worth reading — the guard prints exactly what makes #14108 nasty:

app duly_app · nav 'nav_stalled' · viewName: "not_moving" — duly_task declares no list view named "not_moving" — the shell SILENTLY falls back to the default view and keeps this entry's authored label.

The label stays "Not moving". The screen looks right and shows the wrong rows.

Observed direction, not the template one: leg 4 reddened two tests, not one — the finding, plus the non-vacuity assertion that the joined path was reached at all. Diagnostics went up, which is the correct reading here: mutating the app's only multi-hop path both produces a finding and removes the evidence that the multi-hop walk runs.

All four restored; tree verified byte-identical to HEAD afterwards (git status --porcelain empty, git diff HEAD empty, all four anchors back at count 1).

Gates

main moved while this was in flight (#54 source defaults, #56 hierarchy-security — both touch objects this guard resolves against). It is merged in at 27d31a0; no field was renamed or removed, only default: flags on select options.

Gates re-run on the final commit 27d31a0, after the merge:

pnpm validate exit 0 ✓ Validation passed (400ms)
pnpm typecheck exit 0 tsc --noEmit
pnpm test exit 0 Test Files 13 passed (13) · Tests 407 passed (407)
pnpm build exit 0 Artifact: dist/objectstack.json (96.2 KB)

Exit codes captured before any pipe. 407 tests = 375 on merged main + 32 added. (The pre-merge reading at cf62af9 was 402 = 370 + 32; #54 and #56 added five.)

No changeset: this repo carries no changeset tooling, and the change is test-only.

---

Generated by Claude Code

[os-warren]

Fixes#51

Adds test/metadata-bindings.test.ts — one guard walking dulyViews, dulyDatasets and dulyApps and resolving every reference against dulyObjects. Labelled a stopgap pending objectstack#14105 / #14107 / #14108, written to be deleted rather than maintained, per the test/flow-predicates.test.ts convention.

Scope taken is the widened scope from the PM comment on the card (views + nav + datasets), not the datasets-only scope in the body.

Two things the reviewer should read first

1. No dangling reference exists in shipped metadata. The guard resolves 204 references — 145 view, 34 dataset, 25 nav — and all 204 resolve. So no metadata file is touched by this PR; the only change is the test. That is a real result, not a skipped check: the per-surface counters and the joined-path assertion below are what stop "green" from meaning "the walk did nothing".

2. The card's premise that "nothing has ever checked the five view files or the app nav" is wrong.test/views.test.ts (landed in #49) already resolves the simple view surface and the nav objectName / viewName pair. The card is still real — but the value is in the superset, not in first coverage. The remaining holes it closes:

Hole	Where it was
Datasets not covered at all	datasets.test.ts pins caliber / date-macros / absences, never that a field path names anything real
Dotted paths resolved by nothing	views.test.ts opens its checker with if (!name || name.includes('.')) return — so duty.frequency, the one joined path this app ships, was unchecked everywhere
Hand-copied system-column list	views.test.ts carries business_unit_id (not a platform column) and omits owning_business_unit_id, tenant_id, user_id, deleted_at (which are). This file imports the spec's own SystemFieldName
A view bound to a platform object would false-positive	its bound object had to be in dulyObjects; platform names now resolve from isPlatformProvidedObjectName
No self-test on either file	24 synthetic-fixture cases here pin both directions

The overlap is declared in the file header rather than resolved by deleting another card's guard — that is a follow-up, filed as #58. Until then it is benign: this file is the strict superset, so any disagreement reds here first.

What is checked

• Views — columns[] (both the bare-string and { field } spellings), columns[].summary.field, columns[].prefix.field, filter[].field, sort[].field (plus the legacy "field desc" string), grouping.fields[].field, rowColor.field, the searchableFields / filterableFields / hiddenFields / fieldOrder lists, and every binding block — kanban, calendar, gantt, timeline, gallery, tree, map.
• Datasets — base object, every include path, every dimension and measure field, and every filter key (the column is the key; the walk recurses $and / $or / $not and never mistakes an operator for a column). Also that a joined path's relationship is actually in include — every segment can name something real and still have no join to travel (ADR-0071).
• Joined paths — through a reference-carrying field to a real field on the target. Hopping through a scalar is reported as its own, more legible failure.
• Nav — every objectName, every viewName against the views declared on that object (a view of the right name on the wrong object is a finding), filters keys, and the no-viewName case when the object has no default list.

Beyond the card's enumerated list, and flagged because it is an addition: bulkActionDefs with operation: 'update' write fields — the static patch keys and the collected params[].name, which BulkActionDefSchema documents as merged over the patch. Same defect class, one layer down. Only update; on a custom def those are action params, not fields.

Narrowings, stated rather than hidden

• A hop into a platform object is a boundary, not a resolution.@objectstack/spec exports the platform object name registry but no field lists, so owner.some_typo cannot be judged. The hop is verified, the path is recorded, and a test fails the day one is authored — the hole is loud rather than silent.
• Field-bearing slots are hand-listed (the spec exports no slot table for view field references, unlike FLOW_NODE_EXPRESSION_PATHS for flow predicates), and the list polices itself: a tripwire scans the metadata for field-ish slots and fails on any the walk cannot read.
• Form views are not walked. This app declares none; a tripwire fails the day one appears.
• Tripwires likewise cover unknown nav item types and lookups targeting a name that is neither declared nor platform-provided.

Proving it can fail — four ablations, one per surface

Each leg: anchor asserted to occur exactly once before the edit, both the injected and the removed literal grepped afterwards, a non-empty git diff --stat required, and a trap … EXIT INT TERM restoring from HEAD (the guard was committed first, so this is a real restore point and not the index).

#	Mutation	pnpm validate	guard
1	view column category → categoree_typo	exit 0 — ✓ Validation passed (338ms)	exit 1
2	dataset filter keylast_update_at → last_update_attt	exit 0 — ✓ Validation passed (334ms)	exit 1
3	nav viewName: 'stalled' → 'not_moving'	exit 0 — ✓ Validation passed (430ms)	exit 1
4	joined path duty.frequency → duty.frequencee	exit 0 — ✓ Validation passed (432ms)	exit 1

Leg 3 is the one worth reading — the guard prints exactly what makes #14108 nasty:

app duly_app · nav 'nav_stalled' · viewName: "not_moving" — duly_task declares no list view named "not_moving" — the shell SILENTLY falls back to the default view and keeps this entry's authored label.

The label stays "Not moving". The screen looks right and shows the wrong rows.

Observed direction, not the template one: leg 4 reddened two tests, not one — the finding, plus the non-vacuity assertion that the joined path was reached at all. Diagnostics went up, which is the correct reading here: mutating the app's only multi-hop path both produces a finding and removes the evidence that the multi-hop walk runs.

All four restored; tree verified byte-identical to HEAD afterwards (git status --porcelain empty, git diff HEAD empty, all four anchors back at count 1).

Gates

main moved while this was in flight (#54 source defaults, #56 hierarchy-security — both touch objects this guard resolves against). It is merged in at 27d31a0; no field was renamed or removed, only default: flags on select options.

Gates re-run on the final commit 27d31a0, after the merge:

pnpm validate exit 0 ✓ Validation passed (400ms)
pnpm typecheck exit 0 tsc --noEmit
pnpm test exit 0 Test Files 13 passed (13) · Tests 407 passed (407)
pnpm build exit 0 Artifact: dist/objectstack.json (96.2 KB)

Exit codes captured before any pipe. 407 tests = 375 on merged main + 32 added. (The pre-merge reading at cf62af9 was 402 = 370 + 32; #54 and #56 added five.)

No changeset: this repo carries no changeset tooling, and the change is test-only.

---

Generated by Claude Code

[os-warren]

Fixes#51

Adds test/metadata-bindings.test.ts — one guard walking dulyViews, dulyDatasets and dulyApps and resolving every reference against dulyObjects. Labelled a stopgap pending objectstack#14105 / #14107 / #14108, written to be deleted rather than maintained, per the test/flow-predicates.test.ts convention.

Scope taken is the widened scope from the PM comment on the card (views + nav + datasets), not the datasets-only scope in the body.

Two things the reviewer should read first

1. No dangling reference exists in shipped metadata. The guard resolves 204 references — 145 view, 34 dataset, 25 nav — and all 204 resolve. So no metadata file is touched by this PR; the only change is the test. That is a real result, not a skipped check: the per-surface counters and the joined-path assertion below are what stop "green" from meaning "the walk did nothing".

2. The card's premise that "nothing has ever checked the five view files or the app nav" is wrong.test/views.test.ts (landed in #49) already resolves the simple view surface and the nav objectName / viewName pair. The card is still real — but the value is in the superset, not in first coverage. The remaining holes it closes:

Hole	Where it was
Datasets not covered at all	datasets.test.ts pins caliber / date-macros / absences, never that a field path names anything real
Dotted paths resolved by nothing	views.test.ts opens its checker with if (!name || name.includes('.')) return — so duty.frequency, the one joined path this app ships, was unchecked everywhere
Hand-copied system-column list	views.test.ts carries business_unit_id (not a platform column) and omits owning_business_unit_id, tenant_id, user_id, deleted_at (which are). This file imports the spec's own SystemFieldName
A view bound to a platform object would false-positive	its bound object had to be in dulyObjects; platform names now resolve from isPlatformProvidedObjectName
No self-test on either file	24 synthetic-fixture cases here pin both directions

The overlap is declared in the file header rather than resolved by deleting another card's guard — that is a follow-up, filed as #58. Until then it is benign: this file is the strict superset, so any disagreement reds here first.

What is checked

• Views — columns[] (both the bare-string and { field } spellings), columns[].summary.field, columns[].prefix.field, filter[].field, sort[].field (plus the legacy "field desc" string), grouping.fields[].field, rowColor.field, the searchableFields / filterableFields / hiddenFields / fieldOrder lists, and every binding block — kanban, calendar, gantt, timeline, gallery, tree, map.
• Datasets — base object, every include path, every dimension and measure field, and every filter key (the column is the key; the walk recurses $and / $or / $not and never mistakes an operator for a column). Also that a joined path's relationship is actually in include — every segment can name something real and still have no join to travel (ADR-0071).
• Joined paths — through a reference-carrying field to a real field on the target. Hopping through a scalar is reported as its own, more legible failure.
• Nav — every objectName, every viewName against the views declared on that object (a view of the right name on the wrong object is a finding), filters keys, and the no-viewName case when the object has no default list.

Beyond the card's enumerated list, and flagged because it is an addition: bulkActionDefs with operation: 'update' write fields — the static patch keys and the collected params[].name, which BulkActionDefSchema documents as merged over the patch. Same defect class, one layer down. Only update; on a custom def those are action params, not fields.

Narrowings, stated rather than hidden

• A hop into a platform object is a boundary, not a resolution.@objectstack/spec exports the platform object name registry but no field lists, so owner.some_typo cannot be judged. The hop is verified, the path is recorded, and a test fails the day one is authored — the hole is loud rather than silent.
• Field-bearing slots are hand-listed (the spec exports no slot table for view field references, unlike FLOW_NODE_EXPRESSION_PATHS for flow predicates), and the list polices itself: a tripwire scans the metadata for field-ish slots and fails on any the walk cannot read.
• Form views are not walked. This app declares none; a tripwire fails the day one appears.
• Tripwires likewise cover unknown nav item types and lookups targeting a name that is neither declared nor platform-provided.

Proving it can fail — four ablations, one per surface

Each leg: anchor asserted to occur exactly once before the edit, both the injected and the removed literal grepped afterwards, a non-empty git diff --stat required, and a trap … EXIT INT TERM restoring from HEAD (the guard was committed first, so this is a real restore point and not the index).

#	Mutation	pnpm validate	guard
1	view column category → categoree_typo	exit 0 — ✓ Validation passed (338ms)	exit 1
2	dataset filter keylast_update_at → last_update_attt	exit 0 — ✓ Validation passed (334ms)	exit 1
3	nav viewName: 'stalled' → 'not_moving'	exit 0 — ✓ Validation passed (430ms)	exit 1
4	joined path duty.frequency → duty.frequencee	exit 0 — ✓ Validation passed (432ms)	exit 1

Leg 3 is the one worth reading — the guard prints exactly what makes #14108 nasty:

app duly_app · nav 'nav_stalled' · viewName: "not_moving" — duly_task declares no list view named "not_moving" — the shell SILENTLY falls back to the default view and keeps this entry's authored label.

The label stays "Not moving". The screen looks right and shows the wrong rows.

Observed direction, not the template one: leg 4 reddened two tests, not one — the finding, plus the non-vacuity assertion that the joined path was reached at all. Diagnostics went up, which is the correct reading here: mutating the app's only multi-hop path both produces a finding and removes the evidence that the multi-hop walk runs.

All four restored; tree verified byte-identical to HEAD afterwards (git status --porcelain empty, git diff HEAD empty, all four anchors back at count 1).

Gates

main moved while this was in flight (#54 source defaults, #56 hierarchy-security — both touch objects this guard resolves against). It is merged in at 27d31a0; no field was renamed or removed, only default: flags on select options.

Gates re-run on the final commit 27d31a0, after the merge:

pnpm validate exit 0 ✓ Validation passed (400ms)
pnpm typecheck exit 0 tsc --noEmit
pnpm test exit 0 Test Files 13 passed (13) · Tests 407 passed (407)
pnpm build exit 0 Artifact: dist/objectstack.json (96.2 KB)

Exit codes captured before any pipe. 407 tests = 375 on merged main + 32 added. (The pre-merge reading at cf62af9 was 402 = 370 + 32; #54 and #56 added five.)

No changeset: this repo carries no changeset tooling, and the change is test-only.

---

Generated by Claude Code

[os-warren]

Fixes#51

Adds test/metadata-bindings.test.ts — one guard walking dulyViews, dulyDatasets and dulyApps and resolving every reference against dulyObjects. Labelled a stopgap pending objectstack#14105 / #14107 / #14108, written to be deleted rather than maintained, per the test/flow-predicates.test.ts convention.

Scope taken is the widened scope from the PM comment on the card (views + nav + datasets), not the datasets-only scope in the body.

Two things the reviewer should read first

1. No dangling reference exists in shipped metadata. The guard resolves 204 references — 145 view, 34 dataset, 25 nav — and all 204 resolve. So no metadata file is touched by this PR; the only change is the test. That is a real result, not a skipped check: the per-surface counters and the joined-path assertion below are what stop "green" from meaning "the walk did nothing".

2. The card's premise that "nothing has ever checked the five view files or the app nav" is wrong.test/views.test.ts (landed in #49) already resolves the simple view surface and the nav objectName / viewName pair. The card is still real — but the value is in the superset, not in first coverage. The remaining holes it closes:

Hole	Where it was
Datasets not covered at all	datasets.test.ts pins caliber / date-macros / absences, never that a field path names anything real
Dotted paths resolved by nothing	views.test.ts opens its checker with if (!name || name.includes('.')) return — so duty.frequency, the one joined path this app ships, was unchecked everywhere
Hand-copied system-column list	views.test.ts carries business_unit_id (not a platform column) and omits owning_business_unit_id, tenant_id, user_id, deleted_at (which are). This file imports the spec's own SystemFieldName
A view bound to a platform object would false-positive	its bound object had to be in dulyObjects; platform names now resolve from isPlatformProvidedObjectName
No self-test on either file	24 synthetic-fixture cases here pin both directions

The overlap is declared in the file header rather than resolved by deleting another card's guard — that is a follow-up, filed as #58. Until then it is benign: this file is the strict superset, so any disagreement reds here first.

What is checked

• Views — columns[] (both the bare-string and { field } spellings), columns[].summary.field, columns[].prefix.field, filter[].field, sort[].field (plus the legacy "field desc" string), grouping.fields[].field, rowColor.field, the searchableFields / filterableFields / hiddenFields / fieldOrder lists, and every binding block — kanban, calendar, gantt, timeline, gallery, tree, map.
• Datasets — base object, every include path, every dimension and measure field, and every filter key (the column is the key; the walk recurses $and / $or / $not and never mistakes an operator for a column). Also that a joined path's relationship is actually in include — every segment can name something real and still have no join to travel (ADR-0071).
• Joined paths — through a reference-carrying field to a real field on the target. Hopping through a scalar is reported as its own, more legible failure.
• Nav — every objectName, every viewName against the views declared on that object (a view of the right name on the wrong object is a finding), filters keys, and the no-viewName case when the object has no default list.

Beyond the card's enumerated list, and flagged because it is an addition: bulkActionDefs with operation: 'update' write fields — the static patch keys and the collected params[].name, which BulkActionDefSchema documents as merged over the patch. Same defect class, one layer down. Only update; on a custom def those are action params, not fields.

Narrowings, stated rather than hidden

• A hop into a platform object is a boundary, not a resolution.@objectstack/spec exports the platform object name registry but no field lists, so owner.some_typo cannot be judged. The hop is verified, the path is recorded, and a test fails the day one is authored — the hole is loud rather than silent.
• Field-bearing slots are hand-listed (the spec exports no slot table for view field references, unlike FLOW_NODE_EXPRESSION_PATHS for flow predicates), and the list polices itself: a tripwire scans the metadata for field-ish slots and fails on any the walk cannot read.
• Form views are not walked. This app declares none; a tripwire fails the day one appears.
• Tripwires likewise cover unknown nav item types and lookups targeting a name that is neither declared nor platform-provided.

Proving it can fail — four ablations, one per surface

Each leg: anchor asserted to occur exactly once before the edit, both the injected and the removed literal grepped afterwards, a non-empty git diff --stat required, and a trap … EXIT INT TERM restoring from HEAD (the guard was committed first, so this is a real restore point and not the index).

#	Mutation	pnpm validate	guard
1	view column category → categoree_typo	exit 0 — ✓ Validation passed (338ms)	exit 1
2	dataset filter keylast_update_at → last_update_attt	exit 0 — ✓ Validation passed (334ms)	exit 1
3	nav viewName: 'stalled' → 'not_moving'	exit 0 — ✓ Validation passed (430ms)	exit 1
4	joined path duty.frequency → duty.frequencee	exit 0 — ✓ Validation passed (432ms)	exit 1

Leg 3 is the one worth reading — the guard prints exactly what makes #14108 nasty:

app duly_app · nav 'nav_stalled' · viewName: "not_moving" — duly_task declares no list view named "not_moving" — the shell SILENTLY falls back to the default view and keeps this entry's authored label.

The label stays "Not moving". The screen looks right and shows the wrong rows.

Observed direction, not the template one: leg 4 reddened two tests, not one — the finding, plus the non-vacuity assertion that the joined path was reached at all. Diagnostics went up, which is the correct reading here: mutating the app's only multi-hop path both produces a finding and removes the evidence that the multi-hop walk runs.

All four restored; tree verified byte-identical to HEAD afterwards (git status --porcelain empty, git diff HEAD empty, all four anchors back at count 1).

Gates

main moved while this was in flight (#54 source defaults, #56 hierarchy-security — both touch objects this guard resolves against). It is merged in at 27d31a0; no field was renamed or removed, only default: flags on select options.

Gates re-run on the final commit 27d31a0, after the merge:

pnpm validate exit 0 ✓ Validation passed (400ms)
pnpm typecheck exit 0 tsc --noEmit
pnpm test exit 0 Test Files 13 passed (13) · Tests 407 passed (407)
pnpm build exit 0 Artifact: dist/objectstack.json (96.2 KB)

Exit codes captured before any pipe. 407 tests = 375 on merged main + 32 added. (The pre-merge reading at cf62af9 was 402 = 370 + 32; #54 and #56 added five.)

No changeset: this repo carries no changeset tooling, and the change is test-only.

---

Generated by Claude Code

[os-warren]

Fixes#51

Adds test/metadata-bindings.test.ts — one guard walking dulyViews, dulyDatasets and dulyApps and resolving every reference against dulyObjects. Labelled a stopgap pending objectstack#14105 / #14107 / #14108, written to be deleted rather than maintained, per the test/flow-predicates.test.ts convention.

Scope taken is the widened scope from the PM comment on the card (views + nav + datasets), not the datasets-only scope in the body.

Two things the reviewer should read first

1. No dangling reference exists in shipped metadata. The guard resolves 204 references — 145 view, 34 dataset, 25 nav — and all 204 resolve. So no metadata file is touched by this PR; the only change is the test. That is a real result, not a skipped check: the per-surface counters and the joined-path assertion below are what stop "green" from meaning "the walk did nothing".

2. The card's premise that "nothing has ever checked the five view files or the app nav" is wrong.test/views.test.ts (landed in #49) already resolves the simple view surface and the nav objectName / viewName pair. The card is still real — but the value is in the superset, not in first coverage. The remaining holes it closes:

Hole	Where it was
Datasets not covered at all	datasets.test.ts pins caliber / date-macros / absences, never that a field path names anything real
Dotted paths resolved by nothing	views.test.ts opens its checker with if (!name || name.includes('.')) return — so duty.frequency, the one joined path this app ships, was unchecked everywhere
Hand-copied system-column list	views.test.ts carries business_unit_id (not a platform column) and omits owning_business_unit_id, tenant_id, user_id, deleted_at (which are). This file imports the spec's own SystemFieldName
A view bound to a platform object would false-positive	its bound object had to be in dulyObjects; platform names now resolve from isPlatformProvidedObjectName
No self-test on either file	24 synthetic-fixture cases here pin both directions

The overlap is declared in the file header rather than resolved by deleting another card's guard — that is a follow-up, filed as #58. Until then it is benign: this file is the strict superset, so any disagreement reds here first.

What is checked

• Views — columns[] (both the bare-string and { field } spellings), columns[].summary.field, columns[].prefix.field, filter[].field, sort[].field (plus the legacy "field desc" string), grouping.fields[].field, rowColor.field, the searchableFields / filterableFields / hiddenFields / fieldOrder lists, and every binding block — kanban, calendar, gantt, timeline, gallery, tree, map.
• Datasets — base object, every include path, every dimension and measure field, and every filter key (the column is the key; the walk recurses $and / $or / $not and never mistakes an operator for a column). Also that a joined path's relationship is actually in include — every segment can name something real and still have no join to travel (ADR-0071).
• Joined paths — through a reference-carrying field to a real field on the target. Hopping through a scalar is reported as its own, more legible failure.
• Nav — every objectName, every viewName against the views declared on that object (a view of the right name on the wrong object is a finding), filters keys, and the no-viewName case when the object has no default list.

Beyond the card's enumerated list, and flagged because it is an addition: bulkActionDefs with operation: 'update' write fields — the static patch keys and the collected params[].name, which BulkActionDefSchema documents as merged over the patch. Same defect class, one layer down. Only update; on a custom def those are action params, not fields.

Narrowings, stated rather than hidden

• A hop into a platform object is a boundary, not a resolution.@objectstack/spec exports the platform object name registry but no field lists, so owner.some_typo cannot be judged. The hop is verified, the path is recorded, and a test fails the day one is authored — the hole is loud rather than silent.
• Field-bearing slots are hand-listed (the spec exports no slot table for view field references, unlike FLOW_NODE_EXPRESSION_PATHS for flow predicates), and the list polices itself: a tripwire scans the metadata for field-ish slots and fails on any the walk cannot read.
• Form views are not walked. This app declares none; a tripwire fails the day one appears.
• Tripwires likewise cover unknown nav item types and lookups targeting a name that is neither declared nor platform-provided.

Proving it can fail — four ablations, one per surface

Each leg: anchor asserted to occur exactly once before the edit, both the injected and the removed literal grepped afterwards, a non-empty git diff --stat required, and a trap … EXIT INT TERM restoring from HEAD (the guard was committed first, so this is a real restore point and not the index).

#	Mutation	pnpm validate	guard
1	view column category → categoree_typo	exit 0 — ✓ Validation passed (338ms)	exit 1
2	dataset filter keylast_update_at → last_update_attt	exit 0 — ✓ Validation passed (334ms)	exit 1
3	nav viewName: 'stalled' → 'not_moving'	exit 0 — ✓ Validation passed (430ms)	exit 1
4	joined path duty.frequency → duty.frequencee	exit 0 — ✓ Validation passed (432ms)	exit 1

Leg 3 is the one worth reading — the guard prints exactly what makes #14108 nasty:

app duly_app · nav 'nav_stalled' · viewName: "not_moving" — duly_task declares no list view named "not_moving" — the shell SILENTLY falls back to the default view and keeps this entry's authored label.

The label stays "Not moving". The screen looks right and shows the wrong rows.

Observed direction, not the template one: leg 4 reddened two tests, not one — the finding, plus the non-vacuity assertion that the joined path was reached at all. Diagnostics went up, which is the correct reading here: mutating the app's only multi-hop path both produces a finding and removes the evidence that the multi-hop walk runs.

All four restored; tree verified byte-identical to HEAD afterwards (git status --porcelain empty, git diff HEAD empty, all four anchors back at count 1).

Gates

main moved while this was in flight (#54 source defaults, #56 hierarchy-security — both touch objects this guard resolves against). It is merged in at 27d31a0; no field was renamed or removed, only default: flags on select options.

Gates re-run on the final commit 27d31a0, after the merge:

pnpm validate exit 0 ✓ Validation passed (400ms)
pnpm typecheck exit 0 tsc --noEmit
pnpm test exit 0 Test Files 13 passed (13) · Tests 407 passed (407)
pnpm build exit 0 Artifact: dist/objectstack.json (96.2 KB)

Exit codes captured before any pipe. 407 tests = 375 on merged main + 32 added. (The pre-merge reading at cf62af9 was 402 = 370 + 32; #54 and #56 added five.)

No changeset: this repo carries no changeset tooling, and the change is test-only.

---

Generated by Claude Code

[os-warren]

Fixes#51

Adds test/metadata-bindings.test.ts — one guard walking dulyViews, dulyDatasets and dulyApps and resolving every reference against dulyObjects. Labelled a stopgap pending objectstack#14105 / #14107 / #14108, written to be deleted rather than maintained, per the test/flow-predicates.test.ts convention.

Scope taken is the widened scope from the PM comment on the card (views + nav + datasets), not the datasets-only scope in the body.

Two things the reviewer should read first

1. No dangling reference exists in shipped metadata. The guard resolves 204 references — 145 view, 34 dataset, 25 nav — and all 204 resolve. So no metadata file is touched by this PR; the only change is the test. That is a real result, not a skipped check: the per-surface counters and the joined-path assertion below are what stop "green" from meaning "the walk did nothing".

2. The card's premise that "nothing has ever checked the five view files or the app nav" is wrong.test/views.test.ts (landed in #49) already resolves the simple view surface and the nav objectName / viewName pair. The card is still real — but the value is in the superset, not in first coverage. The remaining holes it closes:

Hole	Where it was
Datasets not covered at all	datasets.test.ts pins caliber / date-macros / absences, never that a field path names anything real
Dotted paths resolved by nothing	views.test.ts opens its checker with if (!name || name.includes('.')) return — so duty.frequency, the one joined path this app ships, was unchecked everywhere
Hand-copied system-column list	views.test.ts carries business_unit_id (not a platform column) and omits owning_business_unit_id, tenant_id, user_id, deleted_at (which are). This file imports the spec's own SystemFieldName
A view bound to a platform object would false-positive	its bound object had to be in dulyObjects; platform names now resolve from isPlatformProvidedObjectName
No self-test on either file	24 synthetic-fixture cases here pin both directions

The overlap is declared in the file header rather than resolved by deleting another card's guard — that is a follow-up, filed as #58. Until then it is benign: this file is the strict superset, so any disagreement reds here first.

What is checked

• Views — columns[] (both the bare-string and { field } spellings), columns[].summary.field, columns[].prefix.field, filter[].field, sort[].field (plus the legacy "field desc" string), grouping.fields[].field, rowColor.field, the searchableFields / filterableFields / hiddenFields / fieldOrder lists, and every binding block — kanban, calendar, gantt, timeline, gallery, tree, map.
• Datasets — base object, every include path, every dimension and measure field, and every filter key (the column is the key; the walk recurses $and / $or / $not and never mistakes an operator for a column). Also that a joined path's relationship is actually in include — every segment can name something real and still have no join to travel (ADR-0071).
• Joined paths — through a reference-carrying field to a real field on the target. Hopping through a scalar is reported as its own, more legible failure.
• Nav — every objectName, every viewName against the views declared on that object (a view of the right name on the wrong object is a finding), filters keys, and the no-viewName case when the object has no default list.

Beyond the card's enumerated list, and flagged because it is an addition: bulkActionDefs with operation: 'update' write fields — the static patch keys and the collected params[].name, which BulkActionDefSchema documents as merged over the patch. Same defect class, one layer down. Only update; on a custom def those are action params, not fields.

Narrowings, stated rather than hidden

• A hop into a platform object is a boundary, not a resolution.@objectstack/spec exports the platform object name registry but no field lists, so owner.some_typo cannot be judged. The hop is verified, the path is recorded, and a test fails the day one is authored — the hole is loud rather than silent.
• Field-bearing slots are hand-listed (the spec exports no slot table for view field references, unlike FLOW_NODE_EXPRESSION_PATHS for flow predicates), and the list polices itself: a tripwire scans the metadata for field-ish slots and fails on any the walk cannot read.
• Form views are not walked. This app declares none; a tripwire fails the day one appears.
• Tripwires likewise cover unknown nav item types and lookups targeting a name that is neither declared nor platform-provided.

Proving it can fail — four ablations, one per surface

Each leg: anchor asserted to occur exactly once before the edit, both the injected and the removed literal grepped afterwards, a non-empty git diff --stat required, and a trap … EXIT INT TERM restoring from HEAD (the guard was committed first, so this is a real restore point and not the index).

#	Mutation	pnpm validate	guard
1	view column category → categoree_typo	exit 0 — ✓ Validation passed (338ms)	exit 1
2	dataset filter keylast_update_at → last_update_attt	exit 0 — ✓ Validation passed (334ms)	exit 1
3	nav viewName: 'stalled' → 'not_moving'	exit 0 — ✓ Validation passed (430ms)	exit 1
4	joined path duty.frequency → duty.frequencee	exit 0 — ✓ Validation passed (432ms)	exit 1

Leg 3 is the one worth reading — the guard prints exactly what makes #14108 nasty:

app duly_app · nav 'nav_stalled' · viewName: "not_moving" — duly_task declares no list view named "not_moving" — the shell SILENTLY falls back to the default view and keeps this entry's authored label.

The label stays "Not moving". The screen looks right and shows the wrong rows.

Observed direction, not the template one: leg 4 reddened two tests, not one — the finding, plus the non-vacuity assertion that the joined path was reached at all. Diagnostics went up, which is the correct reading here: mutating the app's only multi-hop path both produces a finding and removes the evidence that the multi-hop walk runs.

All four restored; tree verified byte-identical to HEAD afterwards (git status --porcelain empty, git diff HEAD empty, all four anchors back at count 1).

Gates

main moved while this was in flight (#54 source defaults, #56 hierarchy-security — both touch objects this guard resolves against). It is merged in at 27d31a0; no field was renamed or removed, only default: flags on select options.

Gates re-run on the final commit 27d31a0, after the merge:

pnpm validate exit 0 ✓ Validation passed (400ms)
pnpm typecheck exit 0 tsc --noEmit
pnpm test exit 0 Test Files 13 passed (13) · Tests 407 passed (407)
pnpm build exit 0 Artifact: dist/objectstack.json (96.2 KB)

Exit codes captured before any pipe. 407 tests = 375 on merged main + 32 added. (The pre-merge reading at cf62af9 was 402 = 370 + 32; #54 and #56 added five.)

No changeset: this repo carries no changeset tooling, and the change is test-only.

---

Generated by Claude Code