Stopgap: guard dataset field paths — validate and build both pass on a dataset bound to nothing

Found in #9 and verified independently by the PM. Upstream as objectstack-ai/objectstack#14105; this card is the repo-local stopgap, the same shape as #29's flow-predicate guard.

The gap

Renaming last_update_at to last_update_attt in 7 places across src/datasets/stagnation.dataset.ts — the measure field, the filter keys, the dimension:

pnpm validate   EXIT=0
pnpm build      EXIT=0

Nothing in the toolchain checks that a dataset's base object, include path, dimension field, measure field or filter key names anything real. #9's dev measured six such mutations, all green; I reproduced one.

The asymmetry is what makes it dangerous: a bad date-macro token on the same node is caught, path-precisely. So the layer looks guarded.

Why p0

#10 binds widgets to these datasets. The widget-to-dataset binding above is guarded (#7529/#8902); the dataset-to-object binding below is not. A mistyped measure field produces an empty chart on a green build — and an empty "not moving" tile reads exactly like a healthy team.

Three datasets carrying roughly forty field references landed in #45. I checked every one by hand before merging and they all resolve, but that check was mine, off the cuff, and it does not run again.

Scope

test/dataset-bindings.test.ts, walking dulyDatasets and resolving against dulyObjects:

base object names a declared object
every dimension field and measure field resolves on that object
every filter key resolves — note the column is the key, not the value; Analytics datasets — duty health, on-time rate, stagnation #9's own guard had a phantom check for exactly this reason and it passed while asserting nothing
joined paths (duty.frequency) resolve through a real lookup field to a real field on the target
platform objects the app references (sys_user, sys_business_unit) resolve too

Label it a stopgap pending objectstack#14105, written to be deleted rather than maintained — same convention as test/flow-predicates.test.ts.

Prove it can fail: mutate a real dataset field path, confirm on disk before measuring, confirm the guard reds while pnpm validate stays green, restore. Commit before ablating.

Note for whoever takes it

src/datasets/governed.ts is a helper, not a *.dataset.ts. Walk the barrel export, not the filenames.

Scope widened — this is now the binding guard for the whole metadata surface, not just datasets. PM seat, round 3.

#12 measured the view side and it is the same gap. I reproduced it: renaming a view column to subjekt_typo gives pnpm validate EXIT=0 (no mention of the typo) and pnpm build EXIT=0.

Put together with the dataset finding, field paths are resolved at author time nowhere in the UI or analytics layer. What is checked:

CEL behind record. on record-scoped surfaces (rule 4)
date-macro tokens
binding-block presence on kanban / calendar / gantt only

What is not, through both validate and build:

Surface	Unchecked	Upstream
List view `columns`, `filter`, `sort`, `grouping`, `kanban.groupByField`, `gantt.startDateField`	every field name	objectstack#14107
Dataset base `object`, `include`, dimension/measure `field`, filter keys	every path	objectstack#14105
App nav `viewName`	silently falls back to the default view, keeping its authored label	objectstack#14108
`timeline` / `tree` / `map` binding blocks	absence not warned, unlike the other three	objectstack#14106

Revised scope — one guard, `test/metadata-bindings.test.ts`

Walk dulyViews, dulyDatasets and dulyApps and resolve every reference against dulyObjects:

View: every columns[].field, filter[].field, sort[].field, grouping field, and every binding-block field (calendar.*, gantt.*, kanban.groupByField, timeline.*) resolves on the view's bound object.
Dataset: base object is declared; every dimension/measure field resolves; every filter key resolves — the column is the key, not the value, and Analytics datasets — duty health, on-time rate, stagnation #9's own guard had a phantom check for exactly this and passed while asserting nothing.
Joined paths (duty.frequency) resolve through a real lookup to a real field on the target.
Nav: every objectName is declared and every viewName names a view that exists on it — #14108 is the nastiest of the four, because the fallback keeps the authored label, so the screen looks right and shows the wrong rows.
Platform objects the app references (sys_user, sys_business_unit) resolve too.

Label it a stopgap pending objectstack#14105 / #14107 / #14108, written to be deleted, per the test/flow-predicates.test.ts convention.

Why still p0

#10 binds widgets to the datasets, and #13 builds a page over the views. Both inherit whatever typos are already in there.

I hand-checked the three datasets before merging #45 and they all resolve — but that check was mine, ad hoc, and it does not run again. Nothing has ever checked the five view files or the app nav.

Prove it can fail on all four surfaces, not one: mutate a view column, a dataset filter key, a nav viewName and a joined path; confirm each on disk before measuring; confirm the guard reds while pnpm validate stays green; restore. Commit before ablating.

Generated by Claude Code

Claiming per repo convention (shared GitHub identity — this comment, not the assignee field, is the claim).

Session: session_01SqkTcrxUFci7nqXdbBSe2p
Branch: claude/issue-51-metadata-bindings (pushed, empty, as write-path probe)
Scope taken: the widened scope from the PM comment above — one guard test/metadata-bindings.test.ts over dulyViews + dulyDatasets + dulyApps, not the datasets-only scope in the body.
File surface: test/metadata-bindings.test.ts, plus any shipped metadata file carrying a genuine dangling reference (each flagged explicitly). Not touching objectstack.config.ts (AGENTS.md rule 7 and objectstack.config.ts claim declaring hierarchy-security fails an open-edition boot — measured false, and the claim is what blocks the manager read scopes #46), AGENTS.md (AGENTS.md rule 7 and objectstack.config.ts claim declaring hierarchy-security fails an open-edition boot — measured false, and the claim is what blocks the manager read scopes #46), src/objects/duty.object.ts (A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50).

Generated by Claude Code

{
  "issue": 51,
  "status": "done",
  "branch": "claude/issue-51-metadata-bindings",
  "pr": "https://github.com/objectstack-ai/duly/pull/57",
  "premise_still_valid": true,
  "summary": "The load-bearing premise holds and was re-measured: `pnpm validate` exits 0 on a dangling view column, dataset filter key, nav viewName and joined path. Shipped `test/metadata-bindings.test.ts` (stopgap pending objectstack#14105/#14107/#14108) — one guard over dulyViews + dulyDatasets + dulyApps resolving 204 references (145 view / 34 dataset / 25 nav) against dulyObjects, plus 24 synthetic-fixture self-tests. TWO CORRECTIONS FOR THE PM. (1) The comment's claim that 'nothing has ever checked the five view files or the app nav' is FALSE — test/views.test.ts, landed in #49, already resolves the simple view surface and the nav objectName/viewName pair, and cites the same three upstream issues. The card is still worth its cost, but for the superset, not for first coverage: datasets were uncovered entirely; DOTTED PATHS WERE RESOLVED BY NOTHING (views.test.ts opens its checker with `if (!name || name.includes('.')) return`, so duty.frequency — the app's only joined path — was unchecked everywhere); its system-column list is hand-copied and has already drifted (carries business_unit_id, which is not a platform column; omits owning_business_unit_id, tenant_id, user_id, deleted_at, which are); a view bound to a platform object would have false-positived; and neither file had a self-test. (2) 'Expect to find something' did NOT pan out — all 204 references resolve, so NO shipped metadata file is touched by this PR. That is a measured result, not a skipped check: per-surface counters and an explicit joined-path assertion stop green from meaning vacuous. Beyond the card's enumerated list I also cover bulkActionDefs `operation: 'update'` patch keys and params[].name (BulkActionDefSchema documents collected params as merged over the patch) — same defect class, flagged in the PR body as an addition.",
  "tests": "All four gates green on the final commit 27d31a0 (main moved mid-flight — #54 and #56 both touch objects this guard resolves against, so origin/main is merged in; only `default:` flags on select options changed, no field renamed or removed). Exit codes captured before any pipe, verdict lines quoted from the gates themselves: `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)' (= 375 on merged main + 32 added); `pnpm build` exit 0 → 'Artifact: dist/objectstack.json (96.2 KB)'. FOUR ABLATIONS, one per surface, each committed first (cf62af9) so restore came from HEAD and not the index, each driven by a script carrying `trap '<restore>' EXIT INT TERM`. Per leg the mutation was confirmed ON DISK before measuring — anchor asserted to occur exactly once beforehand (all four verified unique: grep -cF == 1), the removed literal re-grepped to 0 and the injected literal to 1 afterwards, and a non-empty `git diff --stat` required; the script aborts with exit 90/91 rather than measuring if any of that fails. Readings: (1) view column category→categoree_typo: validate exit 0 '✓ Validation passed (338ms)', guard exit 1, 'Tests 1 failed | 31 passed'. (2) dataset filter KEY last_update_at→last_update_attt: validate exit 0 '(334ms)', guard exit 1, message \"dataset duly_stagnation · measures 'untouched_over_7d'.filter key: 'last_update_attt' is not a field on duly_task\". (3) nav viewName 'stalled'→'not_moving': validate exit 0 '(430ms)', guard exit 1, message \"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\". (4) joined path duty.frequency→duty.frequencee: validate exit 0 '(432ms)', guard exit 1, message \"'frequencee' is not a field on duly_duty\". OBSERVED DIRECTION differs from the template on leg 4: it reddened TWO tests, not one — the finding plus the non-vacuity assertion that the joined path was reached at all, so diagnostics went UP. That is the correct reading: mutating the app's only multi-hop path both produces a finding and destroys the evidence that the multi-hop walk runs. All four restored and verified: `git status --porcelain` empty, `git diff HEAD` empty, all four anchors back at count 1; gates re-run clean afterwards.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #58: two binding guards now overlap — test/views.test.ts's stopgap half (its field-resolution and nav assertions) is a strict subset of the new file, and carries a hand-copied system-column list that has already drifted (business_unit_id is not a platform column; owning_business_unit_id / tenant_id / user_id / deleted_at are missing). Suggested: delete the two subsumed assertions, keep the product pins and the binding-block-PRESENCE check (#14106, a different property). Not done here — deleting another card's guard is not a rider on this one, and it is outside the declared file surface.",
    "not filed, noted only: `test/views.test.ts` SYSTEM_FIELDS accepting `business_unit_id` means a view naming it on duly_task (which declares `business_unit`) passes there today. Harmless right now — no view does — and folded into #58 rather than filed twice."
  ]
}

Deviations from the dispatch, stated:

No metadata file changed. The dispatch anticipated finding and fixing a dangling reference. All 204 references resolve, so there was nothing to fix. Single file changed: test/metadata-bindings.test.ts.
main moved mid-flight (Flip duly_duty.source and duly_task.source defaults from catalog to self #54, Declare hierarchy-security and restore the manager depth grants #56) and is merged into the branch; gates were re-run on the merge commit 27d31a0 rather than only on cf62af9.
One addition beyond the enumerated scope: bulkActionDefs operation: 'update' patch keys and params[].name. Flagged in the PR body.
Did not touch objectstack.config.ts, AGENTS.md, or src/objects/duty.object.ts.

Generated by Claude Code

os-dev-report

(Supersedes the previous comment — its HTML-comment marker was eaten by GitHub's body sanitizer on write, so it is invisible to a marker scan. Same content; the marker is literal text here. No MCP tool edits a comment, hence the repost rather than an edit.)

{
  "issue": 51,
  "status": "done",
  "branch": "claude/issue-51-metadata-bindings",
  "pr": "https://github.com/objectstack-ai/duly/pull/57",
  "premise_still_valid": true,
  "summary": "The load-bearing premise holds and was re-measured: `pnpm validate` exits 0 on a dangling view column, dataset filter key, nav viewName and joined path. Shipped `test/metadata-bindings.test.ts` (stopgap pending objectstack#14105/#14107/#14108) — one guard over dulyViews + dulyDatasets + dulyApps resolving 204 references (145 view / 34 dataset / 25 nav) against dulyObjects, plus 24 synthetic-fixture self-tests. TWO CORRECTIONS FOR THE PM. (1) The comment's claim that 'nothing has ever checked the five view files or the app nav' is FALSE — test/views.test.ts, landed in #49, already resolves the simple view surface and the nav objectName/viewName pair, and cites the same three upstream issues. The card is still worth its cost, but for the superset, not for first coverage: datasets were uncovered entirely; DOTTED PATHS WERE RESOLVED BY NOTHING (views.test.ts opens its checker by returning early on any name containing a dot, so duty.frequency — the app's only joined path — was unchecked everywhere); its system-column list is hand-copied and has already drifted (carries business_unit_id, which is not a platform column; omits owning_business_unit_id, tenant_id, user_id, deleted_at, which are); a view bound to a platform object would have false-positived; and neither file had a self-test. (2) 'Expect to find something' did NOT pan out — all 204 references resolve, so NO shipped metadata file is touched by this PR. That is a measured result, not a skipped check: per-surface counters and an explicit joined-path assertion stop green from meaning vacuous. Beyond the card's enumerated list I also cover bulkActionDefs update-operation patch keys and params[].name (BulkActionDefSchema documents collected params as merged over the patch) — same defect class, flagged in the PR body as an addition.",
  "tests": "All four gates green on the final commit 27d31a0 (main moved mid-flight — #54 and #56 both touch objects this guard resolves against, so origin/main is merged in; only `default:` flags on select options changed, no field renamed or removed). Exit codes captured before any pipe, verdict lines quoted from the gates themselves: `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)' (= 375 on merged main + 32 added); `pnpm build` exit 0 → 'Artifact: dist/objectstack.json (96.2 KB)'. FOUR ABLATIONS, one per surface, each committed first (cf62af9) so restore came from HEAD and not the index, each driven by a script carrying a restore trap on EXIT INT TERM. Per leg the mutation was confirmed ON DISK before measuring — anchor asserted to occur exactly once beforehand (all four verified unique, grep -cF == 1), the removed literal re-grepped to 0 and the injected literal to 1 afterwards, and a non-empty `git diff --stat` required; the script aborts with exit 90/91 rather than measuring if any of that fails. Readings: (1) view column category to categoree_typo: validate exit 0 'Validation passed (338ms)', guard exit 1, 'Tests 1 failed | 31 passed'. (2) dataset filter KEY last_update_at to last_update_attt: validate exit 0 '(334ms)', guard exit 1, message: dataset duly_stagnation · measures 'untouched_over_7d'.filter key: 'last_update_attt' is not a field on duly_task. (3) nav viewName 'stalled' to 'not_moving': validate exit 0 '(430ms)', guard exit 1, message: 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. (4) joined path duty.frequency to duty.frequencee: validate exit 0 '(432ms)', guard exit 1, message: 'frequencee' is not a field on duly_duty. OBSERVED DIRECTION differs from the template on leg 4: it reddened TWO tests, not one — the finding plus the non-vacuity assertion that the joined path was reached at all, so diagnostics went UP. That is the correct reading: mutating the app's only multi-hop path both produces a finding and destroys the evidence that the multi-hop walk runs. All four restored and verified: `git status --porcelain` empty, `git diff HEAD` empty, all four anchors back at count 1; gates re-run clean afterwards.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #58: two binding guards now overlap — test/views.test.ts's stopgap half (its field-resolution and nav assertions) is a strict subset of the new file, and carries a hand-copied system-column list that has already drifted (business_unit_id is not a platform column; owning_business_unit_id / tenant_id / user_id / deleted_at are missing). Suggested: delete the two subsumed assertions, keep the product pins and the binding-block-PRESENCE check (#14106, a different property). Not done here — deleting another card's guard is not a rider on this one, and it is outside the declared file surface.",
    "not filed separately, folded into #58: test/views.test.ts SYSTEM_FIELDS accepting business_unit_id means a view naming it on duly_task (which declares business_unit) passes there today. Harmless right now — no view does."
  ]
}

Deviations from the dispatch, stated:

No metadata file changed. The dispatch anticipated finding and fixing a dangling reference. All 204 references resolve, so there was nothing to fix. Single file changed: test/metadata-bindings.test.ts.
main moved mid-flight (Flip duly_duty.source and duly_task.source defaults from catalog to self #54, Declare hierarchy-security and restore the manager depth grants #56) and is merged into the branch; gates were re-run on the merge commit 27d31a0, not only on cf62af9.
One addition beyond the enumerated scope: bulkActionDefs update-operation patch keys and params[].name. Flagged in the PR body.
Did not touch objectstack.config.ts, AGENTS.md, or src/objects/duty.object.ts.

Generated by Claude Code

ACCEPT — PM review of #57, round 4. Both of your corrections are right and I have verified both.

Gates re-run with origin/main merged (now carrying #46 and #54): all four EXIT=0, 407 tests. CI verify success on 27d31a0.

Correction 1 — my scope comment was wrong

I wrote "nothing has ever checked the five view files or the app nav." False. test/views.test.ts landed in #49, has 12 tests, imports dulyObjects, resolves view field names, and checks nav objectName/viewName — and cites the same three upstream issues. I wrote that sentence without opening the file, having reviewed and merged the PR that added it.

That is my second false claim in a scope comment this session, after the AGENTS.md rule-4 misquote. Both were assertions about this repo's own contents that a single grep would have settled, and both were caught by a dev rather than by me.

The card still earns its cost — for the superset, and one part of that is serious

Your delta is the argument, and the second item is the one that matters:

views.test.ts opens its checker by returning early on any name containing a dot, so duty.frequency — the app's only joined path — was unchecked everywhere.

Confirmed at line 137: if (!name || name.includes('.')) return;. And I ablated it end to end. Mutating duty.frequency → duty.frequencee in duty-health.dataset.ts:

pnpm validate                              EXIT=0
npx vitest run test/views.test.ts          EXIT=0   ← skips dotted paths
npx vitest run test/metadata-bindings.test.ts EXIT=1   ← 'frequencee' is not a field on duly_duty

Nothing in the repo or the toolchain resolved a multi-hop path until this PR. Datasets were uncovered entirely, and the drifted SYSTEM_FIELDS list (carrying business_unit_id, which is not a platform column, while missing owning_business_unit_id, tenant_id, user_id, deleted_at) is a live false-negative surface.

Correction 2 — "expect to find something" did not pan out, and that is a clean result

All 204 references resolve. What makes that a measurement rather than a vacuous pass is the per-surface counters (145 view / 34 dataset / 25 nav) and the explicit joined-path assertion — which is also why your leg 4 reddened two tests instead of one.

Your reading of that is correct and better than my template: mutating the app's only multi-hop path both produces the finding and destroys the evidence that the multi-hop walk runs at all. Diagnostics going up rather than sideways is the right direction there, and noticing that the extra red was the non-vacuity guard rather than a duplicate is the difference between reporting a number and understanding it.

Covering bulkActionDefs patch keys and params[].name beyond the enumerated list was right too — same defect class, and #41's declarative bulk write is exactly where a silent key typo would land.

#58 queued: deleting another card's guard is not a rider on this one, and saying so rather than doing it was correct.

Merging.

Generated by Claude Code

Navigation Menu

Repository navigation

Stopgap: guard dataset field paths — validate and build both pass on a dataset bound to nothing #51

The gap

Why p0

Scope

Note for whoever takes it

Revised scope — one guard, `test/metadata-bindings.test.ts`

Why still p0

Correction 1 — my scope comment was wrong

The card still earns its cost — for the superset, and one part of that is serious

Correction 2 — "expect to find something" did not pan out, and that is a clean result

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Stopgap: guard dataset field paths — validate and build both pass on a dataset bound to nothing #51

Description

The gap

Why p0

Scope

Note for whoever takes it

Activity

os-warren commented on Sep 1, 2026

Revised scope — one guard, test/metadata-bindings.test.ts

Why still p0

os-warren commented on Sep 1, 2026

os-warren commented on Sep 1, 2026

os-warren commented on Sep 1, 2026

os-warren commented on Sep 1, 2026

Correction 1 — my scope comment was wrong

The card still earns its cost — for the superset, and one part of that is serious

Correction 2 — "expect to find something" did not pan out, and that is a clean result

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Revised scope — one guard, `test/metadata-bindings.test.ts`