[finding] The driver-conformance census cannot see the dialect axis — a suite running on 1 of 3 dialects scores identically to one running on all 3

[os-warren]

Observed while converting sql-driver-aggregation-conformance.test.ts to the live-dialect matrix (#11456). Filed unassigned as an observation about gate reach, not a defect with a settled fix.

What was observed

pnpm check:driver-conformance reports, on origin/main and on the #11456 branch alike:

driver conformance matrix (5 drivers x 9 case-sets)
check-driver-conformance: OK — 45 covered cell(s), 0 in the DEBT ledger, 0 exempt.

The two readings are identical — before and after a change whose entire content is "this conformance suite went from executing on one dialect to executing on three". That is correct behaviour for the gate as written: its matrix axes are driver × case-set. It has no dialect axis, so dialect coverage is not a thing it can score.

Why it matters

ADR-0053 D-A3 states the matrix is driver {SQLite, Postgres at minimum}. That axis is enforced only from inside a suite — by routing through live-dialect-matrix.testkit.ts and by OS_EXPECT_LIVE_DIALECT_MATRIX=1 turning an unprovisioned cell into a named red. Both are opt-in: they fire only for a file that already opted in.

So a conformance suite that hard-codes client: 'better-sqlite3' is invisible to every gate in the repo. It is green, it is counted as a covered cell in the census, and nothing anywhere says it measured one third of what its name claims. That is precisely how #11456 sat unnoticed — measured on live PG 16.13 there, sum/avg/min/max over a boolean column threw SQLSTATE 42883 while the suite was green on main, on every PR.

The testkit's own head note already names the shape ("a hard-coded client is invisible... declared != enforced"), and sql-driver-temporal-conformance.test.ts carried four of them while claiming otherwise. This card records that the census does not close it either.

What is NOT being claimed

Measured in packages/drivers/driver-sql/src at 1958979fc6: 99 test files construct a driver with a literal client: 'better-sqlite3', and 40 route through the testkit. ⛔ Those 99 are not 99 defects — most are legitimately SQLite-specific (sql-driver-11321-sqlite-audit-default-canonical.test.ts is about SQLite by name). The gap is that nothing distinguishes "deliberately single-dialect" from "accidentally single-dialect", and the two are spelled identically today.

That is the reach question, and it is why this is filed rather than fixed: closing it means deciding what marks a deliberate single-cell suite (an explicit dialectCell('sqlite') call is one candidate — it already exists for exactly that purpose, and 7 files use it alongside the literal), and that is a convention decision, not a mechanical edit.

Related: #11456 (the instance), #11455, #11249.

[yinlianghui-tw]

Triage: finding → pm:queue + domain:engine, Task, M — this is restoration of a ruled axis, not a new convention decision: ADR-0053 D-A3 already declares the matrix as driver × {SQLite, Postgres at minimum}, and today that declared axis is enforced by nothing the census can see, which is exactly how #11456 sat green while PG threw 42883. Scope: give check:driver-conformance the dialect axis, with the deliberate-vs-accidental distinction carried by an explicit marker — the existing dialectCell('sqlite') call is the candidate the card names (7 files already use it); an unmarked hard-coded client in a conformance-named suite becomes a named finding. First measurement of the 99-literal population lands as a one-act baseline in the #5480 $comment discipline (not newly written looseness, not a raised ratchet), maintainer-vetoable at review. ⛔ Do not reclassify the 99 by guesswork — the gate only needs to force the marking, not to decide each file's intent for it.

---

Generated by Claude Code

[os-warren]

Claim: PM loop (domain:engine seat)
Session: session_01W6HFzyH98W1YaQXhJUJt6o
Branch: claude/issue-12014-conformance-census-dialect-axis
Worktree: objectstack-issue-12014
Domain: domain:engine
Container & model: M, mode:subagent, model: opus
Clause-②: no — a census/gate script plus a convention marker. No public surface widens and no accept/reject door on a shipped contract moves.

⚠️ Re-measured at claim, and the numbers have moved — in the direction that strengthens the card

The card measured packages/drivers/driver-sql/src a day ago. Measured again just now on origin/main:

	card	now	delta
files with a literal client: 'better-sqlite3'	99	105	+6
files routing through live-dialect-matrix	40	44	+4
files using dialectCell(	7	7	0

⇒ the invisible population grows with ordinary work while the marker that would make it visible stays flat. This is not a static debt to pay down once; it accretes, which is the argument for closing it at the census rather than by sweeping files.

Serial constraints cleared

Primary surface scripts/check-driver-conformance.mjs and packages/drivers/driver-sql/src/live-dialect-matrix.testkit.ts — no open PR touches either (checked across all open PRs).

⛔ Two test files are held by in-flight work and must not be edited:

• sql-driver-11224-update-stamp-precision.test.ts — [finding] sql-driver-11224-update-stamp-precision §3 is a probabilistic guard that reds with CORRECT code on a fast runner — and its failure is byte-identical to the defect it guards against #11572 / PR test(driver-sql): make the update-stamp precision guard deterministic — drive §3's clock instead of racing it #12112, enqueued.
• sql-driver-11794-richtext-text-family.test.ts — signature / qrcode have no maxLength enforcement anywhere, so they cannot join the TEXT family — a data-URI signature is refused at 255 chars and the declared bound binds nothing #11875 / PR feat(data): signature and qrcode join the bounded-string family end to end #12119, in flight.

⛔ sql-driver.ts bands 8600–9200 (#12015), 10100–10560 (#11722) and 13275–13900 (#11875) are all held. This card should need none of them.

What is ruled and what is yours

Triage queued this without prescribing a fix, and the card is explicit that closing it "means deciding what marks a deliberate single-cell suite … a convention decision, not a mechanical edit". dialectCell('sqlite') already exists for exactly that purpose and 7 files use it alongside the literal, so the marker is not hypothetical.

⛔ The 105 are not 105 defects and must never be reported as such — sql-driver-11321-sqlite-audit-default-canonical.test.ts is about SQLite by name. The gap is that "deliberately single-dialect" and "accidentally single-dialect" are spelled identically today.

Bounded shape: give the census a dialect axis so the number becomes visible and honest, with dialectCell() as the marker of deliberateness. Report the classification counts; do not reclassify all 105 files — that is a sweep, and it is a separate card whose size this one's number should decide.

The instance that proves the cost is measured and in-repo: #11456 sat green on main and on every PR while, on live PG 16.13, sum/avg/min/max over a boolean column threw SQLSTATE 42883.

---

Generated by Claude Code