fix(lint): resolve every field reference on a list view at validate and build

[claude]

Fixes#14107

A list view names fields in more than forty places and none of them was resolved against the bound object — not by os validate, and not by os build, which is the publish gate. This adds one rule, list-view-field-unknown (validateListViewFieldRefs), over every one of those positions, resolving through the shared object-graph seam that #14105 and #14148 landed.

Premise re-check on today's origin/main

Re-measured on this branch's merge base (0fb3044f6), not inferred from the card:

• The seam exists and is exported.indexObjectGraph, resolveFieldPath, describeFieldPathVerdict, isUnjudgeable, suggestName and listNames are all public from packages/lint/src/object-graph.ts, whose own docblock already names this card as its third consumer. Both family landings are in the base — objectstack validate and build accept a dataset whose base object, include path and dimension/measure field paths all name nothing — the same walker already resolves date-macro tokens on the identical node #14105 (345fc33a) and A dashboard widget's OWN filter keys and options.sortBy are not resolved at author time — validate/build exit 0, widget renders empty #14148 (fa1eca31).
• The gap is still open. A probe ran the whole authoring-rule table (runAuthoringRules, both validate and build) over one mutated list view per position, for each of the card's five measured positions. With the new rule present each mutation produced exactly one finding, from this rule; with it filtered out, the only remaining findings were fixture-inherent and unrelated (field/choice-without-options on the fixture's select field, security-owd-unset on the fixture object) — no existing rule reports any of the five. The probe was a throwaway file, deleted before the first commit.
• The two exceptions really do have owners. A bad sort[].field already reports sort-field-unknown; a bad searchableFields[] entry already reports searchable-field-unknown. Both are pinned as non-regression tests here, so this rule cannot start double-reporting them.

Seam reuse

Resolution is resolveFieldPath's and the message half is describeFieldPathVerdict's; the "did you mean" is the seam's suggestName. No second field-resolution implementation and no copied suggestion helper — the existing three-copy problem is carded separately as #14268 and gains no fourth copy here. The three standard skips arrive as the seam's unknowable verdicts (object not in this stack, no readable field map, registry-injected system column), and this surface adds a fourth of its own: a list view whose data.provider is not object binds to no object graph at all.

The dotted-path decision — recorded, not silent

The card (written before the seam existed) suggested skipping dotted paths "as the chart rule already does". The seam can now walk relationship hops, so this needed an explicit call. Decision: judge the HEAD segment; do not walk hops. The reason is what the runtime does, not effort:

• A ListViewSchema declares no ADR-0021 include, so a list view compiles no joins — the declaration that makes hop-walking meaningful at a dataset position has no counterpart here.
• All three query axes a list view reaches refuse a dotted reference by name. Projection: assertProjectionHasNoDottedPaths in packages/objectql/src/engine.ts (verified present on this base) and assertProjectionFieldsExist at the REST ingress. Filter: the dotted-head door. Sort: assertSortFieldsExist's unknown / dotted / unmaterializable ladder.

Walking hops would therefore blessowner.name in a list view's columns — a reference every runtime door refuses — and teach an AI author that a traversal works on a surface where nothing implements it. Judging the head is also what validate-sortable-fields already does on this same surface.

The result is strictly wider than the card's suggestion: ownr.name is reported (a skip would have passed it), and the finding says which segment was judged so the author reads back the string they typed. What stays unreported is a dotted path whose head does resolve — a larger accept-set narrowing whose failure mode is a loud 400 rather than the silent-empty class this card gates. Filed as #14282 rather than folded in, and both halves are pinned in tests so a later change that starts walking hops has to delete a test that states the reason.

Positions covered

Top level: columns[] (bare-string and { field } forms, plus summary.field and prefix.field), filter[] keys, tabs[].filter[] keys, grouping.fields[], rowColor.field, userFilters.fields[], userFilters.tabs[].filter[] keys, filterableFields[], hiddenFields[], fieldOrder[].

Layout blocks: every field binding on kanban, calendar, gantt (including tooltipFields[] and quickFilters[].field), timeline, gallery, map and tree. The rule's POSITIONS table was checked key-by-key against ListViewShapeSchema and each block schema in packages/spec/src/ui/view.zod.ts, so no walked key is a phantom and no field-naming key is missing.

Filter keys go through walkFilterFieldKeys, so all three authored filter shapes are judged rather than one being walked and the others silently skipped.

Deliberately excluded, with reasons

• sort[] and searchableFields[] — owned by validate-sortable-fields (A view's declared sort naming a formula field clears lint, then 400s on every load — the SORT axis has no authoring gate, unlike SEARCH (#6674) #9257) and validate-searchable-fields (A virtual formula field declared in searchableFields clears lint and the #4254 gate, then silently matches nothing — the same fail-open shape #4254 closed one axis over #6674/compiler/validate: view searchableFields not validated against searchable field types — a declaration typo 400s the whole list at runtime #4830), each adding a runtime-admissibility verdict this rule has no business restating.
• chart (dataset / dimensions / values) — dataset, dimension and measure names, not fields on the bound object; owned by validateChartBindings / validateDatasetReferences.
• rowActions / bulkActions / columns[].action — action names, owned by validateActionNameRefs.
• conditionalFormatting[].condition — a CEL predicate, owned by the expression rules.
• pageName / tabs[].view / addRecord.formView — page and view names, owned by validateViewPageRefs and lintViewRefs.
• data.object itself — owned by validateObjectReferences. When the bound object does not resolve, this rule skips the whole list view, so one typo yields one finding rather than one per position (pinned).

Severity — two tiers, the validateFlowTemplatePaths precedent

error where the miss changes what data the view returns or collapses the layout it configures (every position in the card's measured table); warning where the renderer drops one decoration and renders the rest (optional colour/title/tooltip/cover bindings, a stale hiddenFields or fieldOrder entry).

Acceptance — validate AND build, pinned end-to-end

Following the #14148 precedent, the acceptance block drives runAuthoringRules for both commands rather than inferring the answer from the registry entry: each of the card's five measured positions fails validate and fails build, the fully-bound list view passes both, and a warning-tier position advises rather than gates. The rule also joins the reference-integrity suite's view runtime type, so the standalone list view a Studio tenant or an MCP author writes through the per-write publish door is judged too — that crossing is argued in the suite's own granularity-wall test.

Verification

All readings below are from commit 910f9d26b, the branch head this PR opens on.

• pnpm --filter @objectstack/lint test — 91 files, 2660 tests passed.
• pnpm --filter @objectstack/lint run typecheck — clean. Note the package's tsconfig.json excludes *.test.ts, so that run says nothing about the test files; a throwaway config including them was run separately and produced zero errors naming any of the three test files this PR adds or edits (the 22 errors it did report are pre-existing, in seven sibling test files).
• Gate families derived mechanically from the real change set (node scripts/pm/dispatch-gates.mjs, 33 families, harvested with --commands): 30 green, 3 NOT MEASURED because they refuse without inputs this worktree does not have — check-test-completeness (exit 3, needs a saved turbo run test log; the gate documents this branch as the local NOT-MEASURED case), check:dual-build-cjs-loads (exit 3, needs a full workspace build), check:type-check-debt (exit 3, same). check-half-states timed out at 300s making live GitHub calls and is likewise recorded as NOT MEASURED — none of the four is a red, and none is a finding about this diff.
• Also green: check:ratchet-remedy-authority, check:declared-population-live, check:nul-bytes.
• pnpm lint (repo-wide ESLint, eslint . --no-inline-config) — clean, run whole rather than narrowed.

Changeset: minor for @objectstack/lint — an accept-set narrowing, matching the family precedent set by #14105 and #14148.

This branch was recovered rather than restarted: the predecessor dev on this card died in a container restart with its work committed in the worktree but never pushed, so the remote branch read as empty. The recovered commit was re-verified here from the premise up before this PR was opened.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/lint, touching 18 documentable anchor(s). ⚠️1 changed file(s) yielded no anchor (packages/lint/src/index.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

7 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/plugin-endpoints.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/concepts/metadata-lifecycle.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/deployment/validating-metadata.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/kernel/services-checklist.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/protocol/objectui/index.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/forms.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/pages.mdx(via userFilters (symbol, a field of const object POSITIONS))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v12.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/releases/v15.mdx(via userFilters (symbol, a field of const object POSITIONS))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/lint/src/index.ts) — pages documenting those are invisible to this run
• 15 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 5 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from f170075cc7645caf77aa29c0de92270082061b4f — the merge of head 910f9d26bdad38dd06395af1b23a03936dda3277 into base 8125673462b3c0a6d42ef5b002acd4f77c1a9789, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin f170075cc7645caf77aa29c0de92270082061b4f && git checkout f170075cc7645caf77aa29c0de92270082061b4f
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 8125673462b3c0a6d42ef5b002acd4f77c1a9789 910f9d26bdad38dd06395af1b23a03936dda3277 && git checkout -B drift-repro 8125673462b3c0a6d42ef5b002acd4f77c1a9789 && git merge --no-ff 910f9d26bdad38dd06395af1b23a03936dda3277
node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Fixes#14107

A list view names fields in more than forty places and none of them was resolved against the bound object — not by os validate, and not by os build, which is the publish gate. This adds one rule, list-view-field-unknown (validateListViewFieldRefs), over every one of those positions, resolving through the shared object-graph seam that #14105 and #14148 landed.

Premise re-check on today's origin/main

Re-measured on this branch's merge base (0fb3044f6), not inferred from the card:

• The seam exists and is exported.indexObjectGraph, resolveFieldPath, describeFieldPathVerdict, isUnjudgeable, suggestName and listNames are all public from packages/lint/src/object-graph.ts, whose own docblock already names this card as its third consumer. Both family landings are in the base — objectstack validate and build accept a dataset whose base object, include path and dimension/measure field paths all name nothing — the same walker already resolves date-macro tokens on the identical node #14105 (345fc33a) and A dashboard widget's OWN filter keys and options.sortBy are not resolved at author time — validate/build exit 0, widget renders empty #14148 (fa1eca31).
• The gap is still open. A probe ran the whole authoring-rule table (runAuthoringRules, both validate and build) over one mutated list view per position, for each of the card's five measured positions. With the new rule present each mutation produced exactly one finding, from this rule; with it filtered out, the only remaining findings were fixture-inherent and unrelated (field/choice-without-options on the fixture's select field, security-owd-unset on the fixture object) — no existing rule reports any of the five. The probe was a throwaway file, deleted before the first commit.
• The two exceptions really do have owners. A bad sort[].field already reports sort-field-unknown; a bad searchableFields[] entry already reports searchable-field-unknown. Both are pinned as non-regression tests here, so this rule cannot start double-reporting them.

Seam reuse

Resolution is resolveFieldPath's and the message half is describeFieldPathVerdict's; the "did you mean" is the seam's suggestName. No second field-resolution implementation and no copied suggestion helper — the existing three-copy problem is carded separately as #14268 and gains no fourth copy here. The three standard skips arrive as the seam's unknowable verdicts (object not in this stack, no readable field map, registry-injected system column), and this surface adds a fourth of its own: a list view whose data.provider is not object binds to no object graph at all.

The dotted-path decision — recorded, not silent

The card (written before the seam existed) suggested skipping dotted paths "as the chart rule already does". The seam can now walk relationship hops, so this needed an explicit call. Decision: judge the HEAD segment; do not walk hops. The reason is what the runtime does, not effort:

• A ListViewSchema declares no ADR-0021 include, so a list view compiles no joins — the declaration that makes hop-walking meaningful at a dataset position has no counterpart here.
• All three query axes a list view reaches refuse a dotted reference by name. Projection: assertProjectionHasNoDottedPaths in packages/objectql/src/engine.ts (verified present on this base) and assertProjectionFieldsExist at the REST ingress. Filter: the dotted-head door. Sort: assertSortFieldsExist's unknown / dotted / unmaterializable ladder.

Walking hops would therefore blessowner.name in a list view's columns — a reference every runtime door refuses — and teach an AI author that a traversal works on a surface where nothing implements it. Judging the head is also what validate-sortable-fields already does on this same surface.

The result is strictly wider than the card's suggestion: ownr.name is reported (a skip would have passed it), and the finding says which segment was judged so the author reads back the string they typed. What stays unreported is a dotted path whose head does resolve — a larger accept-set narrowing whose failure mode is a loud 400 rather than the silent-empty class this card gates. Filed as #14282 rather than folded in, and both halves are pinned in tests so a later change that starts walking hops has to delete a test that states the reason.

Positions covered

Top level: columns[] (bare-string and { field } forms, plus summary.field and prefix.field), filter[] keys, tabs[].filter[] keys, grouping.fields[], rowColor.field, userFilters.fields[], userFilters.tabs[].filter[] keys, filterableFields[], hiddenFields[], fieldOrder[].

Layout blocks: every field binding on kanban, calendar, gantt (including tooltipFields[] and quickFilters[].field), timeline, gallery, map and tree. The rule's POSITIONS table was checked key-by-key against ListViewShapeSchema and each block schema in packages/spec/src/ui/view.zod.ts, so no walked key is a phantom and no field-naming key is missing.

Filter keys go through walkFilterFieldKeys, so all three authored filter shapes are judged rather than one being walked and the others silently skipped.

Deliberately excluded, with reasons

• sort[] and searchableFields[] — owned by validate-sortable-fields (A view's declared sort naming a formula field clears lint, then 400s on every load — the SORT axis has no authoring gate, unlike SEARCH (#6674) #9257) and validate-searchable-fields (A virtual formula field declared in searchableFields clears lint and the #4254 gate, then silently matches nothing — the same fail-open shape #4254 closed one axis over #6674/compiler/validate: view searchableFields not validated against searchable field types — a declaration typo 400s the whole list at runtime #4830), each adding a runtime-admissibility verdict this rule has no business restating.
• chart (dataset / dimensions / values) — dataset, dimension and measure names, not fields on the bound object; owned by validateChartBindings / validateDatasetReferences.
• rowActions / bulkActions / columns[].action — action names, owned by validateActionNameRefs.
• conditionalFormatting[].condition — a CEL predicate, owned by the expression rules.
• pageName / tabs[].view / addRecord.formView — page and view names, owned by validateViewPageRefs and lintViewRefs.
• data.object itself — owned by validateObjectReferences. When the bound object does not resolve, this rule skips the whole list view, so one typo yields one finding rather than one per position (pinned).

Severity — two tiers, the validateFlowTemplatePaths precedent

error where the miss changes what data the view returns or collapses the layout it configures (every position in the card's measured table); warning where the renderer drops one decoration and renders the rest (optional colour/title/tooltip/cover bindings, a stale hiddenFields or fieldOrder entry).

Acceptance — validate AND build, pinned end-to-end

Following the #14148 precedent, the acceptance block drives runAuthoringRules for both commands rather than inferring the answer from the registry entry: each of the card's five measured positions fails validate and fails build, the fully-bound list view passes both, and a warning-tier position advises rather than gates. The rule also joins the reference-integrity suite's view runtime type, so the standalone list view a Studio tenant or an MCP author writes through the per-write publish door is judged too — that crossing is argued in the suite's own granularity-wall test.

Verification

All readings below are from commit 910f9d26b, the branch head this PR opens on.

• pnpm --filter @objectstack/lint test — 91 files, 2660 tests passed.
• pnpm --filter @objectstack/lint run typecheck — clean. Note the package's tsconfig.json excludes *.test.ts, so that run says nothing about the test files; a throwaway config including them was run separately and produced zero errors naming any of the three test files this PR adds or edits (the 22 errors it did report are pre-existing, in seven sibling test files).
• Gate families derived mechanically from the real change set (node scripts/pm/dispatch-gates.mjs, 33 families, harvested with --commands): 30 green, 3 NOT MEASURED because they refuse without inputs this worktree does not have — check-test-completeness (exit 3, needs a saved turbo run test log; the gate documents this branch as the local NOT-MEASURED case), check:dual-build-cjs-loads (exit 3, needs a full workspace build), check:type-check-debt (exit 3, same). check-half-states timed out at 300s making live GitHub calls and is likewise recorded as NOT MEASURED — none of the four is a red, and none is a finding about this diff.
• Also green: check:ratchet-remedy-authority, check:declared-population-live, check:nul-bytes.
• pnpm lint (repo-wide ESLint, eslint . --no-inline-config) — clean, run whole rather than narrowed.

Changeset: minor for @objectstack/lint — an accept-set narrowing, matching the family precedent set by #14105 and #14148.

This branch was recovered rather than restarted: the predecessor dev on this card died in a container restart with its work committed in the worktree but never pushed, so the remote branch read as empty. The recovered commit was re-verified here from the premise up before this PR was opened.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/lint, touching 18 documentable anchor(s). ⚠️1 changed file(s) yielded no anchor (packages/lint/src/index.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

7 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/plugin-endpoints.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/concepts/metadata-lifecycle.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/deployment/validating-metadata.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/kernel/services-checklist.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/protocol/objectui/index.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/forms.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/pages.mdx(via userFilters (symbol, a field of const object POSITIONS))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v12.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/releases/v15.mdx(via userFilters (symbol, a field of const object POSITIONS))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/lint/src/index.ts) — pages documenting those are invisible to this run
• 15 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 5 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from f170075cc7645caf77aa29c0de92270082061b4f — the merge of head 910f9d26bdad38dd06395af1b23a03936dda3277 into base 8125673462b3c0a6d42ef5b002acd4f77c1a9789, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin f170075cc7645caf77aa29c0de92270082061b4f && git checkout f170075cc7645caf77aa29c0de92270082061b4f
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 8125673462b3c0a6d42ef5b002acd4f77c1a9789 910f9d26bdad38dd06395af1b23a03936dda3277 && git checkout -B drift-repro 8125673462b3c0a6d42ef5b002acd4f77c1a9789 && git merge --no-ff 910f9d26bdad38dd06395af1b23a03936dda3277
node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Fixes#14107

A list view names fields in more than forty places and none of them was resolved against the bound object — not by os validate, and not by os build, which is the publish gate. This adds one rule, list-view-field-unknown (validateListViewFieldRefs), over every one of those positions, resolving through the shared object-graph seam that #14105 and #14148 landed.

Premise re-check on today's origin/main

Re-measured on this branch's merge base (0fb3044f6), not inferred from the card:

• The seam exists and is exported.indexObjectGraph, resolveFieldPath, describeFieldPathVerdict, isUnjudgeable, suggestName and listNames are all public from packages/lint/src/object-graph.ts, whose own docblock already names this card as its third consumer. Both family landings are in the base — objectstack validate and build accept a dataset whose base object, include path and dimension/measure field paths all name nothing — the same walker already resolves date-macro tokens on the identical node #14105 (345fc33a) and A dashboard widget's OWN filter keys and options.sortBy are not resolved at author time — validate/build exit 0, widget renders empty #14148 (fa1eca31).
• The gap is still open. A probe ran the whole authoring-rule table (runAuthoringRules, both validate and build) over one mutated list view per position, for each of the card's five measured positions. With the new rule present each mutation produced exactly one finding, from this rule; with it filtered out, the only remaining findings were fixture-inherent and unrelated (field/choice-without-options on the fixture's select field, security-owd-unset on the fixture object) — no existing rule reports any of the five. The probe was a throwaway file, deleted before the first commit.
• The two exceptions really do have owners. A bad sort[].field already reports sort-field-unknown; a bad searchableFields[] entry already reports searchable-field-unknown. Both are pinned as non-regression tests here, so this rule cannot start double-reporting them.

Seam reuse

Resolution is resolveFieldPath's and the message half is describeFieldPathVerdict's; the "did you mean" is the seam's suggestName. No second field-resolution implementation and no copied suggestion helper — the existing three-copy problem is carded separately as #14268 and gains no fourth copy here. The three standard skips arrive as the seam's unknowable verdicts (object not in this stack, no readable field map, registry-injected system column), and this surface adds a fourth of its own: a list view whose data.provider is not object binds to no object graph at all.

The dotted-path decision — recorded, not silent

The card (written before the seam existed) suggested skipping dotted paths "as the chart rule already does". The seam can now walk relationship hops, so this needed an explicit call. Decision: judge the HEAD segment; do not walk hops. The reason is what the runtime does, not effort:

• A ListViewSchema declares no ADR-0021 include, so a list view compiles no joins — the declaration that makes hop-walking meaningful at a dataset position has no counterpart here.
• All three query axes a list view reaches refuse a dotted reference by name. Projection: assertProjectionHasNoDottedPaths in packages/objectql/src/engine.ts (verified present on this base) and assertProjectionFieldsExist at the REST ingress. Filter: the dotted-head door. Sort: assertSortFieldsExist's unknown / dotted / unmaterializable ladder.

Walking hops would therefore blessowner.name in a list view's columns — a reference every runtime door refuses — and teach an AI author that a traversal works on a surface where nothing implements it. Judging the head is also what validate-sortable-fields already does on this same surface.

The result is strictly wider than the card's suggestion: ownr.name is reported (a skip would have passed it), and the finding says which segment was judged so the author reads back the string they typed. What stays unreported is a dotted path whose head does resolve — a larger accept-set narrowing whose failure mode is a loud 400 rather than the silent-empty class this card gates. Filed as #14282 rather than folded in, and both halves are pinned in tests so a later change that starts walking hops has to delete a test that states the reason.

Positions covered

Top level: columns[] (bare-string and { field } forms, plus summary.field and prefix.field), filter[] keys, tabs[].filter[] keys, grouping.fields[], rowColor.field, userFilters.fields[], userFilters.tabs[].filter[] keys, filterableFields[], hiddenFields[], fieldOrder[].

Layout blocks: every field binding on kanban, calendar, gantt (including tooltipFields[] and quickFilters[].field), timeline, gallery, map and tree. The rule's POSITIONS table was checked key-by-key against ListViewShapeSchema and each block schema in packages/spec/src/ui/view.zod.ts, so no walked key is a phantom and no field-naming key is missing.

Filter keys go through walkFilterFieldKeys, so all three authored filter shapes are judged rather than one being walked and the others silently skipped.

Deliberately excluded, with reasons

• sort[] and searchableFields[] — owned by validate-sortable-fields (A view's declared sort naming a formula field clears lint, then 400s on every load — the SORT axis has no authoring gate, unlike SEARCH (#6674) #9257) and validate-searchable-fields (A virtual formula field declared in searchableFields clears lint and the #4254 gate, then silently matches nothing — the same fail-open shape #4254 closed one axis over #6674/compiler/validate: view searchableFields not validated against searchable field types — a declaration typo 400s the whole list at runtime #4830), each adding a runtime-admissibility verdict this rule has no business restating.
• chart (dataset / dimensions / values) — dataset, dimension and measure names, not fields on the bound object; owned by validateChartBindings / validateDatasetReferences.
• rowActions / bulkActions / columns[].action — action names, owned by validateActionNameRefs.
• conditionalFormatting[].condition — a CEL predicate, owned by the expression rules.
• pageName / tabs[].view / addRecord.formView — page and view names, owned by validateViewPageRefs and lintViewRefs.
• data.object itself — owned by validateObjectReferences. When the bound object does not resolve, this rule skips the whole list view, so one typo yields one finding rather than one per position (pinned).

Severity — two tiers, the validateFlowTemplatePaths precedent

error where the miss changes what data the view returns or collapses the layout it configures (every position in the card's measured table); warning where the renderer drops one decoration and renders the rest (optional colour/title/tooltip/cover bindings, a stale hiddenFields or fieldOrder entry).

Acceptance — validate AND build, pinned end-to-end

Following the #14148 precedent, the acceptance block drives runAuthoringRules for both commands rather than inferring the answer from the registry entry: each of the card's five measured positions fails validate and fails build, the fully-bound list view passes both, and a warning-tier position advises rather than gates. The rule also joins the reference-integrity suite's view runtime type, so the standalone list view a Studio tenant or an MCP author writes through the per-write publish door is judged too — that crossing is argued in the suite's own granularity-wall test.

Verification

All readings below are from commit 910f9d26b, the branch head this PR opens on.

• pnpm --filter @objectstack/lint test — 91 files, 2660 tests passed.
• pnpm --filter @objectstack/lint run typecheck — clean. Note the package's tsconfig.json excludes *.test.ts, so that run says nothing about the test files; a throwaway config including them was run separately and produced zero errors naming any of the three test files this PR adds or edits (the 22 errors it did report are pre-existing, in seven sibling test files).
• Gate families derived mechanically from the real change set (node scripts/pm/dispatch-gates.mjs, 33 families, harvested with --commands): 30 green, 3 NOT MEASURED because they refuse without inputs this worktree does not have — check-test-completeness (exit 3, needs a saved turbo run test log; the gate documents this branch as the local NOT-MEASURED case), check:dual-build-cjs-loads (exit 3, needs a full workspace build), check:type-check-debt (exit 3, same). check-half-states timed out at 300s making live GitHub calls and is likewise recorded as NOT MEASURED — none of the four is a red, and none is a finding about this diff.
• Also green: check:ratchet-remedy-authority, check:declared-population-live, check:nul-bytes.
• pnpm lint (repo-wide ESLint, eslint . --no-inline-config) — clean, run whole rather than narrowed.

Changeset: minor for @objectstack/lint — an accept-set narrowing, matching the family precedent set by #14105 and #14148.

This branch was recovered rather than restarted: the predecessor dev on this card died in a container restart with its work committed in the worktree but never pushed, so the remote branch read as empty. The recovered commit was re-verified here from the premise up before this PR was opened.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/lint, touching 18 documentable anchor(s). ⚠️1 changed file(s) yielded no anchor (packages/lint/src/index.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

7 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/plugin-endpoints.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/concepts/metadata-lifecycle.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/deployment/validating-metadata.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/kernel/services-checklist.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/protocol/objectui/index.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/forms.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/pages.mdx(via userFilters (symbol, a field of const object POSITIONS))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v12.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/releases/v15.mdx(via userFilters (symbol, a field of const object POSITIONS))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/lint/src/index.ts) — pages documenting those are invisible to this run
• 15 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 5 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from f170075cc7645caf77aa29c0de92270082061b4f — the merge of head 910f9d26bdad38dd06395af1b23a03936dda3277 into base 8125673462b3c0a6d42ef5b002acd4f77c1a9789, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin f170075cc7645caf77aa29c0de92270082061b4f && git checkout f170075cc7645caf77aa29c0de92270082061b4f
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 8125673462b3c0a6d42ef5b002acd4f77c1a9789 910f9d26bdad38dd06395af1b23a03936dda3277 && git checkout -B drift-repro 8125673462b3c0a6d42ef5b002acd4f77c1a9789 && git merge --no-ff 910f9d26bdad38dd06395af1b23a03936dda3277
node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Fixes#14107

A list view names fields in more than forty places and none of them was resolved against the bound object — not by os validate, and not by os build, which is the publish gate. This adds one rule, list-view-field-unknown (validateListViewFieldRefs), over every one of those positions, resolving through the shared object-graph seam that #14105 and #14148 landed.

Premise re-check on today's origin/main

Re-measured on this branch's merge base (0fb3044f6), not inferred from the card:

• The seam exists and is exported.indexObjectGraph, resolveFieldPath, describeFieldPathVerdict, isUnjudgeable, suggestName and listNames are all public from packages/lint/src/object-graph.ts, whose own docblock already names this card as its third consumer. Both family landings are in the base — objectstack validate and build accept a dataset whose base object, include path and dimension/measure field paths all name nothing — the same walker already resolves date-macro tokens on the identical node #14105 (345fc33a) and A dashboard widget's OWN filter keys and options.sortBy are not resolved at author time — validate/build exit 0, widget renders empty #14148 (fa1eca31).
• The gap is still open. A probe ran the whole authoring-rule table (runAuthoringRules, both validate and build) over one mutated list view per position, for each of the card's five measured positions. With the new rule present each mutation produced exactly one finding, from this rule; with it filtered out, the only remaining findings were fixture-inherent and unrelated (field/choice-without-options on the fixture's select field, security-owd-unset on the fixture object) — no existing rule reports any of the five. The probe was a throwaway file, deleted before the first commit.
• The two exceptions really do have owners. A bad sort[].field already reports sort-field-unknown; a bad searchableFields[] entry already reports searchable-field-unknown. Both are pinned as non-regression tests here, so this rule cannot start double-reporting them.

Seam reuse

Resolution is resolveFieldPath's and the message half is describeFieldPathVerdict's; the "did you mean" is the seam's suggestName. No second field-resolution implementation and no copied suggestion helper — the existing three-copy problem is carded separately as #14268 and gains no fourth copy here. The three standard skips arrive as the seam's unknowable verdicts (object not in this stack, no readable field map, registry-injected system column), and this surface adds a fourth of its own: a list view whose data.provider is not object binds to no object graph at all.

The dotted-path decision — recorded, not silent

The card (written before the seam existed) suggested skipping dotted paths "as the chart rule already does". The seam can now walk relationship hops, so this needed an explicit call. Decision: judge the HEAD segment; do not walk hops. The reason is what the runtime does, not effort:

• A ListViewSchema declares no ADR-0021 include, so a list view compiles no joins — the declaration that makes hop-walking meaningful at a dataset position has no counterpart here.
• All three query axes a list view reaches refuse a dotted reference by name. Projection: assertProjectionHasNoDottedPaths in packages/objectql/src/engine.ts (verified present on this base) and assertProjectionFieldsExist at the REST ingress. Filter: the dotted-head door. Sort: assertSortFieldsExist's unknown / dotted / unmaterializable ladder.

Walking hops would therefore blessowner.name in a list view's columns — a reference every runtime door refuses — and teach an AI author that a traversal works on a surface where nothing implements it. Judging the head is also what validate-sortable-fields already does on this same surface.

The result is strictly wider than the card's suggestion: ownr.name is reported (a skip would have passed it), and the finding says which segment was judged so the author reads back the string they typed. What stays unreported is a dotted path whose head does resolve — a larger accept-set narrowing whose failure mode is a loud 400 rather than the silent-empty class this card gates. Filed as #14282 rather than folded in, and both halves are pinned in tests so a later change that starts walking hops has to delete a test that states the reason.

Positions covered

Top level: columns[] (bare-string and { field } forms, plus summary.field and prefix.field), filter[] keys, tabs[].filter[] keys, grouping.fields[], rowColor.field, userFilters.fields[], userFilters.tabs[].filter[] keys, filterableFields[], hiddenFields[], fieldOrder[].

Layout blocks: every field binding on kanban, calendar, gantt (including tooltipFields[] and quickFilters[].field), timeline, gallery, map and tree. The rule's POSITIONS table was checked key-by-key against ListViewShapeSchema and each block schema in packages/spec/src/ui/view.zod.ts, so no walked key is a phantom and no field-naming key is missing.

Filter keys go through walkFilterFieldKeys, so all three authored filter shapes are judged rather than one being walked and the others silently skipped.

Deliberately excluded, with reasons

• sort[] and searchableFields[] — owned by validate-sortable-fields (A view's declared sort naming a formula field clears lint, then 400s on every load — the SORT axis has no authoring gate, unlike SEARCH (#6674) #9257) and validate-searchable-fields (A virtual formula field declared in searchableFields clears lint and the #4254 gate, then silently matches nothing — the same fail-open shape #4254 closed one axis over #6674/compiler/validate: view searchableFields not validated against searchable field types — a declaration typo 400s the whole list at runtime #4830), each adding a runtime-admissibility verdict this rule has no business restating.
• chart (dataset / dimensions / values) — dataset, dimension and measure names, not fields on the bound object; owned by validateChartBindings / validateDatasetReferences.
• rowActions / bulkActions / columns[].action — action names, owned by validateActionNameRefs.
• conditionalFormatting[].condition — a CEL predicate, owned by the expression rules.
• pageName / tabs[].view / addRecord.formView — page and view names, owned by validateViewPageRefs and lintViewRefs.
• data.object itself — owned by validateObjectReferences. When the bound object does not resolve, this rule skips the whole list view, so one typo yields one finding rather than one per position (pinned).

Severity — two tiers, the validateFlowTemplatePaths precedent

error where the miss changes what data the view returns or collapses the layout it configures (every position in the card's measured table); warning where the renderer drops one decoration and renders the rest (optional colour/title/tooltip/cover bindings, a stale hiddenFields or fieldOrder entry).

Acceptance — validate AND build, pinned end-to-end

Following the #14148 precedent, the acceptance block drives runAuthoringRules for both commands rather than inferring the answer from the registry entry: each of the card's five measured positions fails validate and fails build, the fully-bound list view passes both, and a warning-tier position advises rather than gates. The rule also joins the reference-integrity suite's view runtime type, so the standalone list view a Studio tenant or an MCP author writes through the per-write publish door is judged too — that crossing is argued in the suite's own granularity-wall test.

Verification

All readings below are from commit 910f9d26b, the branch head this PR opens on.

• pnpm --filter @objectstack/lint test — 91 files, 2660 tests passed.
• pnpm --filter @objectstack/lint run typecheck — clean. Note the package's tsconfig.json excludes *.test.ts, so that run says nothing about the test files; a throwaway config including them was run separately and produced zero errors naming any of the three test files this PR adds or edits (the 22 errors it did report are pre-existing, in seven sibling test files).
• Gate families derived mechanically from the real change set (node scripts/pm/dispatch-gates.mjs, 33 families, harvested with --commands): 30 green, 3 NOT MEASURED because they refuse without inputs this worktree does not have — check-test-completeness (exit 3, needs a saved turbo run test log; the gate documents this branch as the local NOT-MEASURED case), check:dual-build-cjs-loads (exit 3, needs a full workspace build), check:type-check-debt (exit 3, same). check-half-states timed out at 300s making live GitHub calls and is likewise recorded as NOT MEASURED — none of the four is a red, and none is a finding about this diff.
• Also green: check:ratchet-remedy-authority, check:declared-population-live, check:nul-bytes.
• pnpm lint (repo-wide ESLint, eslint . --no-inline-config) — clean, run whole rather than narrowed.

Changeset: minor for @objectstack/lint — an accept-set narrowing, matching the family precedent set by #14105 and #14148.

This branch was recovered rather than restarted: the predecessor dev on this card died in a container restart with its work committed in the worktree but never pushed, so the remote branch read as empty. The recovered commit was re-verified here from the premise up before this PR was opened.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/lint, touching 18 documentable anchor(s). ⚠️1 changed file(s) yielded no anchor (packages/lint/src/index.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

7 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/plugin-endpoints.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/concepts/metadata-lifecycle.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/deployment/validating-metadata.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/kernel/services-checklist.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/protocol/objectui/index.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/forms.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/pages.mdx(via userFilters (symbol, a field of const object POSITIONS))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v12.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/releases/v15.mdx(via userFilters (symbol, a field of const object POSITIONS))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/lint/src/index.ts) — pages documenting those are invisible to this run
• 15 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 5 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from f170075cc7645caf77aa29c0de92270082061b4f — the merge of head 910f9d26bdad38dd06395af1b23a03936dda3277 into base 8125673462b3c0a6d42ef5b002acd4f77c1a9789, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin f170075cc7645caf77aa29c0de92270082061b4f && git checkout f170075cc7645caf77aa29c0de92270082061b4f
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 8125673462b3c0a6d42ef5b002acd4f77c1a9789 910f9d26bdad38dd06395af1b23a03936dda3277 && git checkout -B drift-repro 8125673462b3c0a6d42ef5b002acd4f77c1a9789 && git merge --no-ff 910f9d26bdad38dd06395af1b23a03936dda3277
node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Fixes#14107

A list view names fields in more than forty places and none of them was resolved against the bound object — not by os validate, and not by os build, which is the publish gate. This adds one rule, list-view-field-unknown (validateListViewFieldRefs), over every one of those positions, resolving through the shared object-graph seam that #14105 and #14148 landed.

Premise re-check on today's origin/main

Re-measured on this branch's merge base (0fb3044f6), not inferred from the card:

• The seam exists and is exported.indexObjectGraph, resolveFieldPath, describeFieldPathVerdict, isUnjudgeable, suggestName and listNames are all public from packages/lint/src/object-graph.ts, whose own docblock already names this card as its third consumer. Both family landings are in the base — objectstack validate and build accept a dataset whose base object, include path and dimension/measure field paths all name nothing — the same walker already resolves date-macro tokens on the identical node #14105 (345fc33a) and A dashboard widget's OWN filter keys and options.sortBy are not resolved at author time — validate/build exit 0, widget renders empty #14148 (fa1eca31).
• The gap is still open. A probe ran the whole authoring-rule table (runAuthoringRules, both validate and build) over one mutated list view per position, for each of the card's five measured positions. With the new rule present each mutation produced exactly one finding, from this rule; with it filtered out, the only remaining findings were fixture-inherent and unrelated (field/choice-without-options on the fixture's select field, security-owd-unset on the fixture object) — no existing rule reports any of the five. The probe was a throwaway file, deleted before the first commit.
• The two exceptions really do have owners. A bad sort[].field already reports sort-field-unknown; a bad searchableFields[] entry already reports searchable-field-unknown. Both are pinned as non-regression tests here, so this rule cannot start double-reporting them.

Seam reuse

Resolution is resolveFieldPath's and the message half is describeFieldPathVerdict's; the "did you mean" is the seam's suggestName. No second field-resolution implementation and no copied suggestion helper — the existing three-copy problem is carded separately as #14268 and gains no fourth copy here. The three standard skips arrive as the seam's unknowable verdicts (object not in this stack, no readable field map, registry-injected system column), and this surface adds a fourth of its own: a list view whose data.provider is not object binds to no object graph at all.

The dotted-path decision — recorded, not silent

The card (written before the seam existed) suggested skipping dotted paths "as the chart rule already does". The seam can now walk relationship hops, so this needed an explicit call. Decision: judge the HEAD segment; do not walk hops. The reason is what the runtime does, not effort:

• A ListViewSchema declares no ADR-0021 include, so a list view compiles no joins — the declaration that makes hop-walking meaningful at a dataset position has no counterpart here.
• All three query axes a list view reaches refuse a dotted reference by name. Projection: assertProjectionHasNoDottedPaths in packages/objectql/src/engine.ts (verified present on this base) and assertProjectionFieldsExist at the REST ingress. Filter: the dotted-head door. Sort: assertSortFieldsExist's unknown / dotted / unmaterializable ladder.

Walking hops would therefore blessowner.name in a list view's columns — a reference every runtime door refuses — and teach an AI author that a traversal works on a surface where nothing implements it. Judging the head is also what validate-sortable-fields already does on this same surface.

The result is strictly wider than the card's suggestion: ownr.name is reported (a skip would have passed it), and the finding says which segment was judged so the author reads back the string they typed. What stays unreported is a dotted path whose head does resolve — a larger accept-set narrowing whose failure mode is a loud 400 rather than the silent-empty class this card gates. Filed as #14282 rather than folded in, and both halves are pinned in tests so a later change that starts walking hops has to delete a test that states the reason.

Positions covered

Top level: columns[] (bare-string and { field } forms, plus summary.field and prefix.field), filter[] keys, tabs[].filter[] keys, grouping.fields[], rowColor.field, userFilters.fields[], userFilters.tabs[].filter[] keys, filterableFields[], hiddenFields[], fieldOrder[].

Layout blocks: every field binding on kanban, calendar, gantt (including tooltipFields[] and quickFilters[].field), timeline, gallery, map and tree. The rule's POSITIONS table was checked key-by-key against ListViewShapeSchema and each block schema in packages/spec/src/ui/view.zod.ts, so no walked key is a phantom and no field-naming key is missing.

Filter keys go through walkFilterFieldKeys, so all three authored filter shapes are judged rather than one being walked and the others silently skipped.

Deliberately excluded, with reasons

• sort[] and searchableFields[] — owned by validate-sortable-fields (A view's declared sort naming a formula field clears lint, then 400s on every load — the SORT axis has no authoring gate, unlike SEARCH (#6674) #9257) and validate-searchable-fields (A virtual formula field declared in searchableFields clears lint and the #4254 gate, then silently matches nothing — the same fail-open shape #4254 closed one axis over #6674/compiler/validate: view searchableFields not validated against searchable field types — a declaration typo 400s the whole list at runtime #4830), each adding a runtime-admissibility verdict this rule has no business restating.
• chart (dataset / dimensions / values) — dataset, dimension and measure names, not fields on the bound object; owned by validateChartBindings / validateDatasetReferences.
• rowActions / bulkActions / columns[].action — action names, owned by validateActionNameRefs.
• conditionalFormatting[].condition — a CEL predicate, owned by the expression rules.
• pageName / tabs[].view / addRecord.formView — page and view names, owned by validateViewPageRefs and lintViewRefs.
• data.object itself — owned by validateObjectReferences. When the bound object does not resolve, this rule skips the whole list view, so one typo yields one finding rather than one per position (pinned).

Severity — two tiers, the validateFlowTemplatePaths precedent

error where the miss changes what data the view returns or collapses the layout it configures (every position in the card's measured table); warning where the renderer drops one decoration and renders the rest (optional colour/title/tooltip/cover bindings, a stale hiddenFields or fieldOrder entry).

Acceptance — validate AND build, pinned end-to-end

Following the #14148 precedent, the acceptance block drives runAuthoringRules for both commands rather than inferring the answer from the registry entry: each of the card's five measured positions fails validate and fails build, the fully-bound list view passes both, and a warning-tier position advises rather than gates. The rule also joins the reference-integrity suite's view runtime type, so the standalone list view a Studio tenant or an MCP author writes through the per-write publish door is judged too — that crossing is argued in the suite's own granularity-wall test.

Verification

All readings below are from commit 910f9d26b, the branch head this PR opens on.

• pnpm --filter @objectstack/lint test — 91 files, 2660 tests passed.
• pnpm --filter @objectstack/lint run typecheck — clean. Note the package's tsconfig.json excludes *.test.ts, so that run says nothing about the test files; a throwaway config including them was run separately and produced zero errors naming any of the three test files this PR adds or edits (the 22 errors it did report are pre-existing, in seven sibling test files).
• Gate families derived mechanically from the real change set (node scripts/pm/dispatch-gates.mjs, 33 families, harvested with --commands): 30 green, 3 NOT MEASURED because they refuse without inputs this worktree does not have — check-test-completeness (exit 3, needs a saved turbo run test log; the gate documents this branch as the local NOT-MEASURED case), check:dual-build-cjs-loads (exit 3, needs a full workspace build), check:type-check-debt (exit 3, same). check-half-states timed out at 300s making live GitHub calls and is likewise recorded as NOT MEASURED — none of the four is a red, and none is a finding about this diff.
• Also green: check:ratchet-remedy-authority, check:declared-population-live, check:nul-bytes.
• pnpm lint (repo-wide ESLint, eslint . --no-inline-config) — clean, run whole rather than narrowed.

Changeset: minor for @objectstack/lint — an accept-set narrowing, matching the family precedent set by #14105 and #14148.

This branch was recovered rather than restarted: the predecessor dev on this card died in a container restart with its work committed in the worktree but never pushed, so the remote branch read as empty. The recovered commit was re-verified here from the premise up before this PR was opened.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/lint, touching 18 documentable anchor(s). ⚠️1 changed file(s) yielded no anchor (packages/lint/src/index.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

7 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/plugin-endpoints.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/concepts/metadata-lifecycle.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/deployment/validating-metadata.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/kernel/services-checklist.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/protocol/objectui/index.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/forms.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/pages.mdx(via userFilters (symbol, a field of const object POSITIONS))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v12.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/releases/v15.mdx(via userFilters (symbol, a field of const object POSITIONS))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/lint/src/index.ts) — pages documenting those are invisible to this run
• 15 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 5 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from f170075cc7645caf77aa29c0de92270082061b4f — the merge of head 910f9d26bdad38dd06395af1b23a03936dda3277 into base 8125673462b3c0a6d42ef5b002acd4f77c1a9789, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin f170075cc7645caf77aa29c0de92270082061b4f && git checkout f170075cc7645caf77aa29c0de92270082061b4f
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 8125673462b3c0a6d42ef5b002acd4f77c1a9789 910f9d26bdad38dd06395af1b23a03936dda3277 && git checkout -B drift-repro 8125673462b3c0a6d42ef5b002acd4f77c1a9789 && git merge --no-ff 910f9d26bdad38dd06395af1b23a03936dda3277
node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Fixes#14107

A list view names fields in more than forty places and none of them was resolved against the bound object — not by os validate, and not by os build, which is the publish gate. This adds one rule, list-view-field-unknown (validateListViewFieldRefs), over every one of those positions, resolving through the shared object-graph seam that #14105 and #14148 landed.

Premise re-check on today's origin/main

Re-measured on this branch's merge base (0fb3044f6), not inferred from the card:

• The seam exists and is exported.indexObjectGraph, resolveFieldPath, describeFieldPathVerdict, isUnjudgeable, suggestName and listNames are all public from packages/lint/src/object-graph.ts, whose own docblock already names this card as its third consumer. Both family landings are in the base — objectstack validate and build accept a dataset whose base object, include path and dimension/measure field paths all name nothing — the same walker already resolves date-macro tokens on the identical node #14105 (345fc33a) and A dashboard widget's OWN filter keys and options.sortBy are not resolved at author time — validate/build exit 0, widget renders empty #14148 (fa1eca31).
• The gap is still open. A probe ran the whole authoring-rule table (runAuthoringRules, both validate and build) over one mutated list view per position, for each of the card's five measured positions. With the new rule present each mutation produced exactly one finding, from this rule; with it filtered out, the only remaining findings were fixture-inherent and unrelated (field/choice-without-options on the fixture's select field, security-owd-unset on the fixture object) — no existing rule reports any of the five. The probe was a throwaway file, deleted before the first commit.
• The two exceptions really do have owners. A bad sort[].field already reports sort-field-unknown; a bad searchableFields[] entry already reports searchable-field-unknown. Both are pinned as non-regression tests here, so this rule cannot start double-reporting them.

Seam reuse

Resolution is resolveFieldPath's and the message half is describeFieldPathVerdict's; the "did you mean" is the seam's suggestName. No second field-resolution implementation and no copied suggestion helper — the existing three-copy problem is carded separately as #14268 and gains no fourth copy here. The three standard skips arrive as the seam's unknowable verdicts (object not in this stack, no readable field map, registry-injected system column), and this surface adds a fourth of its own: a list view whose data.provider is not object binds to no object graph at all.

The dotted-path decision — recorded, not silent

The card (written before the seam existed) suggested skipping dotted paths "as the chart rule already does". The seam can now walk relationship hops, so this needed an explicit call. Decision: judge the HEAD segment; do not walk hops. The reason is what the runtime does, not effort:

• A ListViewSchema declares no ADR-0021 include, so a list view compiles no joins — the declaration that makes hop-walking meaningful at a dataset position has no counterpart here.
• All three query axes a list view reaches refuse a dotted reference by name. Projection: assertProjectionHasNoDottedPaths in packages/objectql/src/engine.ts (verified present on this base) and assertProjectionFieldsExist at the REST ingress. Filter: the dotted-head door. Sort: assertSortFieldsExist's unknown / dotted / unmaterializable ladder.

Walking hops would therefore blessowner.name in a list view's columns — a reference every runtime door refuses — and teach an AI author that a traversal works on a surface where nothing implements it. Judging the head is also what validate-sortable-fields already does on this same surface.

The result is strictly wider than the card's suggestion: ownr.name is reported (a skip would have passed it), and the finding says which segment was judged so the author reads back the string they typed. What stays unreported is a dotted path whose head does resolve — a larger accept-set narrowing whose failure mode is a loud 400 rather than the silent-empty class this card gates. Filed as #14282 rather than folded in, and both halves are pinned in tests so a later change that starts walking hops has to delete a test that states the reason.

Positions covered

Top level: columns[] (bare-string and { field } forms, plus summary.field and prefix.field), filter[] keys, tabs[].filter[] keys, grouping.fields[], rowColor.field, userFilters.fields[], userFilters.tabs[].filter[] keys, filterableFields[], hiddenFields[], fieldOrder[].

Layout blocks: every field binding on kanban, calendar, gantt (including tooltipFields[] and quickFilters[].field), timeline, gallery, map and tree. The rule's POSITIONS table was checked key-by-key against ListViewShapeSchema and each block schema in packages/spec/src/ui/view.zod.ts, so no walked key is a phantom and no field-naming key is missing.

Filter keys go through walkFilterFieldKeys, so all three authored filter shapes are judged rather than one being walked and the others silently skipped.

Deliberately excluded, with reasons

• sort[] and searchableFields[] — owned by validate-sortable-fields (A view's declared sort naming a formula field clears lint, then 400s on every load — the SORT axis has no authoring gate, unlike SEARCH (#6674) #9257) and validate-searchable-fields (A virtual formula field declared in searchableFields clears lint and the #4254 gate, then silently matches nothing — the same fail-open shape #4254 closed one axis over #6674/compiler/validate: view searchableFields not validated against searchable field types — a declaration typo 400s the whole list at runtime #4830), each adding a runtime-admissibility verdict this rule has no business restating.
• chart (dataset / dimensions / values) — dataset, dimension and measure names, not fields on the bound object; owned by validateChartBindings / validateDatasetReferences.
• rowActions / bulkActions / columns[].action — action names, owned by validateActionNameRefs.
• conditionalFormatting[].condition — a CEL predicate, owned by the expression rules.
• pageName / tabs[].view / addRecord.formView — page and view names, owned by validateViewPageRefs and lintViewRefs.
• data.object itself — owned by validateObjectReferences. When the bound object does not resolve, this rule skips the whole list view, so one typo yields one finding rather than one per position (pinned).

Severity — two tiers, the validateFlowTemplatePaths precedent

error where the miss changes what data the view returns or collapses the layout it configures (every position in the card's measured table); warning where the renderer drops one decoration and renders the rest (optional colour/title/tooltip/cover bindings, a stale hiddenFields or fieldOrder entry).

Acceptance — validate AND build, pinned end-to-end

Following the #14148 precedent, the acceptance block drives runAuthoringRules for both commands rather than inferring the answer from the registry entry: each of the card's five measured positions fails validate and fails build, the fully-bound list view passes both, and a warning-tier position advises rather than gates. The rule also joins the reference-integrity suite's view runtime type, so the standalone list view a Studio tenant or an MCP author writes through the per-write publish door is judged too — that crossing is argued in the suite's own granularity-wall test.

Verification

All readings below are from commit 910f9d26b, the branch head this PR opens on.

• pnpm --filter @objectstack/lint test — 91 files, 2660 tests passed.
• pnpm --filter @objectstack/lint run typecheck — clean. Note the package's tsconfig.json excludes *.test.ts, so that run says nothing about the test files; a throwaway config including them was run separately and produced zero errors naming any of the three test files this PR adds or edits (the 22 errors it did report are pre-existing, in seven sibling test files).
• Gate families derived mechanically from the real change set (node scripts/pm/dispatch-gates.mjs, 33 families, harvested with --commands): 30 green, 3 NOT MEASURED because they refuse without inputs this worktree does not have — check-test-completeness (exit 3, needs a saved turbo run test log; the gate documents this branch as the local NOT-MEASURED case), check:dual-build-cjs-loads (exit 3, needs a full workspace build), check:type-check-debt (exit 3, same). check-half-states timed out at 300s making live GitHub calls and is likewise recorded as NOT MEASURED — none of the four is a red, and none is a finding about this diff.
• Also green: check:ratchet-remedy-authority, check:declared-population-live, check:nul-bytes.
• pnpm lint (repo-wide ESLint, eslint . --no-inline-config) — clean, run whole rather than narrowed.

Changeset: minor for @objectstack/lint — an accept-set narrowing, matching the family precedent set by #14105 and #14148.

This branch was recovered rather than restarted: the predecessor dev on this card died in a container restart with its work committed in the worktree but never pushed, so the remote branch read as empty. The recovered commit was re-verified here from the premise up before this PR was opened.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/lint, touching 18 documentable anchor(s). ⚠️1 changed file(s) yielded no anchor (packages/lint/src/index.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

7 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/plugin-endpoints.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/concepts/metadata-lifecycle.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/deployment/validating-metadata.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/kernel/services-checklist.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/protocol/objectui/index.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/forms.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/pages.mdx(via userFilters (symbol, a field of const object POSITIONS))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v12.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/releases/v15.mdx(via userFilters (symbol, a field of const object POSITIONS))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/lint/src/index.ts) — pages documenting those are invisible to this run
• 15 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 5 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from f170075cc7645caf77aa29c0de92270082061b4f — the merge of head 910f9d26bdad38dd06395af1b23a03936dda3277 into base 8125673462b3c0a6d42ef5b002acd4f77c1a9789, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin f170075cc7645caf77aa29c0de92270082061b4f && git checkout f170075cc7645caf77aa29c0de92270082061b4f
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 8125673462b3c0a6d42ef5b002acd4f77c1a9789 910f9d26bdad38dd06395af1b23a03936dda3277 && git checkout -B drift-repro 8125673462b3c0a6d42ef5b002acd4f77c1a9789 && git merge --no-ff 910f9d26bdad38dd06395af1b23a03936dda3277
node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Fixes#14107

A list view names fields in more than forty places and none of them was resolved against the bound object — not by os validate, and not by os build, which is the publish gate. This adds one rule, list-view-field-unknown (validateListViewFieldRefs), over every one of those positions, resolving through the shared object-graph seam that #14105 and #14148 landed.

Premise re-check on today's origin/main

Re-measured on this branch's merge base (0fb3044f6), not inferred from the card:

• The seam exists and is exported.indexObjectGraph, resolveFieldPath, describeFieldPathVerdict, isUnjudgeable, suggestName and listNames are all public from packages/lint/src/object-graph.ts, whose own docblock already names this card as its third consumer. Both family landings are in the base — objectstack validate and build accept a dataset whose base object, include path and dimension/measure field paths all name nothing — the same walker already resolves date-macro tokens on the identical node #14105 (345fc33a) and A dashboard widget's OWN filter keys and options.sortBy are not resolved at author time — validate/build exit 0, widget renders empty #14148 (fa1eca31).
• The gap is still open. A probe ran the whole authoring-rule table (runAuthoringRules, both validate and build) over one mutated list view per position, for each of the card's five measured positions. With the new rule present each mutation produced exactly one finding, from this rule; with it filtered out, the only remaining findings were fixture-inherent and unrelated (field/choice-without-options on the fixture's select field, security-owd-unset on the fixture object) — no existing rule reports any of the five. The probe was a throwaway file, deleted before the first commit.
• The two exceptions really do have owners. A bad sort[].field already reports sort-field-unknown; a bad searchableFields[] entry already reports searchable-field-unknown. Both are pinned as non-regression tests here, so this rule cannot start double-reporting them.

Seam reuse

Resolution is resolveFieldPath's and the message half is describeFieldPathVerdict's; the "did you mean" is the seam's suggestName. No second field-resolution implementation and no copied suggestion helper — the existing three-copy problem is carded separately as #14268 and gains no fourth copy here. The three standard skips arrive as the seam's unknowable verdicts (object not in this stack, no readable field map, registry-injected system column), and this surface adds a fourth of its own: a list view whose data.provider is not object binds to no object graph at all.

The dotted-path decision — recorded, not silent

The card (written before the seam existed) suggested skipping dotted paths "as the chart rule already does". The seam can now walk relationship hops, so this needed an explicit call. Decision: judge the HEAD segment; do not walk hops. The reason is what the runtime does, not effort:

• A ListViewSchema declares no ADR-0021 include, so a list view compiles no joins — the declaration that makes hop-walking meaningful at a dataset position has no counterpart here.
• All three query axes a list view reaches refuse a dotted reference by name. Projection: assertProjectionHasNoDottedPaths in packages/objectql/src/engine.ts (verified present on this base) and assertProjectionFieldsExist at the REST ingress. Filter: the dotted-head door. Sort: assertSortFieldsExist's unknown / dotted / unmaterializable ladder.

Walking hops would therefore blessowner.name in a list view's columns — a reference every runtime door refuses — and teach an AI author that a traversal works on a surface where nothing implements it. Judging the head is also what validate-sortable-fields already does on this same surface.

The result is strictly wider than the card's suggestion: ownr.name is reported (a skip would have passed it), and the finding says which segment was judged so the author reads back the string they typed. What stays unreported is a dotted path whose head does resolve — a larger accept-set narrowing whose failure mode is a loud 400 rather than the silent-empty class this card gates. Filed as #14282 rather than folded in, and both halves are pinned in tests so a later change that starts walking hops has to delete a test that states the reason.

Positions covered

Top level: columns[] (bare-string and { field } forms, plus summary.field and prefix.field), filter[] keys, tabs[].filter[] keys, grouping.fields[], rowColor.field, userFilters.fields[], userFilters.tabs[].filter[] keys, filterableFields[], hiddenFields[], fieldOrder[].

Layout blocks: every field binding on kanban, calendar, gantt (including tooltipFields[] and quickFilters[].field), timeline, gallery, map and tree. The rule's POSITIONS table was checked key-by-key against ListViewShapeSchema and each block schema in packages/spec/src/ui/view.zod.ts, so no walked key is a phantom and no field-naming key is missing.

Filter keys go through walkFilterFieldKeys, so all three authored filter shapes are judged rather than one being walked and the others silently skipped.

Deliberately excluded, with reasons

• sort[] and searchableFields[] — owned by validate-sortable-fields (A view's declared sort naming a formula field clears lint, then 400s on every load — the SORT axis has no authoring gate, unlike SEARCH (#6674) #9257) and validate-searchable-fields (A virtual formula field declared in searchableFields clears lint and the #4254 gate, then silently matches nothing — the same fail-open shape #4254 closed one axis over #6674/compiler/validate: view searchableFields not validated against searchable field types — a declaration typo 400s the whole list at runtime #4830), each adding a runtime-admissibility verdict this rule has no business restating.
• chart (dataset / dimensions / values) — dataset, dimension and measure names, not fields on the bound object; owned by validateChartBindings / validateDatasetReferences.
• rowActions / bulkActions / columns[].action — action names, owned by validateActionNameRefs.
• conditionalFormatting[].condition — a CEL predicate, owned by the expression rules.
• pageName / tabs[].view / addRecord.formView — page and view names, owned by validateViewPageRefs and lintViewRefs.
• data.object itself — owned by validateObjectReferences. When the bound object does not resolve, this rule skips the whole list view, so one typo yields one finding rather than one per position (pinned).

Severity — two tiers, the validateFlowTemplatePaths precedent

error where the miss changes what data the view returns or collapses the layout it configures (every position in the card's measured table); warning where the renderer drops one decoration and renders the rest (optional colour/title/tooltip/cover bindings, a stale hiddenFields or fieldOrder entry).

Acceptance — validate AND build, pinned end-to-end

Following the #14148 precedent, the acceptance block drives runAuthoringRules for both commands rather than inferring the answer from the registry entry: each of the card's five measured positions fails validate and fails build, the fully-bound list view passes both, and a warning-tier position advises rather than gates. The rule also joins the reference-integrity suite's view runtime type, so the standalone list view a Studio tenant or an MCP author writes through the per-write publish door is judged too — that crossing is argued in the suite's own granularity-wall test.

Verification

All readings below are from commit 910f9d26b, the branch head this PR opens on.

• pnpm --filter @objectstack/lint test — 91 files, 2660 tests passed.
• pnpm --filter @objectstack/lint run typecheck — clean. Note the package's tsconfig.json excludes *.test.ts, so that run says nothing about the test files; a throwaway config including them was run separately and produced zero errors naming any of the three test files this PR adds or edits (the 22 errors it did report are pre-existing, in seven sibling test files).
• Gate families derived mechanically from the real change set (node scripts/pm/dispatch-gates.mjs, 33 families, harvested with --commands): 30 green, 3 NOT MEASURED because they refuse without inputs this worktree does not have — check-test-completeness (exit 3, needs a saved turbo run test log; the gate documents this branch as the local NOT-MEASURED case), check:dual-build-cjs-loads (exit 3, needs a full workspace build), check:type-check-debt (exit 3, same). check-half-states timed out at 300s making live GitHub calls and is likewise recorded as NOT MEASURED — none of the four is a red, and none is a finding about this diff.
• Also green: check:ratchet-remedy-authority, check:declared-population-live, check:nul-bytes.
• pnpm lint (repo-wide ESLint, eslint . --no-inline-config) — clean, run whole rather than narrowed.

Changeset: minor for @objectstack/lint — an accept-set narrowing, matching the family precedent set by #14105 and #14148.

This branch was recovered rather than restarted: the predecessor dev on this card died in a container restart with its work committed in the worktree but never pushed, so the remote branch read as empty. The recovered commit was re-verified here from the premise up before this PR was opened.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/lint, touching 18 documentable anchor(s). ⚠️1 changed file(s) yielded no anchor (packages/lint/src/index.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

7 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/plugin-endpoints.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/concepts/metadata-lifecycle.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/deployment/validating-metadata.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/kernel/services-checklist.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/protocol/objectui/index.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/forms.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/pages.mdx(via userFilters (symbol, a field of const object POSITIONS))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v12.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/releases/v15.mdx(via userFilters (symbol, a field of const object POSITIONS))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/lint/src/index.ts) — pages documenting those are invisible to this run
• 15 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 5 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from f170075cc7645caf77aa29c0de92270082061b4f — the merge of head 910f9d26bdad38dd06395af1b23a03936dda3277 into base 8125673462b3c0a6d42ef5b002acd4f77c1a9789, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin f170075cc7645caf77aa29c0de92270082061b4f && git checkout f170075cc7645caf77aa29c0de92270082061b4f
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 8125673462b3c0a6d42ef5b002acd4f77c1a9789 910f9d26bdad38dd06395af1b23a03936dda3277 && git checkout -B drift-repro 8125673462b3c0a6d42ef5b002acd4f77c1a9789 && git merge --no-ff 910f9d26bdad38dd06395af1b23a03936dda3277
node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Fixes#14107

A list view names fields in more than forty places and none of them was resolved against the bound object — not by os validate, and not by os build, which is the publish gate. This adds one rule, list-view-field-unknown (validateListViewFieldRefs), over every one of those positions, resolving through the shared object-graph seam that #14105 and #14148 landed.

Premise re-check on today's origin/main

Re-measured on this branch's merge base (0fb3044f6), not inferred from the card:

• The seam exists and is exported.indexObjectGraph, resolveFieldPath, describeFieldPathVerdict, isUnjudgeable, suggestName and listNames are all public from packages/lint/src/object-graph.ts, whose own docblock already names this card as its third consumer. Both family landings are in the base — objectstack validate and build accept a dataset whose base object, include path and dimension/measure field paths all name nothing — the same walker already resolves date-macro tokens on the identical node #14105 (345fc33a) and A dashboard widget's OWN filter keys and options.sortBy are not resolved at author time — validate/build exit 0, widget renders empty #14148 (fa1eca31).
• The gap is still open. A probe ran the whole authoring-rule table (runAuthoringRules, both validate and build) over one mutated list view per position, for each of the card's five measured positions. With the new rule present each mutation produced exactly one finding, from this rule; with it filtered out, the only remaining findings were fixture-inherent and unrelated (field/choice-without-options on the fixture's select field, security-owd-unset on the fixture object) — no existing rule reports any of the five. The probe was a throwaway file, deleted before the first commit.
• The two exceptions really do have owners. A bad sort[].field already reports sort-field-unknown; a bad searchableFields[] entry already reports searchable-field-unknown. Both are pinned as non-regression tests here, so this rule cannot start double-reporting them.

Seam reuse

Resolution is resolveFieldPath's and the message half is describeFieldPathVerdict's; the "did you mean" is the seam's suggestName. No second field-resolution implementation and no copied suggestion helper — the existing three-copy problem is carded separately as #14268 and gains no fourth copy here. The three standard skips arrive as the seam's unknowable verdicts (object not in this stack, no readable field map, registry-injected system column), and this surface adds a fourth of its own: a list view whose data.provider is not object binds to no object graph at all.

The dotted-path decision — recorded, not silent

The card (written before the seam existed) suggested skipping dotted paths "as the chart rule already does". The seam can now walk relationship hops, so this needed an explicit call. Decision: judge the HEAD segment; do not walk hops. The reason is what the runtime does, not effort:

• A ListViewSchema declares no ADR-0021 include, so a list view compiles no joins — the declaration that makes hop-walking meaningful at a dataset position has no counterpart here.
• All three query axes a list view reaches refuse a dotted reference by name. Projection: assertProjectionHasNoDottedPaths in packages/objectql/src/engine.ts (verified present on this base) and assertProjectionFieldsExist at the REST ingress. Filter: the dotted-head door. Sort: assertSortFieldsExist's unknown / dotted / unmaterializable ladder.

Walking hops would therefore blessowner.name in a list view's columns — a reference every runtime door refuses — and teach an AI author that a traversal works on a surface where nothing implements it. Judging the head is also what validate-sortable-fields already does on this same surface.

The result is strictly wider than the card's suggestion: ownr.name is reported (a skip would have passed it), and the finding says which segment was judged so the author reads back the string they typed. What stays unreported is a dotted path whose head does resolve — a larger accept-set narrowing whose failure mode is a loud 400 rather than the silent-empty class this card gates. Filed as #14282 rather than folded in, and both halves are pinned in tests so a later change that starts walking hops has to delete a test that states the reason.

Positions covered

Top level: columns[] (bare-string and { field } forms, plus summary.field and prefix.field), filter[] keys, tabs[].filter[] keys, grouping.fields[], rowColor.field, userFilters.fields[], userFilters.tabs[].filter[] keys, filterableFields[], hiddenFields[], fieldOrder[].

Layout blocks: every field binding on kanban, calendar, gantt (including tooltipFields[] and quickFilters[].field), timeline, gallery, map and tree. The rule's POSITIONS table was checked key-by-key against ListViewShapeSchema and each block schema in packages/spec/src/ui/view.zod.ts, so no walked key is a phantom and no field-naming key is missing.

Filter keys go through walkFilterFieldKeys, so all three authored filter shapes are judged rather than one being walked and the others silently skipped.

Deliberately excluded, with reasons

• sort[] and searchableFields[] — owned by validate-sortable-fields (A view's declared sort naming a formula field clears lint, then 400s on every load — the SORT axis has no authoring gate, unlike SEARCH (#6674) #9257) and validate-searchable-fields (A virtual formula field declared in searchableFields clears lint and the #4254 gate, then silently matches nothing — the same fail-open shape #4254 closed one axis over #6674/compiler/validate: view searchableFields not validated against searchable field types — a declaration typo 400s the whole list at runtime #4830), each adding a runtime-admissibility verdict this rule has no business restating.
• chart (dataset / dimensions / values) — dataset, dimension and measure names, not fields on the bound object; owned by validateChartBindings / validateDatasetReferences.
• rowActions / bulkActions / columns[].action — action names, owned by validateActionNameRefs.
• conditionalFormatting[].condition — a CEL predicate, owned by the expression rules.
• pageName / tabs[].view / addRecord.formView — page and view names, owned by validateViewPageRefs and lintViewRefs.
• data.object itself — owned by validateObjectReferences. When the bound object does not resolve, this rule skips the whole list view, so one typo yields one finding rather than one per position (pinned).

Severity — two tiers, the validateFlowTemplatePaths precedent

error where the miss changes what data the view returns or collapses the layout it configures (every position in the card's measured table); warning where the renderer drops one decoration and renders the rest (optional colour/title/tooltip/cover bindings, a stale hiddenFields or fieldOrder entry).

Acceptance — validate AND build, pinned end-to-end

Following the #14148 precedent, the acceptance block drives runAuthoringRules for both commands rather than inferring the answer from the registry entry: each of the card's five measured positions fails validate and fails build, the fully-bound list view passes both, and a warning-tier position advises rather than gates. The rule also joins the reference-integrity suite's view runtime type, so the standalone list view a Studio tenant or an MCP author writes through the per-write publish door is judged too — that crossing is argued in the suite's own granularity-wall test.

Verification

All readings below are from commit 910f9d26b, the branch head this PR opens on.

• pnpm --filter @objectstack/lint test — 91 files, 2660 tests passed.
• pnpm --filter @objectstack/lint run typecheck — clean. Note the package's tsconfig.json excludes *.test.ts, so that run says nothing about the test files; a throwaway config including them was run separately and produced zero errors naming any of the three test files this PR adds or edits (the 22 errors it did report are pre-existing, in seven sibling test files).
• Gate families derived mechanically from the real change set (node scripts/pm/dispatch-gates.mjs, 33 families, harvested with --commands): 30 green, 3 NOT MEASURED because they refuse without inputs this worktree does not have — check-test-completeness (exit 3, needs a saved turbo run test log; the gate documents this branch as the local NOT-MEASURED case), check:dual-build-cjs-loads (exit 3, needs a full workspace build), check:type-check-debt (exit 3, same). check-half-states timed out at 300s making live GitHub calls and is likewise recorded as NOT MEASURED — none of the four is a red, and none is a finding about this diff.
• Also green: check:ratchet-remedy-authority, check:declared-population-live, check:nul-bytes.
• pnpm lint (repo-wide ESLint, eslint . --no-inline-config) — clean, run whole rather than narrowed.

Changeset: minor for @objectstack/lint — an accept-set narrowing, matching the family precedent set by #14105 and #14148.

This branch was recovered rather than restarted: the predecessor dev on this card died in a container restart with its work committed in the worktree but never pushed, so the remote branch read as empty. The recovered commit was re-verified here from the premise up before this PR was opened.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/lint, touching 18 documentable anchor(s). ⚠️1 changed file(s) yielded no anchor (packages/lint/src/index.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

7 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/plugin-endpoints.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/concepts/metadata-lifecycle.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/deployment/validating-metadata.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/kernel/services-checklist.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/protocol/objectui/index.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/forms.mdx(via /api/v1/meta/view (route, a path literal in REFERENCE_INTEGRITY_RULES; a path literal in validateListViewFieldRefs))
• content/docs/ui/pages.mdx(via userFilters (symbol, a field of const object POSITIONS))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v12.mdx(via userFilters (symbol, a field of const object POSITIONS))
• content/docs/releases/v15.mdx(via userFilters (symbol, a field of const object POSITIONS))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/lint/src/index.ts) — pages documenting those are invisible to this run
• 15 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 5 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from f170075cc7645caf77aa29c0de92270082061b4f — the merge of head 910f9d26bdad38dd06395af1b23a03936dda3277 into base 8125673462b3c0a6d42ef5b002acd4f77c1a9789, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin f170075cc7645caf77aa29c0de92270082061b4f && git checkout f170075cc7645caf77aa29c0de92270082061b4f
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 8125673462b3c0a6d42ef5b002acd4f77c1a9789 910f9d26bdad38dd06395af1b23a03936dda3277 && git checkout -B drift-repro 8125673462b3c0a6d42ef5b002acd4f77c1a9789 && git merge --no-ff 910f9d26bdad38dd06395af1b23a03936dda3277
node scripts/docs-audit/affected-docs.mjs --json 8125673462b3c0a6d42ef5b002acd4f77c1a9789

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 8125673462b3c0a6d42ef5b002acd4f77c1a9789 → pass the list as
args.docs, on the commit named under Which tree this was computed on.