[finding] driver-sql's SQLite json codec is not round-trip faithful for a string whose content is valid JSON — '123' reads back as a number, and Postgres does not agree

[os-trump]

Filed by the domain:services PM seat (session session_01UQgPSniH1GFM9ZDeGyuGUa) on behalf of the #12172 dev. Observation, not a defect claim — and see the measurement caveat below, which is load-bearing. Unassigned and without domain:*: the landing zone is packages/drivers/driver-sql (engine lane), and routing is triage's.

⚠️ Read this before grading: MODELLED, not executed

The finding was reached by reading both codec functions and modelling them in node — ⛔ not by an executed driver round-trip against a real SQLite database. It wants confirmation on a real rig before it is treated as settled. Stated first rather than in a footnote, because the whole card turns on it: if a real round-trip disagrees with the model, the finding is wrong and that is the useful outcome.

The shape

sys_setting.value and every other Field.json column go through driver-sql's codec. The two halves do not compose to identity on SQLite when the stored string's content happens to be valid JSON:

• formatInput (sql-driver.ts:14877-14882) stores non-object primitives as-is.
• formatOutput (:14929-14938) JSON.parses every string json field, with a keep-as-string fallback when the parse throws.

⇒ On SQLite, a stored string round-trips type-changed whenever it parses:

stored (a string)	reads back on SQLite	reads back on Postgres
'123'	number 123	'123'
'true'	boolean true	'true'
'null'	null	'null'
'{"a":1}'	object {a: 1}	'{"a":1}'
'America/New_York'	'America/New_York' (parse throws, fallback holds)	same

Postgres does not take that path: it JSON.stringifys into the jsonb column and the client parses back, so the string survives as a string.

⇒ The two dialects diverge for this value class. For service-settings specifically the user-visible form is: a string-typed setting whose value is '123' or 'true' comes back type-changed on a SQLite deployment — and the same app on Postgres does not.

⛔ Distinct from the deliberate coercion next door. The numeric-scalar coercion at :14943 is for numericFields and is documented as intentional. This is a different function, a different column class, and carries no such statement.

Why it surfaced here

While repairing #12172 (a service-settings test fixture that stored JSON text where the service persists verbatim), the dev had to establish what a real driver hands back for a Field.json column — which meant reading both halves of the codec. The fixture repair itself does not depend on this: both dialects round-trip an ordinary string like 'America/New_York' to the raw value, which is what that card needed. This is the edge the reading exposed on the way past.

Dedup — two queries, both run

Per this seat's standing rule (cards and open PRs, the latter by the file the finding names):

• is:issue semantic search over the codec/dialect-divergence space → the nearest neighbours are driver-sql (MySQL): find() answers 1/0 for a declared boolean field — the read coercion is gated to SQLite, so the storage form leaks on the row-read door #11782 (closed — MySQL find() answers 1/0 for a declared boolean because the read coercion was gated to SQLite), driver-sql (PG): JSON-field values are bound without JSON.stringify — non-empty arrays and bare strings 500, empty array silently stored as {} #10995 (closed — PG JSON-field values bound without JSON.stringify; the write half, other dialect), [Decision] min/max over a boolean aggregand: pin the cross-driver JSON answer — 0/1 (SQL) vs false/true (both in-memory faces) #11249 (closed — a ruling pinning the cross-driver JSON answer for boolean min/max), driver-sql: single→multi-value field change never migrates the existing column type (varchar/text kept), arrays silently stored as stringified literals — data corruption on Postgres #11535, driver-mongodb lowers avg / sum over a boolean column to null / 0 — the same cell as #11065, one driver over #11151. None is this shape: none is about a string whose content parses, and none names formatOutput's parse-with-fallback.
• is:pr is:open over driver-sql + the codec function names → zero results.

⭐ But the density of that neighbourhood is itself the finding worth grading. This is at least the fourth instance of "a codec or coercion gated to one dialect diverges from the other", and #11249 shows the pattern is expensive when it lands: that one could not simply be fixed — it had to be ruled, because both answers were defensible. Whether this class wants a cross-dialect round-trip invariant rather than another per-instance card is a question for triage, and it is the reason this is filed as an observation rather than as a repair.

What a good answer looks like

⛔ Not "fix the parse". First: execute the round trip on a real SQLite rig for the four rows in the table above, and on Postgres for the same four, and post the two readings side by side. If they agree, this card closes as a modelling error and the model is what was wrong. If they diverge as predicted, the repair direction is a ruling question — round-trip fidelity vs. the convenience of reading a JSON column as parsed data — not a one-line patch.

Provenance, and a gap worth keeping visible

⭐ The #12172 dev found this and deliberately did not file it, because that seat has no dedup-search channel — direct REST returns 403 GitHub access is not enabled for this session, and MCP issue search is off-limits for dedup reads under the dispatch contract. It handed the finding up rather than filing blind, which is the right call and the reason this card exists with a dedup search behind it instead of a duplicate. ⚠️ That gap is already carded as #12123; this is a live instance of its cost.

Refs

#12172 / PR #12379 (where it surfaced) · #11782 · #10995 · #11249 · #11535 · #12123 (the dedup-channel gap)

[os-trump]

Triage: promoted → pm:queue, routed domain:engine; rationale: the landing zone is packages/drivers/driver-sql (engine lane; driver-sql is explicitly outside the driver-memory/driver-mongodb investment freeze). Type Task, not Bug — the card is a MODELLED divergence, not an executed one, and the family precedent shows both repair directions can be defensible, so nothing is established as violating a declared contract yet.

Queue charter is exactly the card's "what a good answer looks like": execute the round trip first — the four table rows on a real SQLite rig and the same four on Postgres, readings posted side by side. Branch on the reading: model wrong ⇒ close as a modelling error with the reading as the record; divergence confirmed ⇒ ⛔ do not pick a repair — escalate as a needs-user-decision card (round-trip fidelity vs. parsed-read convenience is a ruling-class fork, same as the boolean min/max precedent), and fold into that escalation the class question this card raises: whether a cross-dialect round-trip invariant should replace per-instance cards, this being at least the fourth member of the "codec/coercion gated to one dialect" family.

Size/model suggestion: S (measurement + branch), opus — the branch judgment (close vs. escalate, and drafting the fork honestly) is judgment-tier even though the rig work is mechanical.

---

Generated by Claude Code

[os-warren]

os-dev-report

{
 "issue": 12380,
 "status": "needs_decision",
 "branch": "claude/issue-12380-sqlite-json-roundtrip",
 "pr": null,
 "premise_still_valid": true,
 "summary": "Executed the round trip on live SQLite, live Postgres 16 and live MySQL 8. The modelled divergence is CONFIRMED, and the executed reading is broader than the model in a way that changes the repair question: there are TWO independent mechanisms on SQLite, not one. (A) A read-side one, which is the one the card modelled: formatOutput JSON.parses every string in a json column. (B) A write-side one the card did not model: the json column is created with declared type 'json', which under SQLite's type-affinity rules is NUMERIC affinity, so a number-like string is converted to INTEGER/REAL BEFORE storage. '0123', ' 123 ', '1e5', '1.0' and '-0' are already destroyed on disk; no read-path change can recover them. Postgres and MySQL agree with each other and are faithful in both directions, so the divergence is two-way (SQLite vs the other two), not three-way. Per triage's charter I did not pick a repair: no PR.",
 "tests": "See the executed readings below. No gate union is owed: `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` -> \"this branch changes nothing against 'origin/main' (merge base 7986d973f) - nothing to derive\". No ablation is owed either: no gate and no code were added, and an ablation exists to prove a NEW gate can fail. `node scripts/check-driver-conformance.mjs` was run anyway because the class question turns on it -> \"check-driver-conformance: OK - 45 covered cell(s), 0 in the DEBT ledger, 0 exempt.\"",
 "open_questions": ["Round-trip fidelity vs parsed-read convenience on SQLite json columns, and the migration it implies - see the fork below."],
 "out_of_scope_findings": []
}

---

Executed round trip: the model is confirmed, and the mechanism is not the modelled one

Rig: SqlDriver.create() / findOne() through the real driver, object registered via initObjects so the driver runs its own DDL. Physical column type read from the catalog (pragma_table_info / information_schema.columns), never from emitted DDL. The stored cell read back by a separate raw query that bypasses the codec.

dialect	server	physical type of a Field.json column (catalog)
SQLite	better-sqlite3, :memory:	json
Postgres	live PG 16.13, server TZ Asia/Shanghai	json (udt_name=json)
MySQL	live MySQL 8.0.46, server TZ +08:00	json

Process TZ America/New_York for all three (the testkit's non-vacuity posture).

Reading 1 — a string whose content is valid JSON

wrote is always a string. PG and MySQL were identical on every single row, so they share a column.

wrote (string)	SQLite disk	SQLite read	PG / MySQL disk	PG / MySQL read
'123'	123 INTEGER	123 number	"123"	'123' string
'true'	true TEXT	true boolean	"true"	'true' string
'false'	false TEXT	false boolean	"false"	'false' string
'null'	null TEXT	null	"null"	'null' string
'[]'	[] TEXT	[] array	"[]"	'[]' string
'{"a":1}'	{"a":1} TEXT	{a:1} object	"{\"a\":1}"	'{"a":1}' string
'"quoted"'	"quoted" TEXT	quoted string	"\"quoted\""	'"quoted"' string
' 123 '	123 INTEGER	123 number	" 123 "	' 123 ' string
'0123'	123 INTEGER	123 number	"0123"	'0123' string
'1e5'	100000 INTEGER	100000 number	"1e5"	'1e5' string
'1.0'	1 INTEGER	1 number	"1.0"	'1.0' string
'-0'	0 INTEGER	0 number	"-0"	'-0' string
'9007199254740993'	9007199254740993 INTEGER	9007199254740992 number	"9007199254740993"	exact string
''	`` TEXT	'' string	""	'' string
'NaN'	NaN TEXT	'NaN' string	"NaN"	'NaN' string
'America/New_York'	TEXT	'America/New_York' string	"America/New_York"	same
'{bad json'	TEXT	'{bad json' string	"{bad json"	same

Postgres and MySQL: 17/17 faithful. SQLite: 13/17 type-changed. The card's four predicted rows all reproduce.

The boundary, and why it is not one boundary

The card modelled one mechanism. There are two, and they have different reversibility, which is the whole decision:

(A) Read-side — formatOutput, reversible. The disk still holds the exact original bytes; only the presentation is wrong. Applies to strings that survive storage as TEXT: 'true', 'false', 'null', '[]', '{"a":1}', '"quoted"'.

(B) Write-side — SQLite column affinity, IRREVERSIBLE. The column is declared json. SQLite's affinity rules assign TEXT affinity only to a declared type containing CHAR/CLOB/TEXT, INTEGER to one containing INT, and so on; json contains none of them, so it falls through to NUMERIC affinity, which converts a bound number-like string at storage time. Applies to '123', ' 123 ', '0123', '1e5', '1.0', '-0'.

Executed directly rather than inferred — the same value bound into a json-declared and a text-declared column in one insert:

json_col="123"/integer text_col="0123"/text
json_col="123"/integer text_col=" 123 "/text
json_col="100000"/integer text_col="1e5"/text
json_col="1"/integer text_col="1.0"/text
json_col="0"/integer text_col="-0"/text
json_col="true"/text text_col="true"/text

So a fix that repairs '123' on the read path repairs nothing: by the time any read runs, '0123' and '123' are the same INTEGER on disk. That is the sense in which the card's '1e5' warning lands — but it lands harder than "the fix must cover it": for class (B) there is no read-path fix at all.

Which dialect is right

Decided from the declared contract, not from strictness. valueSchemaFor({type:'json'}, 'stored') in packages/spec/src/data/field-value.zod.ts returns z.unknown(), and says so deliberately:

Where the contract is deliberately open (json, code payloads, computed types), the schema is z.unknown() — openness is now an explicit decision, not an accident of nobody checking.

An open contract is what settles it. Because 123 and '123' are both legal stored values of the same field, the driver has no license to map them onto one representation. Postgres and MySQL match the contract; SQLite does not. Their JSON.stringify write half is injective and the client parse is its exact inverse; SQLite's half is injective in neither direction.

Measured, on the same six pairs — is the string form distinguishable on disk from the native form?

pair	SQLite	PG	MySQL
'123' vs 123	COLLIDE (both INTEGER 123)	distinct	distinct (json_type STRING vs INTEGER)
'[]' vs []	COLLIDE (both TEXT [])	distinct	distinct
'{"a":1}' vs {a:1}	COLLIDE (both TEXT {"a":1})	distinct	distinct
'true' vs true	distinct (TEXT true vs INTEGER 1)	distinct	distinct
'null' vs null	distinct on disk, collide on read (both null)	distinct	distinct
'"q"' vs 'q'	distinct	distinct	distinct

PG and MySQL: 0 collisions out of 6. SQLite: 3 on disk, 4 on read.

Something the card did not model: native values fail too

The card is titled around strings. The same codec also breaks non-string JSON values on SQLite:

wrote=true (boolean) disk="1"/integer read=1 (number) faithful=false
wrote=false (boolean) disk="0"/integer read=0 (number) faithful=false

formatInput leaves the boolean as-is, better-sqlite3 binds it as INTEGER, and formatOutput's json branch only touches strings, so nothing converts it back. (formatOutput's booleanFields pass is keyed to declared Field.boolean columns, not to booleans living inside a json payload.) Numbers, objects, arrays, plain strings and null do round-trip.

So the honest scope is not "strings whose content parses" — it is: on SQLite, Field.json round-trips faithfully only for object, array, plain-string, number and null; it fails for every boolean and for every string whose content is valid JSON.

Blast radius — this is a migration question

sys_setting.value is Field.json (packages/platform-objects/src/system/sys-setting.object.ts:156), and the settings service persists the raw JS value verbatim — storedValue = rawValue (settings-service.ts:1667), read back as value: r.value ?? null (:2205) with no re-coercion by declared type. So the driver's answer is what the caller gets.

On a SQLite deployment today:

• a boolean setting reads back as 1 / 0;
• a string setting whose value is '123', 'true', 'null', '[]' or '{"a":1}' reads back type-changed;
• a string setting whose value is '0123', '1e5', '1.0', '-0' or ' 123 ' has already lost its bytes on disk.

Both directions of the transition, as Clause ② asks:

• Making strings faithful (stop parsing in formatOutput) flips every existing SQLite row that currently reads as an object/array back to a raw JSON string. Every consumer of a json column — settings, composite, repeater, record, location, address, vector, and every Field.multiple — starts receiving text where it received structure. That breaks the overwhelmingly common, correct case in order to fix the rare one.
• Keeping the parse leaves the corruption and the dialect divergence in place.
• Making the encoding injective (stringify on SQLite too, as PG/MySQL already do) is the only option that is right in both directions — and it is a storage format change: every existing SQLite row is in the old format, so it needs a migration, and for class (B) rows the pre-migration bytes are not recoverable. A migration can convert {"a":1}-as-object-intent going forward; it cannot know whether an on-disk INTEGER 123 was written as 123 or as '123'.

That is why I stopped here rather than shipping a read-path change over existing rows.

The fork for the ruling

Q. On SQLite, should a Field.json column store an injective JSON encoding (matching Postgres and MySQL), accepting a storage-format migration and an unrecoverable class of already-damaged rows — or should the current lossy-but-convenient encoding be declared the contract for SQLite?

• Option A — make SQLite injective (JSON.stringify on write, JSON.parse on read, unconditionally). Round-trip fidelity for every value; one codec across all three dialects; kills the whole divergence class rather than this instance. Cost: a storage-format migration over every existing SQLite Field.json column; class (B) rows cannot be restored, only stopped from growing; any out-of-band reader of a SQLite file sees quoted JSON text where it saw a bare value.
• Option B — declare SQLite's current behaviour the contract. Zero migration. Cost: sys_setting and every json column keep silently corrupting booleans and JSON-looking strings on the dialect tenant environments actually run; the same app keeps behaving differently on SQLite and Postgres; and it makes "declared open, therefore the driver may re-interpret" a precedent, which is the opposite of contract-first.
• Option C — narrow what can be written (reject a string whose content parses as JSON). ⚠️ This is a new rejection door on an existing accept path: writes that succeed today would start failing, on all three dialects, for values PG and MySQL already handle correctly. It also cannot repair a single existing row.

Recommendation: A, with the migration scoped and the unrecoverable class named explicitly in its changeset. It is the only option under which the declared-open contract and the driver's behaviour agree, and the only one that closes class (B) rather than relocating it. On the four axes: real business need — sys_setting is the measured live consumer and tenant environments run SQLite/Turso; long-term soundness — one codec, no per-dialect special case, no consumer-side tolerance; hard to get wrong for AI-written metadata apps — an app authored against Postgres behaves identically on SQLite instead of corrupting on deploy; startup scope discipline — A removes a branch rather than adding a capability, and C would add a rejection surface with no pull behind it.

The class question triage asked to fold in

⭐ The census has no opinion about this, and that is the finding. check-driver-conformance is green at 9 of 9 dialect-scored cells matrix-routed after #12136's MATRIXED invariant — but its nine case-sets are FILTER_LOGIC, TEMPORAL, TEMPORAL_TIME, PAGINATION, PAGINATION_UNORDERED, PAGINATION_ZERO_LIMIT, FILTER_TEXT, AGGREGATION, FILTER_COMPARAND_TYPE.

Not one of them is about value storage round-trip. The dialect axis enforces that filters, temporal storage, pagination and aggregation answer the same on every dialect. It says nothing about whether what you wrote is what you read back. So MATRIXED 9/9 green is not weak evidence about this defect — it is no evidence at all, and it would stay green forever with this defect in place.

This is the fourth member of the "codec or coercion gated to one dialect" family (#11782, #10995, #11249). The reason per-instance cards keep arriving is structural: the census enforces a matrix over the axes someone thought to add a case-set for, and nobody has added the one this family lives on. A VALUE_ROUNDTRIP case-set in packages/spec/src/data/*-conformance.ts would put the whole family under CLASSIFIED + MATRIXED at once — every driver forced to consume it, every dialect forced to answer the same. That is a bigger and better answer than repairing this instance, and it is the same shape the census already imposes on temporal storage.

---

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

PM review — investigation ACCEPTED. Escalating; ⛔ no repair attempted, correctly.

The executed reading is materially broader than this card modelled, and it changes the question from "patch a codec" to "migration plus ruling".

The card modelled one mechanism. There are three, and one is irreversible

#	mechanism	reversible?
A	Read-side — formatOutput JSON.parses every string in a json column; disk still holds the original bytes	✅ yes
B	Write-side, unmodelled — the column is declared type json, which under SQLite's type-affinity rules resolves to NUMERIC affinity, so a number-like string is converted to INTEGER/REAL before storage	⛔ no
C	Native booleans, unmodelled — true reads back as number 1; formatOutput's json branch only touches strings, and its booleanFields pass is keyed to declared Field.boolean columns	✅ yes

⇒ '0123', ' 123 ', '1e5', '1.0', '-0' are already destroyed on disk. No read-path change recovers them.

⭐ Mechanism B was executed, not inferred — the same value bound into a json-declared and a text-declared column in one insert: json_col='123'→integer vs text_col='0123'→text. That is the affinity rule caught in the act.

So the honest scope is not "strings whose content parses". On SQLite, Field.json round-trips faithfully only for object, array, plain-string, number and null.

Divergence is two-way, not three

PG 16.13 and MySQL 8.0.46 are 17/17 faithful, 0/6 colliding, identical to each other. I asked for MySQL specifically because a three-way split would be a worse card; it isn't one.

Which dialect is right — settled by the contract, which is the test I set

I fenced this: "⛔ Do not assume Postgres is correct because it is stricter — check what the json field's declared stored-value contract actually says." It was checked, and I verified it independently at packages/spec/src/data/field-value.zod.ts:401-403:

"Where the contract is deliberately open (json, code payloads, computed types), the schema is z.unknown() — openness is now an explicit decision, not an accident of nobody checking."

⇒ An explicitly-open contract admits both 123 and '123' as legal values of one field, so the driver has no license to map them onto one representation. PG/MySQL honour that; SQLite does not. Not a strictness argument — a contract one.

⭐ The census answer, and it is worse than "didn't catch it"

I asked whether #12136's freshly-landed dialect axis now has an opinion here. The answer:

check-driver-conformance is green at 9 of 9 dialect-scored cells matrix-routed after #12136's MATRIXED invariant, but none of its nine case-sets is about value storage round-trip — so that green is not weak evidence about this defect, it is no evidence at all, and it would stay green forever with the defect in place.

That is the right shape of answer and it converts an instance into a class question. The nine case-sets cover filters, temporal, pagination and aggregation. Nothing covers "what you wrote is what you read back" — which is why this family keeps arriving one card at a time.

⭐ An anomaly disclosed in its own data rather than tidied away

Run B's single cell for the string '"q"' contradicted runs A and C. The dev hypothesised the row id contained a double quote, probed it directly (run D), found the hypothesis was WRONG, and reported the cell as an unexplained artifact of its own logging template — while showing that no headline claim rests on it, because B's collision verdicts are computed from the disk column, which is consistent across every run.

Reporting an unexplained contradiction in your own measurements, with the hypothesis you tried and its failure, is exactly the standard. A tidy table here would have been worth less.

Blast radius read from source, not assumed: sys_setting.value is Field.json (platform-objects/src/system/sys-setting.object.ts:156), and the settings service persists verbatim and reads back with no re-coercion by declared type — so the driver's answer is what the caller gets. Tenant environments run SQLite/Turso.

Why there is no PR, and why that is right

My dispatch said: "⛔ If repairing the codec would change what already-stored data reads back as, that is a migration question — stop and report with the blast radius rather than shipping a read-path change over existing rows." It does, and part of the damage is unrecoverable, so it did.

⚠️ And the fork is forced, not chosen: '123' the string and 123 the number are the same bytes on disk today, so no read-path change can distinguish them, and there is no patch that repairs one class without flipping the other.

No ablation was fabricated to fill the template — "an ablation exists to prove a NEW gate can fail, and I added no gate and no code". Correct.

State: pm:dispatched → needs-user-decision. Putting the fork to the maintainer now.

Housekeeping

The branch claude/issue-12380-sqlite-json-roundtrip was pushed empty as the write-routing probe (zero commits, identical to base 7986d973fa); git push origin --delete was refused by the proxy. It carries nothing and is safe to reuse or delete — flagging so nobody reads it as abandoned work.

---

Generated by Claude Code

[os-warren]

Maintainer ruling — A: make SQLite injective, and D: add the VALUE_ROUNDTRIP case-set

Source: maintainer, 2026-08-26, live PM chat (session session_01W6HFzyH98W1YaQXhJUJt6o). Both questions answered: A（让 SQLite 变单射） and 加（VALUE_ROUNDTRIP case-set）.

A — one codec across three dialects

JSON.stringify on write, JSON.parse on read, unconditionally, as PG and MySQL already do. This deletes a dialect branch rather than adding one, and it closes the divergence class rather than this instance.

The contract decides it, not strictness: field-value.zod.ts:401-403 states that json's stored contract is z.unknown() because "openness is now an explicit decision, not an accident of nobody checking." An explicitly-open contract admits both 123 and '123' as legal values of one field ⇒ no driver has license to collapse them onto one representation.

The costs are accepted with open eyes and must be stated in the PR, not discovered:

• a storage-format migration over every existing SQLite Field.json column;
• ⛔ the NUMERIC-affinity class ('0123', '1e5', ' 123 ', '1.0', '-0') can only be stopped from growing, never restored — a migration cannot know whether an on-disk INTEGER 123 was written as 123 or as '123';
• an out-of-band reader of a SQLite file will see quoted JSON text where it saw a bare value.

⛔ B and C are not taken. B would keep silently corrupting booleans and JSON-looking strings on the dialect tenant environments actually run, and would set the precedent "declared open, therefore the driver may re-interpret" — the inverse of contract-first. C is a new rejection door on an existing accept path, failing writes on all three dialects for values PG and MySQL already handle correctly, and repairing zero existing rows.

D — the case-set, and why it is a separate card

Ruled in. The measured justification stands on its own: the census is green at 9 of 9 dialect-scored cells, and none of its nine case-sets is about value storage round-trip — so that green is no evidence at all here, and would stay green forever with the defect in place. A VALUE_ROUNDTRIP case-set puts this family under CLASSIFIED + MATRIXED at once, converting it from per-instance cards into an enforced invariant.

Sequencing is mine, and D goes second. Two reasons:

1. A VALUE_ROUNDTRIP case-set landing before A would ship a gate that is red on SQLite by construction — and this seat ruled on Resolve the 2 DIALECT_LEDGER rows, then promote "every dialect-scored cell has a matrix-routed suite" to an invariant (#12014 follow-up) #12136 that "a gate that ships red is worse than one that ships honest." It would have to ledger SQLite immediately, which is the escape hatch Resolve the 2 DIALECT_LEDGER rows, then promote "every dialect-scored cell has a matrix-routed suite" to an invariant (#12014 follow-up) #12136 just narrowed.
2. D is cross-driver by design — it will ask driver-memory and driver-mongodb the same question, and whatever it surfaces there is not this card's blast radius to absorb. ⚠️ [裁决] driver-memory / driver-mongodb 投入冻结 —— 维护者 2026-08-05 口径（跨单锚点） #5499 froze investment in both of those drivers, so D needs to be scoped against that ruling rather than tripping over it.

⇒ This card is A, with its own pin. D is filed as a follow-up, sized by what A measures — the same shape as #12014 → #12136, which worked.

State: needs-user-decision → pm:dispatched.

---

Generated by Claude Code