[objectstack-fleet]

Fixes #21255

Clause-②: no (narrowing)

This is the precondition #21242 waits on: after it lands, no having or per-aggregation filter query reaches @objectstack/formula's lteBound with a cross-class plain reference. #21242 itself is not addressed here.

What changed

having and the per-aggregation filter (aggregations[i].filter) now apply the comparison-class rule to every plain { $field } comparison, as where does, and not only to an addDays pair. A plain reference whose two columns belong to different classes of the spec's CROSS_FIELD_COMPARISON_CLASSES is refused INVALID_FILTER / 400 before any driver is asked for a row.

• packages/objectql/src/having-filter.ts
  • crossClassReferenceViolation asks the spec's own crossFieldComparisonVerdict (the classification driver-sql's crossFieldComparisonClass delegates to) and refuses only its cross-class answer. comparable, no-class and unjudged are not this rule's, and a side with no declaration is not judged.
  • The cross-class sentence is written once (crossClassReason) and printed by both the addDays rule and the plain rule. No third copy of the class table: AggregatedColumnClass is now the spec's CrossFieldComparisonClass, the same six names.
  • Per-aggregation filter: same refusal, same withholding and the same log line as the objectql + REST: the per-aggregation filter still lacks four of where's doors — a bad date, an addDays numeric pair, an undeclared { $field } and an unknown key answer 200 with every count 0 #20148 reference rules. The wire message now names the same-class rule ("compared as the same type class", where's words) beside the addDays one.
  • having: the pair is judged against each aggregated column's TYPE (aggregatedRowColumnTypes). The message names the two projected columns and their classes, as the objectql having: a { $field } reference with addDays against a non-temporal aggregated column answers by epoch-ms coercion, where SQL push-down refuses the same pair on where — the aggregated row declares no temporal class to judge it by #20127 addDays refusal does (columnPairError, which says "with addDays" only when the reference carries one).
  • addDays pairs: unchanged, still offsetPairViolation over the having vocabulary's classes.
• packages/objectql/src/engine.ts: one argument at the assertHavingIsEvaluable call site, aggregatedRowColumnTypes(query.groupBy, query.aggregations, declaredFields), which is the same map the number-comparand door already receives a few lines below. This is outside the claim's file surface. The reason: the having vocabulary's class (classOfDeclaredType) reads a file / image groupBy projection as text, where the spec gives it no class. Judging plain references by that class would have refused a file-against-number pair under the cross-class words, a narrowing beyond cross-class references. Asking the spec's verdict of the column's type avoids it.
• Pins: packages/objectql (both doors, empty and populated, grouped and ungrouped) and packages/rest, where the where twin runs on a real SqlDriver.
• .changeset/21255-having-plain-reference-class.md: minor, BREAKING (accept-set narrowing), ADR-0087 not-required (no-migration-prescription).

Measurements (H1 to H4)

• H1, confirmed at base 2791138cbf: assertConditionIsEvaluable judged the class only under if (scope.classes && target.addDays !== undefined) (:1425). assertAggregationFilterReferencesAreDeclared judged it only under if (offset !== undefined) (:1329).
• H2, measured. where's words are driver-sql's (sql-driver.ts applyCrossFieldComparison): "T" is stored as C1 but "R" as C2, and a cross-class comparison answers differently in SQL (storage-class ordering) than in memory (JS coercion) — compare same-class columns., under uncompilableFieldReferenceError (INVALID_FILTER, withheld). The having vocabulary and the spec verdict:
  • They agree on the six class names, and on every single-valued FieldType member the spec classes. The having side reads the same five value-class sets, and everything else falls back to text.
  • They disagree on the no-class families: list-or-object (structured-JSON types, multi-option types, multiple: true) and file read as text in the having vocabulary. formula is undefined (not judged) there, while the spec says no class (refused by where). A type outside FieldType is text there and unjudged in the spec.
  • Hence the plain rule asks the spec's verdict directly and does not reuse classOfDeclaredType. The tail of the sentence is pinned against the twin's real diagnostic (see Pins).
• H3, measured. Each position takes its classes from its own source. The per-aggregation filter reads the object's declared fields (declaredFieldMeta: type plus multiple). having reads the type the query gives each aggregated column: a count / sum / avg is a number, a day bucket a date, a coarser bucket text, and min / max the field's type. When the class cannot be told, nothing is judged; that is the posture an addDays pair already had. Evidence: having with no registered object keeps ['c1'] for last_closed $lte { $field: 'first_due' }, and a per-aggregation filter with no registered object counts 3 for the card's query. Both are pinned on both doors, and both stayed green under the reverse verification.
• H4, reproduced at base 2791138cbf through engine.aggregate on SqlDriver over better-sqlite3 (probe fixture): aggregations[0].filter { closed_at: { $lte: { $field: 'due_on' } } } answered [{ n: 4 }], and having max(closed_at) $lte { $field: 'due_day' } (due_on day bucket) kept 4 of 6 groups. The where twin answered INVALID_FILTER / 400 with the diagnostic above. On the pinned REST fixture, with the rule reverted: 3 rows (c1 2, c2 1) and 3 of 6 buckets.

Pins

• The two measured queries refused, each beside its where twin in the same test (packages/rest/src/aggregation-filter-where-doors.test.ts, [#21255] block, POST /api/v1/data/:object/query on SqlDriver). Each refusal is 400 INVALID_FILTER on an empty and a populated table, with no driver read. The twin is 400 INVALID_FILTER. The class names and the sentence's tail are parsed out of the twin's own withheld diagnostic (withheldFilterDiagnosticOf) and asserted inside the per-aggregation log line and the having message, so the agreement is pinned rather than retyped.
• Refusals on both doors (packages/objectql): 7 per-aggregation shapes (datetime/date both ways, text/number, time/datetime, under $ne, behind a $or branch that holds, under $not), the names withheld and logged 8 times. 9 having shapes: the card's query, datetime/date both ways, text/sum, sum/date, count/datetime under $ne, $or, $not, and a month bucket against a date.
• Same-class controls answer what they answered. Per-aggregation: date/date 3, datetime/datetime 4, number/number 4, time/time 6, text/text 0 (REST: date/date and datetime/datetime counted as their where twins count). having: day bucket/date ['2026-01-02', '2026-01-15'], datetime/datetime ['c1', 'c2'], count/max ['c2', 'c3']. The existing ANSWERED row "a numeric pair with NO addDays" (['c1']) is relabelled "(one class on both sides)", because its old label "(the rule is the offset's)" is no longer true.
• addDays pairs unchanged: the existing objectql having: a { $field } reference with addDays against a non-temporal aggregated column answers by epoch-ms coercion, where SQL push-down refuses the same pair on where — the aggregated row declares no temporal class to judge it by #20127 REFUSED / ANSWERED pins and the objectql + REST: the per-aggregation filter still lacks four of where's doors — a bad date, an addDays numeric pair, an undeclared { $field } and an unknown key answer 200 with every count 0 #20148 REFERENCE_REFUSED / REFERENCE_PASSING pins, left green and not edited.

Reverse verification

Only the gate was reverted, through node scripts/ablation-replace.mjs. In crossClassReferenceViolation, the anchor if (target === undefined || referent === undefined) return undefined; became if ('ABLATION_21255'.length > 0) return undefined;: the plain rule answers "not judged" at both positions, and the addDays rule is untouched.

• The tool showed the anchor 1 → 0 and the blob c425c56a9b → 604a038ce3. Rebuild exit 0. node scripts/ablation-dist-preflight.mjs @objectstack/objectql ABLATION_21255: marker present in 4 built files.
• Under the mutation:
  • objectql: 16 failed | 265 passed (281). The 16 are exactly the 7 per-aggregation and 9 having refusal pins. Every same-class control, both registry-less controls and every addDays pin stayed green.
  • rest: 2 failed | 18 passed (20), the two refusal pins. The three same-class controls stayed green.
• Restore: blob back to the HEAD hash, git diff HEAD empty. After the rebuild, the preflight with --absent found the marker absent from all 14 built files and the tree clean. Re-run: objectql 281 passed, rest 20 passed.
• The direction was as predicted: the refusal pins went red, the controls stayed green.

Tests and gates (HEAD df85ac4baa)

Every command was run through bash scripts/pm/os-verify-lock.sh (VERDICT command-exit 0 each time) unless it is listed as a gate.

• pnpm --filter @objectstack/objectql exec vitest run --project local --maxWorkers=2 src/engine-aggregate-filter.test.ts src/engine-aggregate-having-comparand-shape.test.ts: 281 passed (281).
• pnpm --filter @objectstack/rest exec vitest run --project local --maxWorkers=2 src/aggregation-filter-where-doors.test.ts: 20 passed (20).
• The whole @objectstack/objectql suite (vitest run --project local --maxWorkers=2): 360 files, 7108 passed. This ran at 08678c107e, which differs from HEAD only by a second main merge (no objectql file), a doc-comment reflow and the REST test's typed options.
• Typechecks, at df85ac4baa: pnpm --filter @objectstack/objectql typecheck exit 0, including check:test-typecheck ("40 file(s) / 234 error(s) … held"); pnpm --filter @objectstack/rest typecheck exit 0, test layer "0 error(s)".
• Consumers whose fixtures carry { $field } on the aggregate path, run against the same tree and still green:
  • packages/rest data-field-comparand-permission.test.ts: 30 passed;
  • packages/services/service-analytics cross-field-engine-fallback, cross-field-offset-dataset and include-relation-cross-field-boundary: 175 passed.
• Gates: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands derived 65 commands at df85ac4baa. All 65 ran there with exit 0, check:dual-build-cjs-loads and check:type-check-debt included. --ran with the recorded exit codes reports: "65 derived, 65 run, 0 NOT-MEASURED, 0 UNRUN … a DERIVED zero".
• NOT MEASURED, family check-issue-citations --census and check-shard-attestation. Reason: each takes a value from the workflow, so CI runs them.
• Lint, a proven narrowing: pnpm exec eslint --no-inline-config --format json over the 5 changed source and test files reported 5 results, 0 errors and 0 warnings. eslint.config.mjs sets no parserOptions.project and registers no typed rule, so linting is not type-aware and this diff cannot move the verdict of any file it does not touch. The repo-wide pnpm lint is CI's.

Acceptance notes

• No-class pairs are not judged by this rule. This is a boundary, kept on purpose: refusing them would narrow beyond cross-class references. Measured at engine.aggregate on SqlDriver, where the where twin is 400 every time:

  • per-aggregation text vs image: counted 6, at HEAD and with the rule reverted;
  • number vs multiselect: counted 6, at HEAD and with the rule reverted;
  • having on an image groupBy against a count: answered, at HEAD and with the rule reverted;
  • datetime vs a formula, measured at HEAD only: counted 0, because the formula has no value in the raw rows.

  None of these reaches lteBound with a bare day. Reported to the seat as a finding for this family's close-out card.

• applyInMemoryAggregation (exported) does not run the objectql + REST: the per-aggregation filter still lacks four of where's doors — a bad date, an addDays numeric pair, an undeclared { $field } and an unknown key answer 200 with every count 0 #20148 reference rules for a host that calls it directly, and so does not run this one either. No in-repo caller passes a per-aggregation { $field } there. Noted, not filed.

• A having refusal message runs past the REST envelope's 500-character bound, so the wire truncates its closing clause about how a column's class is read. The class reason sits in the first part and survives. The same is true of the existing addDays refusal.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/objectql, touching 18 documentable anchor(s).

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

• content/docs/protocol/objectql/query-syntax.mdx (via due_on (literal, a string literal in a comment on a changed line))

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 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.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 17 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 4e6dc2338acbc00eaf98bd8269317a779c6b8c02 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from e68ba3a18443a75ded9f83e17202fbbd5e36a64e — the merge of head df85ac4baabe5a6974e269419b595a274d306c06 into base 4e6dc2338acbc00eaf98bd8269317a779c6b8c02, 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 e68ba3a18443a75ded9f83e17202fbbd5e36a64e && git checkout e68ba3a18443a75ded9f83e17202fbbd5e36a64e
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4e6dc2338acbc00eaf98bd8269317a779c6b8c02 df85ac4baabe5a6974e269419b595a274d306c06 && git checkout -B drift-repro 4e6dc2338acbc00eaf98bd8269317a779c6b8c02 && git merge --no-ff df85ac4baabe5a6974e269419b595a274d306c06

node scripts/docs-audit/affected-docs.mjs --json 4e6dc2338acbc00eaf98bd8269317a779c6b8c02

⚠️ 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 4e6dc2338acbc00eaf98bd8269317a779c6b8c02 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: df85ac4baabe5a6974e269419b595a274d306c06
Local-runs: none

Inputs: card #21255 (body; comments 5942982209, 5943357114, 5944459558, 5944487371); PR #21297 (body, the 6-file list, the GitHub diff against merge base 748b2407); packages/spec/src/data/filter-cross-field-comparison-class.ts and packages/drivers/driver-sql/src/sql-driver.ts (applyCrossFieldComparison, uncompilableFieldReferenceError) at the merge base; having-filter.ts, engine.ts, registry.ts and aggregate-field-type-door.ts at base and head through git show; card #21299; and the head's check-runs, read last. Nothing was built, run or re-run.

① Derived judgments

1. Refused set at the per-aggregation filter — right, and exact. assertAggregationFilterReferencesAreDeclared hands every plain reference to crossClassReferenceViolation with declaredFieldMeta on both sides (type plus multiple: true, the two inputs crossFieldComparisonVerdict reads) and refuses only the cross-class answer. comparable answers as before; no-class (file, list-or-object, formula) and unjudged return undefined; a side the object's field map does not carry returns undefined. The addDays arm is the old offsetPairViolation call, now one branch of an offset !== undefined ternary. Nothing wider than cross-class is refused. The three row-carried names declaredReferenceNames admits beyond the map (id, created_at, updated_at) are judged only when the map carries them; by default it does, because the registry injects AUDIT_FIELD_DEFS.created_at / updated_at as type: 'datetime' (registry.ts near :655, plan.audit), so the datetime pair that matters is judged on an ordinary object.

2. Refused set at having — right at this head, with one latent seam. assertConditionIsEvaluable routes a reference with addDays to the unchanged offset rule and a plain one to assertSameClassReference, which asks the spec's verdict of each aggregated column's TYPE (columnTypeMeta over aggregatedRowColumnTypes): a day bucket is date, a coarser bucket text, count / count_distinct / sum / avg number, min / max the field's type. The spec classes each of those as the having vocabulary does; a file, image, formula or structured-JSON projection answers no-class and is not judged. Latent seam: columnTypeMeta passes no multiple, so a multiple: true select / radio / lookup / user projection would read as a scalar text. Unreachable at this head: the [finding] two more JSON-stored columns as a group or distinct key answer 500 on PostgreSQL: groupBy on a multiple: true select, and count_distinct on a json field #20808 door refuses a groupBy on a multi-value field, and the spec's min / max rows admit only numeric, temporal and boolean types, so no such column exists in an aggregated row. Noted for objectql having and the per-aggregation filter answer a { $field } comparison against a no-class column (file, multi-valued, formula) where the where twin refuses it 400: the family's close-out card, with a per-position enumeration pin #21299's enumeration pin; not a defect of this diff.

3. TYPE rather than the having class at the having seam — right. classOfDeclaredType lumps every non-numeric, non-boolean, non-temporal type into text, so judging by it would have refused a file-against-number pair under the cross-class sentence, the narrowing the dispatch forbade; the type lets the spec answer no-class for it. Nothing else having judges moves: types is a new optional EvaluableScope member read by exactly one new branch; the addDays branch is logically unchanged (classes && addDays became addDays, then classes); assertHavingIsEvaluable has one caller (engine.ts :17317), which now passes the fourth argument.

4. Words — right. crossClassReason is byte-identical to the sentence offsetPairViolation built before, which is applyCrossFieldComparison's cross-class sentence with "is stored as" read as "is" (the objectql having: a { $field } reference with addDays against a non-temporal aggregated column answers by epoch-ms coercion, where SQL push-down refuses the same pair on where — the aggregated row declares no temporal class to judge it by #20127 convention for computed columns). The per-aggregation wire message gains "compared as the same type class", the clause uncompilableFieldReferenceError's wire message carries; the fields, the operator and the reason stay withheld, and the logged diagnostic keeps where's shape (Operator ... on field ... compares against another field ..., which cannot be evaluated here: reason). having names its own projection, as objectql having: a { $field } reference with addDays against a non-temporal aggregated column answers by epoch-ms coercion, where SQL push-down refuses the same pair on where — the aggregated row declares no temporal class to judge it by #20127 does, and columnPairError says "with addDays" only when the reference carries one.

5. AggregatedColumnClass — right, and not a public-surface change. It becomes an alias of CrossFieldComparisonClass: the same six literals, so every existing use type-checks unchanged. It is not published: neither the . nor the ./core entry of @objectstack/objectql re-exports having-filter.ts; its consumers are two sibling door modules. The changeset's "No export or published type changes" is accurate.

6. addDays pairs — unchanged, confirmed. offsetPairViolation keeps its guards and its prose; the objectql having: a { $field } reference with addDays against a non-temporal aggregated column answers by epoch-ms coercion, where SQL push-down refuses the same pair on where — the aggregated row declares no temporal class to judge it by #20127 and objectql + REST: the per-aggregation filter still lacks four of where's doors — a bad date, an addDays numeric pair, an undeclared { $field } and an unknown key answer 200 with every count 0 #20148 pins are untouched except one ANSWERED label ("the rule is the offset's" became "one class on both sides", the true reason now). Green in Test Core on this head.

7. Pins — they prove what they claim. The objectql per-aggregation helper drives 8 cells (native-capable and raw driver, empty and populated, grouped and ungrouped) and asserts INVALID_FILTER / 400, zero aggregate / find calls, one message across cells and 8 logged diagnostics naming both fields and both classes; the having helper drives both doors, empty and populated, zero reads. The packages/rest pins drive POST /api/v1/data/:object/query on a real SqlDriver over better-sqlite3 with closed_at (datetime) added to the fixture, assert zero reads and the twin's 400, and parse the two class names and the trailing sentence out of the twin's own withheld diagnostic (withheldFilterDiagnosticOf, a published driver-sql export) before asserting them inside the per-aggregation log line and the having message. Same-class controls (5 per-aggregation, 3 having, 3 REST) and two registry-less controls answer as before. The ablation anchor (the target === undefined || referent === undefined guard replaced by an always-true return) disables crossClassReferenceViolation at both positions and nothing else; 7 + 9 objectql and 2 REST refusal blocks is exactly the count the diff adds, so "16 and 2 red, controls green" is the only outcome that mutation can produce. Not re-run here.

② Semver level

• minor with the BREAKING banner is right: ADR-0087's amendment of 2026-09-13 ([Decision] 两条裁决援引同一个 launch-window convention，却给出相反的 changeset 等级（minor vs major）—— 退役一个可写键到底发哪一级？ #18003) states that pre-GA a metadata-facing break ships minor, carrying the BREAKING banner and its ADR-0087 disposition entry; check-changeset-no-major refuses major until GA; the objectql CHANGELOG carries the same sentence on more than ten 17.6.0 entries.
• adr-0087: not-required (no-migration-prescription) is a category check-adr-0087-registration lists (its CATEGORIES, :497) and re-verifies on every run; Check Changeset and Lint & Repo Gates are green on this head. The claim holds on the diff: no spec key, export, stored shape or accepted request shape moves; what is refused is a comparison where already refuses, and which same-class column the author meant is not something a ledger entry can decide.
• Clause-②: no (narrowing) stands at line start in the changeset (line 7) and in the PR body (line 3).
• Prose: accurate. "What was accepted before" is the card's two measured queries and the whole-day reading that answered them; "What is refused now" names the six scalar operators, the spec's six classes, both doors, 400 before any read on an empty set as on a populated one, and the withheld-versus-named split per position; the remedy is where's (compare same-class columns); "Unchanged" correctly keeps same-class, addDays, no-declaration and no-class pairs out of this rule.

③ Boundary flags

• Deviation 1 (engine.ts, one argument) — recorded by amendment 5944487371 and stated in the PR body. Necessary for the no-narrowing constraint (judgment 3). Nit, not a contract issue: aggregatedRowColumnTypes(query.groupBy, query.aggregations, declaredFields) is now computed a third time inside aggregate (also :17349 and :17416) rather than hoisted beside havingColumnClasses.
• Deviation 2 (packages/rest test) — recorded by the amendment. Justified: @objectstack/objectql declares no driver-sql dependency (its package.json) and the engine refuses no where reference, so a twin cannot be refused inside objectql; the file is a test only, in the existing objectql + REST: the per-aggregation filter still lacks four of where's doors — a bad date, an addDays numeric pair, an undeclared { $field } and an unknown key answer 200 with every count 0 #20148 twin harness, with the fixture widened by one datetime column. The amendment says the cross-lane surface is declared on the domain:cli seat post; that post is outside this review's inputs and is taken as recorded.
• Open question (refuse no-class too?) — answered A and filed as objectql having and the per-aggregation filter answer a { $field } comparison against a no-class column (file, multi-valued, formula) where the where twin refuses it 400: the family's close-out card, with a per-position enumeration pin #21299 (open, created 2026-10-02T02:30Z, unlabelled, awaiting triage). It names both positions, the crossClassReferenceViolation seam, the four measured pairs with their where twins, applyInMemoryAggregation as an enumerated position, and an enumeration pin over positions and verdicts. It covers the measured positions. Escalated to the seat for objectql having and the per-aggregation filter answer a { $field } comparison against a no-class column (file, multi-valued, formula) where the where twin refuses it 400: the family's close-out card, with a per-position enumeration pin #21299's enumeration: add the no-declaration rows beside the four verdicts (the registry-less host, and the declaredReferenceNames-admitted row-carried columns on an object that opts out of audit fields) and the latent columnTypeMeta multiple seam of judgment 2.
• Out-of-scope findings — the no-class divergence is objectql having and the per-aggregation filter answer a { $field } comparison against a no-class column (file, multi-valued, formula) where the where twin refuses it 400: the family's close-out card, with a per-position enumeration pin #21299's; applyInMemoryAggregation is enumerated on objectql having and the per-aggregation filter answer a { $field } comparison against a no-class column (file, multi-valued, formula) where the where twin refuses it 400: the family's close-out card, with a per-position enumeration pin #21299 (no in-repo caller passes a per-aggregation reference there; packages/verify date-bucket parity is its only external caller); the 500-character truncation is rest-server.ts :11375 (clientMsg.slice(0, 500)), pre-existing, and the class reason sits in the first part of the having message, so the REST pin's asserted fragment survives it. All answered.
• Downstream formula: retire F7's whole-day copy (lteBound in matches-filter.ts) now that the RLS write check judges the stored form (#21109, PR #21235); its direct-call cases move to the storage-form lowering #21242 (lteBound) — after this PR, on a registered object with its default system fields, no having or per-aggregation query reaches lteBound with a cross-class plain reference between two columns the field map declares: both positions refuse before any read, and created_at / updated_at sit in that map as datetime. What can still reach it, each by the dispatch's own no-declaration-not-judged direction, read and not measured: (a) a registry-less host, which this PR pins as answered, and those two controls encode lteBound's whole-day answer (picked: 3; ['c1']), so formula: retire F7's whole-day copy (lteBound in matches-filter.ts) now that the RLS write check judges the stored form (#21109, PR #21235); its direct-call cases move to the storage-form lowering #21242 must expect them to move; (b) an object that opts out of audit fields, where created_at / updated_at pass declaredReferenceNames but have no map entry, while driver-sql refuses the where twin; (c) a direct applyInMemoryAggregation caller. None is a declared-column production path, so this card unblocks formula: retire F7's whole-day copy (lteBound in matches-filter.ts) now that the RLS write check judges the stored form (#21109, PR #21235); its direct-call cases move to the storage-form lowering #21242 as far as its scope reaches; (a) and (b) go to the seat with objectql having and the per-aggregation filter answer a { $field } comparison against a no-class column (file, multi-valued, formula) where the where twin refuses it 400: the family's close-out card, with a per-position enumeration pin #21299.
• Check-runs on the head, read 2026-10-02T02:53Z: 34 of 34 completed, 31 success and 3 skipped (Build Docs, Console Pin Gate, Packed-tarball smoke (opt-in)), none in progress; combined status success. The gate verdicts are green.

Implemented-by: claude/issue-21255-having-class-rule
Reviewed-by: session_017xfMoEjKUuSh2xYB8sCozp

VERDICT: PASS

---

Generated by Claude Code