fix(lint): judge an injected column on the same axis as an authored one in the dotted-filter and include rules (#16340)

Two more consumers of a resolved leaf's `meta` inherit the registry type the
object graph now carries, which is why the fix went to the seam rather than
into `filter-preset-comparand`.

`list-view-field-dotted` refuses `created_at.x` (a `datetime` scalar has
nothing beneath it) and `owner_id.name` (a `lookup` stores an id, not an
embedded document) — both already refused at the door by
`assertFilterIsMaterializable` with the registry's field map in hand, so the
linter's silence was the miss. `dataset-include-unknown` drops its
`verdict.injected` bail, whose stated reason ("its type is registry-owned and
invisible here") this change makes false: `include: ['owner_id']` joins,
`include: ['created_at']` derives no join and is refused.

`id` falls through the untyped branch of all three rules — the driver
provisions the primary key and no definition table describes it.

Claude-Session: https://claude.ai/code/session_01MkQhmuuJAVDjmeWNixwDDH
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.changeset/lint-injected-temporal-column-types.md

@@ -29,4 +29,13 @@ The engine already refused all three of those at query time (`INVALID_FILTER` /
 
 **Type change for direct consumers of the seam**: `GraphObject.injected` changed from `ReadonlySet<string>` to `ReadonlyMap<string, GraphField>`. `.has(name)` answers exactly as before; code that iterated the set or spread it into one needs `.keys()`. Shipped as `minor` under the repo's launch-window convention.
 
+## Two more rules inherit it, in the same edit
+
+The type reaches every rule that asks a second question about a resolved leaf, which is the whole reason it was fixed at the seam rather than inside `filter-preset-comparand`:
+
+- **`list-view-field-dotted`** now refuses a dotted list-view filter key whose head is an injected column, on the same axis as an authored one. `created_at.x` reads as the `datetime` scalar it is (nothing beneath it for a path to reach) and `owner_id.name` as the `lookup` it is (it stores an id, not an embedded document). `assertFilterIsMaterializable` and the REST ingress have always answered `400 INVALID_FIELD` for both — the linter was silent only because the type was missing here.
+- **`dataset-include-unknown`** now judges an `include[]` entry naming an injected column instead of bailing on the marker: `include: ['owner_id']` joins (it is the registry's `lookup`), `include: ['created_at']` is refused (a `datetime` derives no join, so every dimension written against that prefix addresses nothing).
+
+`id` falls through the untyped branch of all three rules — the DRIVER provisions the primary key and no definition table describes it, so an unreadable head is what the door sees too, and none of them invents a refusal there.
+
 A relationship HOP through an injected column stays a skip (`unknowable` / `injected-hop`), deliberately: the slice now carries `reference`, and traversing it would newly judge every path through a platform anchor wherever `sys_user` is compiled into the stack — a widening with its own findings to measure.

packages/lint/src/validate-dataset-references.test.ts

@@ -245,6 +245,36 @@ describe('validateDatasetReferences — include[] must name a RELATIONSHIP', ()
     expect(rules(stackWith({ include: ['duty'], dimensions: [], measures: [] }))).toEqual([]);
   });
 
+  // [#16340] An injected column is judged on the same axis as an authored one:
+  // the graph carries the registry's own definition for it. `owner_id` IS the
+  // `lookup` the registry declares, so an include naming it joins; `created_at`
+  // is a `datetime`, so an include naming it derives no join and every
+  // dimension written against that prefix addresses nothing — which is the
+  // finding, not a guess. Before this the rule bailed on the marker and said
+  // neither thing.
+  it('accepts an include naming an INJECTED relationship anchor', () => {
+    expect(rules(stackWith({ include: ['owner_id'], dimensions: [], measures: [] }))).toEqual([]);
+  });
+
+  it('refuses an include naming an injected column that is not a relationship', () => {
+    const findings = validateDatasetReferences(
+      stackWith({ include: ['created_at'], dimensions: [], measures: [] }),
+    );
+    expect(findings).toHaveLength(1);
+    expect(findings[0].rule).toBe(DATASET_INCLUDE_UNKNOWN);
+    expect(findings[0].message).toContain('`datetime` field');
+    expect(findings[0].message).toContain('not a relationship');
+  });
+
+  it('⛔ leaves the primary key untyped — the driver provisions it, no table describes it', () => {
+    const findings = validateDatasetReferences(
+      stackWith({ include: ['id'], dimensions: [], measures: [] }),
+    );
+    expect(findings).toHaveLength(1);
+    // The untyped branch: "an ordinary field", not a guessed type.
+    expect(findings[0].message).toContain('an ordinary field');
+  });
+
   it('refuses a multi-hop include whose intermediate hop is not traversable', () => {
     const findings = validateDatasetReferences(
       stackWith({ include: ['status.owner'], dimensions: [], measures: [] }),
@@ -371,12 +401,15 @@ describe('validateDatasetReferences — the three skips', () => {
     ).toEqual([]);
   });
 
-  it('skips a hop THROUGH an injected column, whose target is registry-owned', () => {
+  it('skips a hop THROUGH an injected column, whose target the seam does not traverse', () => {
     // `owner_id` IS injected on this object (`ownership` omitted ⇒ both anchors)
-    // and IS a lookup at the registry — but its type and target are invisible
-    // here, so `owner_id.name` is unanswerable rather than a miss. Reporting it
-    // would be the false positive skip 3 exists to avoid; assuming it resolves
-    // would be the fail-open on the other side.
+    // and IS a lookup at the registry. [#16340] The slice now carries that
+    // target, but `resolveFieldPath` still answers `injected-hop` rather than
+    // walking it: traversing would newly judge every path through a platform
+    // anchor wherever `sys_user` is compiled in, which is a widening with its
+    // own findings to measure. Reporting the hop would be the false positive
+    // skip 3 exists to avoid; assuming it resolves would be the fail-open on
+    // the other side.
     expect(rules(stackWith({ dimensions: [{ name: 'o', field: 'owner_id.name' }], measures: [] }))).toEqual([]);
   });
 

packages/lint/src/validate-dataset-references.ts

@@ -214,9 +214,14 @@ export function validateDatasetReferences(stack: AnyRec): DatasetRefFinding[] {
 
       if (verdict.kind === 'ok') {
         // The entry resolves to a real field — but `include` joins, so the
-        // field must BE a relationship. An injected column's type is
-        // registry-owned and invisible here, so it is unanswerable, not a miss.
-        if (verdict.injected) return;
+        // field must BE a relationship. [#16340] An injected column is judged
+        // on the same axis as an authored one: the graph carries the
+        // registry's own definition, so `owner_id` reads as the `lookup` it is
+        // and `created_at` as the `datetime` it is. The bail that used to sit
+        // here ("its type is registry-owned and invisible") is gone with the
+        // limitation that justified it. The primary key still falls through
+        // the untyped branch below — the DRIVER provisions it and no
+        // definition table describes it.
         const type = verdict.meta?.type;
         if (type && RELATIONSHIP_FIELD_TYPES.has(type)) return;
         findings.push({

packages/lint/src/validate-list-view-field-refs.test.ts

@@ -427,10 +427,32 @@ describe('#14282 — a dotted key the FILTER door refuses, and the ones it serve
     expect(validateListViewFieldRefs(stackWith(mutate(filterOn('tags.0'))))).toEqual([]);
   });
 
-  it('a registry-injected head is NOT refused at a filter — its type is invisible here', () => {
-    // `created_at` resolves through skip 3 with no readable type, and
-    // `classifyDottedFilterHead` answers `null` for an unreadable head.
-    expect(validateListViewFieldRefs(stackWith(mutate(filterOn('created_at.x'))))).toEqual([]);
+  // [#16340] A registry-injected head IS judged now: the graph carries the
+  // registry's own definition for it, so the classifier reads the same
+  // `datetime` the DOOR reads. `assertFilterIsMaterializable` has always
+  // refused `created_at.x` with `400 INVALID_FIELD` — the linter was silent
+  // only because the type was missing here, which is the miss #16340 closed.
+  it('a registry-injected scalar head is refused at a filter, as the door refuses it', () => {
+    const findings = validateListViewFieldRefs(stackWith(mutate(filterOn('created_at.x'))));
+    expect(findings).toHaveLength(1);
+    expect(findings[0].rule).toBe(LIST_VIEW_FIELD_DOTTED);
+    expect(findings[0].severity).toBe('error');
+    expect(findings[0].message).toContain('`datetime` field');
+    expect(findings[0].message).toContain('single scalar value');
+  });
+
+  it('an injected RELATION head is refused on the same axis as an authored one', () => {
+    const findings = validateListViewFieldRefs(stackWith(mutate(filterOn('owner_id.name'))));
+    expect(findings).toHaveLength(1);
+    expect(findings[0].message).toContain('`lookup` field');
+    expect(findings[0].message).toContain("stores the related record's id");
+  });
+
+  it('⛔ the primary key is NOT refused — the driver provisions it and no table types it', () => {
+    // The one injected column with no definition behind it. An unreadable head
+    // is what `classifyDottedFilterHead` answers `null` for, and the door
+    // serves it, so the linter must not invent a refusal here.
+    expect(validateListViewFieldRefs(stackWith(mutate(filterOn('id.x'))))).toEqual([]);
   });
 
   it('the tab and user-filter tab presets are judged on the same axis', () => {

packages/lint/src/validate-list-view-field-refs.ts

@@ -204,9 +204,18 @@
  * never reported (ADR-0072 D1: one dead finding and authors stop trusting the
  * linter): an object this stack does not define, an object that declares no
  * readable field map (ADR-0015 `external`, datasource-introspected schemas),
- * and a registry-injected system column. A fourth skip is this surface's own:
- * a list view whose `data.provider` is not `object` binds to no object graph
- * at all, so none of its field names is resolvable here.
+ * and a hop THROUGH a registry-injected system column. A fourth skip is this
+ * surface's own: a list view whose `data.provider` is not `object` binds to no
+ * object graph at all, so none of its field names is resolvable here.
+ *
+ * [#16340] An injected column at the HEAD of a dotted filter key is not a skip
+ * and never was — it resolves. What used to be missing was its TYPE, so
+ * `classifyDottedFilterHead` read an unreadable head and this rule stayed
+ * silent on `created_at.x` while `assertFilterIsMaterializable` refused it at
+ * the door with the registry's own field map in hand. The graph now carries
+ * the registry's definition for each injected column, so the two answer alike.
+ * `id` remains unreadable — the DRIVER provisions the primary key and no
+ * definition table describes it — and the door serves it, so this rule does too.
  */
 
 import { classifyDottedFilterHead } from '@objectstack/spec/data';