fix(driver-sql): aggregate count / count_distinct / sum / avg answer numbers on PostgreSQL and MySQL

[objectstack-fleet]

Fixes #20335
Clause-②: no

What changed

SqlDriver.aggregate handed the SQL client's answer straight through. node-postgres parses bigint (OID 20) and numeric (OID 1700) to strings, and mysql2 does the same for DECIMAL. So count / count_distinct / sum / avg reached the engine's having and the REST response as strings on the native path of PostgreSQL (all four) and MySQL (sum / avg), while SQLite and the rows path of every dialect answered numbers.

The fix is one presentation step at the end of the native path, in packages/drivers/driver-sql/src/sql-driver.ts:

• AGGREGATE_ANSWER_KIND is a Record over the spec's AggregationFunction. count, count_distinct, sum and avg are 'number'; min and max are 'column'. A function added to the enum without an entry fails tsc.
• In aggregate(), an aliased aggregation whose function is 'number' registers its alias with the existing 'number' presenter (presentReadValue, the one formatOutput applies to a numeric field on a find() row). min / max keep the column's own presentation, unchanged.
• It is keyed on the function the query asked for, never on what a value looks like. It is not gated by dialect: the presenter rewrites only a string, so SQLite's answers (and mysql2's COUNT) pass through untouched.
• No connection-level type parser is touched. find(), distinct() and the where comparand path are unchanged. packages/objectql is untouched.

Precision policy (H3)

The answer is one JS number, an IEEE-754 double, on every dialect. A sum / avg whose exact value needs more than a double's 15 to 17 significant digits, or an integer total at or above 2^53, is rounded to the nearest double. The policy is stated on AGGREGATE_ANSWER_KIND and in the changeset.

Options weighed:

• A. A JS number, with the loss beyond double precision undeclared. Rejected, because the loss must be written down.
• B. A string only when the value is unsafe as a double, a number otherwise. Rejected. The value's type would depend on its size, so the defect would come back for large totals only: a having $in, or a chart reading the column, would silently stop matching for exactly those groups. That is also the harder shape for an AI author to get right.
• C. Chosen: always a number, with the loss declared. It is the same bound find() already puts on a read of the same exact-decimal column, since formatOutput's numeric pass (valueSchemaFor gives the numeric class z.number().finite(), ADR-0104 D1). It is also the bound the rows path has always had: in-memory-aggregation.ts sums JS doubles.

What the spec says an aggregate's value type is: packages/spec/src/data/aggregation-conformance.ts types AggregationExpectation.value as number and states it "stays a number for every case", across every enrolled face. service-analytics' measure-result-type.ts publishes number as the result type of count / count_distinct / sum / avg measures. Before this change, PostgreSQL delivered strings under that declaration.

Measured (H1, H2)

Base 26daf0b036 and head f3b9e1390c, on SQLite (better-sqlite3), live PostgreSQL 16.13 (server zone Asia/Shanghai) and live MySQL 8.0.46 (+08:00). Each cell went through SqlDriver.aggregate, engine.aggregate and POST /api/v1/data/:object/query (JSON round-trip). The fixture is groupBy customer, four groups, over number fields (one integer-valued, one decimal-valued), currency, percent and rating. The three native doors answered identically at base and at head, on every dialect.

face	base	head
PostgreSQL native: count, count_distinct	string "2"	number 2
PostgreSQL native: sum / avg over number, currency, percent	string "500.000…" (30-digit scale)	number 500
PostgreSQL native: sum / avg over rating (int4)	string "7" / "3.5000000000000000"	number 7 / 3.5
MySQL native: count, count_distinct	number	number, unchanged
MySQL native: sum / avg over number, currency, percent, rating	string (DECIMAL)	number
min / max over any of the five, native, PG and MySQL	number	number, unchanged
SQLite native, every cell	number	byte-identical
rows path, every dialect, every cell	number	byte-identical

H2: a raw query through pg answers field OIDs n:20 total:1700 mean:1700 mn:1700 mx:1700 ss:20 sa:1700 smin:23. Every value is a string except smin (int4). The same query through mysql2 answers column types n:8 (LONGLONG, a number), 246 (NEWDECIMAL, a string) for sum / avg / min / max of the decimal column and for sum / avg of the int column, and 3 for min of the int column. So min / max over a numeric column is a string at the client too. It already left the driver as a number, because a declared numeric field takes the 'number' column presentation since the numeric-representation change. The rows path yields numbers because find() presents the numeric column as a number and in-memory-aggregation.ts computes count as rows.length and sum / avg in JS arithmetic.

The card's having table, engine and REST doors (having is evaluated by the engine on both paths):

having	base: PG native	base: MySQL native	head: every dialect × path
{ n: { $in: [2] } }	no group	c1, c2	c1, c2
{ total: { $in: [500, 20] } }	no group	no group	c1, c4
{ mean: { $in: [250, 600] } }	no group	no group	c1, c2
{ avg_rate: { $in: [0.375] } }	no group	no group	c1
{ n: { $lt: 'not-a-date' } }	c1–c4	no group	no group
{ total: { $lt: 'not-a-date' } }	c1–c4	c1–c4	no group
{ n: { $gt: '+010000-01-01T00:00:00.000Z' } }	c1–c4	no group	no group
$eq on count / sum / avg, $gt / $gte numbers	as elsewhere	as elsewhere	unchanged

At base, SQLite (both paths) and the rows path of PostgreSQL and MySQL already answered the head column.

Collateral (H4)

• find() and distinct() over the five numeric columns are byte-identical base to head, on all three dialects (compared as typed JSON).
• SQLite: every aggregate cell is byte-identical base to head, on every door.
• No connection-level parser changed. The temporal min / max presentation is untouched: the 'column' arm is the pre-existing branch. sql-driver-aggregate-temporal-output.test.ts and sql-driver-13973-canonical-iso-read-door.test.ts pass in the live suite below.

Consumers (H5)

These read the changed values and now receive a number:

• @objectstack/objectql aggregateSummaryValue: roll-up summaries write the value into the parent's summary field. That value is now a number where PostgreSQL (count, sum, avg) and MySQL (sum, avg) handed back a numeric string. summary-backfill.ts counts nonEmpty for a count / sum roll-up only when typeof computed === 'number', so by reading, its report under-counted those roll-ups on PostgreSQL (count, sum) and MySQL (sum) before; it counts them now.
• service-analytics ObjectQLStrategy: passes values through into responses that declare number, and now delivers one. cross-object-rebucket.ts and dataset-executor.ts coerce with Number(...), which is the identity on a number.
• metadata-protocol (the REST query route), runtime action-execution aggregate, mcp stdio-data-bridge, and the client SDK: pass-through, no coercion.
• objectui, read by code search: ObjectChart readValue, ObjectMetricWidget and MetricWidget read these values through Number(...), which is the identity on a number.

None of the consumers above compares these values as strings or branches on typeof value === 'string'; the one typeof test (summary-backfill.ts) asks for 'number'.

Tests

• New: packages/drivers/driver-sql/src/sql-driver-20335-aggregate-numeric-presentation.test.ts. Seven cases per dialect cell of the live matrix (declareDialectCell, so the PostgreSQL and MySQL cells run in Temporal Conformance (live PG + MySQL)):
  • count / count_distinct / sum / avg over number, currency, percent and rating, and sum / avg over a boolean, asserted with toBe against the rows' own JS arithmetic;
  • the all-NULL fold;
  • min / max presentation unchanged;
  • the precision policy: SQL-written 9007199254740993 and 12345678901234567.123456789 answer Number(literal), never a string, and equal what find() reads for the same row.
• New: packages/rest/src/rest-aggregate-numeric-having.test.ts. Engine and REST doors, native and rows paths: having $in / $eq on count / count_distinct / sum / avg, the string-comparand rows of the card, and the response's JSON numbers. The SQLite cell always runs. The PostgreSQL and MySQL cells run when OS_TEST_POSTGRES_URL / OS_TEST_MYSQL_URL are set and are otherwise a named skip.
• Reverse verification: the fix was committed first, then the one presentedOutput.set(agg.alias, 'number') line was deleted through scripts/ablation-replace.mjs (anchor 1 → 0, blob 8dc157d535 → c247bcff26). driver-sql was rebuilt, and ablation-dist-preflight --absent confirmed the marker absent from all six built files. Result:
  • driver-sql test: 7 failed, 14 passed. The failures are every PG and MySQL string cell (for example c1 count(*): expected '2' to be 2). Every SQLite case and MySQL count stayed green.
  • REST test: 13 failed, 23 passed. The failures are the PG and MySQL cells the base table marks. SQLite stayed green.
  • The ablated native answers were byte-identical to the base on all three dialects.
  • Restore: blob equals HEAD, git diff HEAD empty. After a rebuild the marker is present in 2 built files, and git status --porcelain is empty.
• Whole suites, at 06349dc973 (identical code to f3b9e1390c, which only corrects a docblock). PostgreSQL and MySQL were live, with TZ=America/New_York and OS_EXPECT_LIVE_DIALECT_MATRIX=1.
  • @objectstack/driver-sql: 204 files passed, 4690 tests passed, 1 skipped. The reporter confirmed that all 3 dialects were exercised.
  • @objectstack/rest local project, with no live URL, as in CI: 210 files passed, 3817 tests passed, 26 skipped (24 of them this file's PostgreSQL and MySQL cells).
  • @objectstack/objectql aggregate, having, in-memory aggregation and summary files: 19 files, 612 tests passed.
• Typecheck: @objectstack/driver-sql exit 0 and @objectstack/rest exit 0 (including check:test-typecheck). Both new files are in a typecheck program (--listFiles).

Gates

At head f3b9e1390c, after a full workspace build (turbo run build over ./packages/* and ./packages/*/*, 71 of 71 tasks):

• node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 63 commands, the same 63 as the dispatch list. All 63 ran and exited 0. --ran reconciliation: 63 derived, 63 run, 0 NOT-MEASURED, 0 UNRUN.
• origin/main moved during the run, so the three --base gates (check-adr-0087-registration, check-changeset-no-major, check-empty-changeset) and check-issue-citations were also run with --base 26daf0b036 (the merge base). Each exited 0. check-changeset-no-major reads the level from the PR, so its local run has no PR payload to judge.
• Lint, a proved narrowing: eslint --no-inline-config --format json over the three touched TypeScript files reports 3 files, 0 errors, 0 warnings. eslint --print-config resolves a config for each, so none is ignored. The config enables no type-aware linting (parserOptions is ecmaVersion / sourceType only, with no project), so this diff cannot move the verdict on an untouched file. The repo-wide pnpm lint is CI's.
• NOT MEASURED locally, and owned by CI: the type-check lanes over the whole workspace, Test Core shards, Dogfood, Build Core, and Temporal Conformance as CI spells it. The driver-sql suite was run locally against live PostgreSQL and MySQL as above.

Acceptance notes

• The rows path and the exact-decimal native path can differ in the last place of a double. A number column holding 0.1 and 0.2 sums to 0.3 on PostgreSQL and MySQL native (exact numeric / DECIMAL arithmetic) and to 0.30000000000000004 on the rows path and on SQLite (double arithmetic). So having { s: { $eq: 0.3 } } keeps that group on PG / MySQL native and on no other face. Measured identical at base and at head: this PR moves the type, not the arithmetic. Reported to the seat as a separate finding.
• readPresentationKind's 'number' kind (used by min / max and distinct()) reads numericFields, which includes the driver-internal integer / int / float aliases, on every dialect. formatOutput narrows its row pass to numericValueFields on PostgreSQL and MySQL, to keep an introspected external bigint above 2^53 as a string. Not measured, not changed here.
• The REST test's PostgreSQL and MySQL cells are provisioned by no CI job today; the live servers are attached to driver-sql's suite. CI runs their SQLite cell. The PostgreSQL and MySQL value pins run in CI through the driver-sql file. Carrier: none.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/driver-sql, touching 3 documentable anchor(s).

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

• content/docs/ai/natural-language-queries.mdx (via count_distinct (symbol, a field of const object AGGREGATE_ANSWER_KIND))
• content/docs/data-modeling/drivers.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/data-modeling/index.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/data-modeling/queries.mdx (via count_distinct (symbol, a field of const object AGGREGATE_ANSWER_KIND))
• content/docs/deployment/validating-metadata.mdx (via count_distinct (symbol, a field of const object AGGREGATE_ANSWER_KIND))
• content/docs/kernel/contracts/data-engine.mdx (via count_distinct (symbol, a field of const object AGGREGATE_ANSWER_KIND))
• content/docs/permissions/tenant-audit-census.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/plugins/packages.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/protocol/kernel/index.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/protocol/kernel/lifecycle.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/protocol/objectql/query-syntax.mdx (via SqlDriver (symbol, a top-level class), count_distinct (symbol, a field of const object AGGREGATE_ANSWER_KIND))
• content/docs/protocol/objectql/types.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/ui/dashboards.mdx (via count_distinct (symbol, a field of const object AGGREGATE_ANSWER_KIND))

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

• content/docs/releases/v15.mdx (via count_distinct (symbol, a field of const object AGGREGATE_ANSWER_KIND))
• content/docs/releases/v17/17-0.mdx (via SqlDriver (symbol, a top-level class), count_distinct (symbol, a field of const object AGGREGATE_ANSWER_KIND))

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

• 5 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 — 11 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 a88a1bb399ea1ba6d717b8f6fefa0b13ec3e66a8 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json a88a1bb399ea1ba6d717b8f6fefa0b13ec3e66a8

⚠️ 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 a88a1bb399ea1ba6d717b8f6fefa0b13ec3e66a8 → 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: f3b9e1390c0bcea6aa49033485960a41647a48db
Local-runs: none

Inputs read, and nothing else: card #20335 (body and all four comments — triage 5861208644, claim 5861869486, os-dev-report 5862967111, takeover claim 5863887111); PR #20372 body and file list (4 files, equal to git diff origin/main... at the head: sql-driver.ts, two new test files, one changeset); the head's check-runs: 34 runs, 31 success, 3 skipped — Console Pin Gate, Build Docs, Packed-tarball smoke (opt-in), all three rostered as expected skips in scripts/pm/check-expected-skips.mjs; none queued or in progress, none red; the one commit status (Vercel, ignored build step) is success. Read-only git and REST GETs only; nothing built, run or re-run.

① Derived judgments

1. SqlDriver.aggregate answer type for count / count_distinct / sum / avg: on PostgreSQL (all four) and MySQL (sum / avg) a numeric string becomes a JS number; SQLite and the engine's rows path are byte-identical. Public surface: the value's runtime type on two dialects moves TO what the spec already declares (packages/spec/src/data/aggregation-conformance.ts types AggregationExpectation.value as number, "stays a number for every case"; service-analytics measure-result-type.ts publishes number for these four). Accept set: unchanged — no query shape is newly accepted or newly refused; only the answer side moves. RIGHT: a fix toward the declared contract, neither a widening nor a narrowing.

2. Precision policy (the dev's option C): the answer is Number(text), one IEEE-754 double on every dialect; a total at or above 2^53, or one needing more than ~17 significant digits, rounds to the nearest double and is never a string. Public surface: a PG / MySQL native sum / avg beyond double precision left the driver as exact text before and leaves as a rounded double now. RIGHT: it is the bound ADR-0104 D1 (valueSchemaFor gives the numeric class z.number().finite()) and formatOutput's numeric pass already put on a find() of the same column, and the bound in-memory-aggregation.ts (toNumber, JS reduce) always had on the rows path; a value-dependent type (option B) would reopen the card's defect for exactly the large totals. Declared on AGGREGATE_ANSWER_KIND and in the changeset, as triage asked. Residual: PG numeric 'NaN' stays a string under the presenter's existing rule — declared in the docblock; right to leave.

3. AGGREGATE_ANSWER_KIND: a module-private const (no export) — no new export, no public surface. It is a Readonly Record over AggregationFunction; the spec enum (query.zod.ts:159) has exactly six members — count, sum, avg, min, max, count_distinct — and all six carry an entry; funcName = agg.function is typed by AggregationNodeSchema.function: AggregationFunction, so the index is total and a seventh member fails tsc (Type Check · workspace green). RIGHT.

4. The min / max branch re-keyed to AGGREGATE_ANSWER_KIND[funcName] === 'column': same membership as the former funcName === 'min' || funcName === 'max'; the [finding] AGGREGATION_ROWS has no boolean column, so the cross-driver aggregation conformance family cannot see a boolean aggregand on any face #11152 boolean exception (kind !== 'boolean') and the temporal presentation are kept verbatim. RIGHT — no behaviour moves; the live temporal pins ran green in the head's Temporal Conformance (live PG + MySQL).

5. Ordering: presentReadColumns(this.foldEmptyAggregateAnswers(rows, foldedOutput), presentedOutput) — the sum over a column that is NULL in every row of a group: driver-sql answers null, the engine's in-memory aggregate tier answers 0 — same query, same rows, fork chosen by a driver capability bit #15546 fold runs first; emptyGroupValueFor gives 0 (a number) for count / count_distinct / sum, which the 'number' presenter passes untouched since it rewrites only a non-empty string that Number() parses; avg over all-NULL stays null (value == null returns as is). RIGHT; the driver test pins both.

6. Dialect-ungated on purpose: the presenter rewrites only strings, so better-sqlite3's numbers and mysql2's COUNT (a number) pass through — no "string-answering dialects" list to drift. RIGHT; SQLite byte-identity is what the dev's rows table and the ablation show, and the SQLite cells of both files ran under Test Core (green).

7. Unaliased aggregations stay untracked — AggregationNodeSchema.alias is z.string() (required), so that branch is defensive only. RIGHT.

8. find(), distinct(), the where comparand coercion, the node-pg / mysql2 connection-level parsers and packages/objectql: untouched — the net diff touches aggregate() and three docblocks in one file, exactly the surface the claim named and inside every ⛔ of the dispatch. RIGHT.

9. The head commit f3b9e13 is a comment-only docblock correction (verified: git diff 06349dc973 f3b9e1390c is 3 insertions, 1 deletion, all inside a comment). Its claim — the numeric coercion runs on every dialect — is TRUE on this head: readPresentationKind's 'number' arm reads numericFields with no dialect gate, and formatOutput's numeric pass runs on every dialect with a per-dialect registry (numericFields on SQLite, numericValueFields elsewhere). RIGHT.

10. Changeset prose (the shipped CHANGELOG text, a review face): every sentence checks against the diff and the code — the PG / MySQL wire types named (bigint for count and sum over an integer column, numeric for sum / avg over the exact-decimal family and avg over an integer column; mysql2 DECIMAL for SUM / AVG); the having outcomes match the card's table and the dev's measured rows; "min / max unchanged (a declared numeric field was already a number)" matches readPresentationKind; "find() / distinct() unchanged, no connection-level type parser touched" matches the diff; the precision paragraph matches AGGREGATE_ANSWER_KIND; and the consumer note names the one visible move honestly (a consumer that compared these as strings, or checked typeof value === 'string', now receives a number). RIGHT.

11. Consumers, by reading: packages/objectql/src/summary-backfill.ts:423 counts nonEmpty only when typeof computed === 'number', so the PR's "under-counted on PG / MySQL before, counts now" reading is right; having-filter.ts branches on typeof value === 'string' only to format a diagnostic (line 357), never to compare. No consumer in this repo compares these values as strings. RIGHT.

12. Reach of the gates on this head: the driver-sql test declares its cells through declareDialectCell, and Temporal Conformance (live PG + MySQL) runs pnpm --filter @objectstack/driver-sql test — the whole suite — with both URLs and OS_EXPECT_LIVE_DIALECT_MATRIX=1 (ci.yml ~1382–1399); that check-run is success, so the PostgreSQL and MySQL value pins RAN on this head and are green. The REST file's SQLite cell ran under Test Core (packages/rest local project, configDefaults.include). RIGHT — the fix's live cells are red-capable in CI, and the dev's reverse verification (7 driver-sql failures, every one a PG / MySQL string cell; 13 REST failures, the PG / MySQL cells; SQLite green throughout) shows the pins turn on exactly the one deleted line.

13. The REST test's "rows" axis: a per-aggregation filter forces the engine's in-memory path (engine.ts ~16505, engine.aggregate: add per-aggregation filter to the contract — ruled half of #10413 (measure-level filters on the ObjectQL analytics path) #10576), so its two paths are genuinely native and rows, not native twice. RIGHT.

② Semver level

• .changeset/20335-pg-aggregate-numbers.md declares '@objectstack/driver-sql': patch. The only released package whose shipped code changes is @objectstack/driver-sql (17.4.0, not private); @objectstack/rest gains a test file only and publishes nothing, so it owes no changeset. A bug fix in a released package takes patch, never none and never skip-changeset (Post-Task Checklist §3). Check Changeset and Lint & Repo Gates are green on the head. RIGHT.
• Not minor: no new accepted input and no new export. Not breaking: nothing an author can write is removed or renamed, and the value-type move on two dialects is toward the spec's declared number, not away from it; the changeset discloses the one visible move and the precision policy, which is the disclosure triage 5861208644 asked for. RIGHT.
• Clause-②: line — Clause-②: no in the PR body, in the changeset body (where check-adr-0087-registration reads it) and in both claims; no (widening) / (narrowing) arm. The answer to 「本卡放宽接受集或扩大公开面吗」 is no: the accept set is unchanged and the public surface gains nothing; the arm is rightly absent because the accept set is not narrowed either. Consistent on every carrier. RIGHT.

③ Boundary flags

open_questions: [] — none to answer.

Dev flags (os-dev-report 5862967111, deviations D1–D6 and out_of_scope_findings F1–F3), each answered or escalated:

• D1 (PG role without superuser) and D2 (MySQL socket via symlink): local test-environment shapes on the dev's container; no repository effect — the diff is the four files. Answered: no action.
• D3 (stray /suite2.pid at the dev container's filesystem root): not in the tree (git ls-tree of the head lists no *.pid); the branch carries nothing from it. Answered: no repository action; the container belongs to the stood-down os-sales seat.
• D4 (comment-only docblock correction in presentReadValue): inside the claimed file and judged TRUE in ①.9. Answered: right.
• D5 (whole suites at 06349dc, gate union at f3b9e13): the two heads differ by three comment lines, and every check-run on f3b9e13 itself is green, so nothing rests on the dev's local run. Answered.
• D6 / F3 (the REST test reads OS_TEST_POSTGRES_URL / OS_TEST_MYSQL_URL directly with describe.skipIf(!config); its PG / MySQL cells are provisioned by no CI job): two consequences.
  • Accepted: the card's execution note 3 (pin having $in / $eq on count / sum / avg on SQLite, PostgreSQL and MySQL, both paths) is met in the file and was measured green by the dev with live URLs (36 passed). In CI the load-bearing half — the driver answering numbers on PG and MySQL — is pinned red-capable by the driver-sql file (①.12), and the having evaluation is objectql's dialect-agnostic code, exercised on both paths by the SQLite cell. Not a FAIL.
  • Escalated to the seat (carrier none): unlike its sibling packages/rest/src/data-date-read-year-below-100.test.ts, the new file does not honour OS_EXPECT_LIVE_DIALECT_MATRIX=1 — under that flag with a URL missing the sibling reds by design and the new file stays a skip. No CI job runs packages/rest under the flag today, so no gate moves on this head; it is a latent vacuous-pass hole should rest ever join the live job. A follow-up hygiene card, or a one-line pin when that wiring happens; not a condition on this PR.
• F1 (class a): exact-decimal native arithmetic (0.1 + 0.2 = 0.3 on PG numeric / MySQL DECIMAL) against double arithmetic on the rows path and SQLite (0.30000000000000004), so having { s: { $eq: 0.3 } } keeps the group on PG / MySQL native only. Measured identical at base and head — this PR moves the type, not the arithmetic — and correctly kept outside a card whose dispatch excluded objectql's having and the arithmetic path. Escalated: the seat files it bare (the report carries the dedupe words); no card is cited as filed yet. Not a condition on this PR.
• F2 (carrier none): readPresentationKind's 'number' kind reads numericFields (driver-internal integer / int / float aliases included) on every dialect, while formatOutput narrows to numericValueFields on PG / MySQL to keep an introspected external bigint above 2^53 a string. Pre-existing since [finding] The NUMERIC column family diverges from driver-sql in both migration formats — driver real, generators numeric, and rating is real against integer #16318; reaches min / max and distinct() on introspected tables, not this card's four functions, whose 'number' presentation is the declared policy. Answered: not a condition; the seat may hold it for a later card.
• The card's citation of a string-count acceptance note on PR fix(objectql,core): a per-aggregation filter and having read a temporal comparand by the column's storage rule — one rule in core, shared with both drivers' where #20202 did not reproduce (the dev read five temporal notes there); nothing in the fix turned on it. Answered: no action.

Implemented-by: claude/issue-20335-pg-aggregate-numbers
Reviewed-by: session_01N8TPEsoJxPsdSdNKGnNGEN

VERDICT: PASS