drivers(turso): the unbacked-conflict-target refusal has no cross-face parity pin — the two wordings can drift without a test noticing

[os-zhuang]

Filed out of #8445. Observation-class: a test-coverage gap, no runtime defect. Unassigned.

The state after #8413 and #8445

One condition — a conflictKeys upsert whose target no unique index backs — is now refused on both TursoDriver faces, and by #5240 both must say it in one wording:

• REMOTE: driver-turso's remote-transport.ts, refuseUnbackedConflictTarget (drivers(turso): the remote face drops unique entirely — a declared-unique column takes duplicates, and an upsert on conflictKeys dies with a raw SqliteError #8413).
• LOCAL: driver-sql's sql-driver.ts, same-named helper, first sentence copied verbatim (drivers(sql): an upsert whose conflictKeys have no backing unique index throws a raw SqliteError — the local twin of #8413's consequence 2 #8445).

TursoDriver picks its face from url, so both can answer in one deployment and a reword of either makes the answer a property of the connection string.

The gap

Nothing compares the two. What exists:

• turso-local-remote-unique-parity.test.ts Pin 3 asserts the refusal on the remote face only — the local face was still raw when that file was written.
• drivers(sql): an upsert whose conflictKeys have no backing unique index throws a raw SqliteError — the local twin of #8413's consequence 2 #8445's sql-driver-upsert-conflict-target-envelope.test.ts pins the first sentence as a literal, which is one-way by construction: it fails if the local face is reworded and cannot see a reword of the remote one.

So a future PR touching one package can drift the pair and both suites stay green. That is exactly the failure mode remote-transport-aggregate-function-refusal.test.ts was written for, and its own header records the measurement that proves it matters: with ONE face reverted the parity cases fail; with both reverted they agree on the wrong answer and stay green. A parity test measures agreement, so it has to be the single-face change that goes red.

The shape of the fix

Add a local-face case to turso-local-remote-unique-parity.test.ts, beside the existing Pin 3: same object without the unique declaration, same conflictKeys upsert, run on both faces, and compare the two RUNTIME messages (plus code and status) rather than two copies of a literal.

It belongs in driver-turso because that is the only package that can import both: driver-sql cannot depend on driver-turso, and remote-transport.ts is deliberately free of knex and of SqlDriver (see its file header), so neither source file can hold the comparison. #8445's declared file surface was driver-sql + changeset, so the dev did not reach into the sibling package to add it — this card is that decision, recorded rather than smuggled.

Related: #8445, #8413, #5240 (one condition, one wording), #6203 / #5769 (the two-answers-per-connection-string defect this class of pin exists to catch).

---

Generated by Claude Code

[hotlong]

Triage: promoted finding → pm:queue at first touch; lands in packages/drivers/driver-turso (turso-local-remote-unique-parity.test.ts) → domain:drivers, type Task.

Rationale: this is a test-only pin with a fully specified shape (add a local-face case beside the existing remote-only Pin 3, compare the two RUNTIME messages plus code+status instead of two literals) and no open question — exactly the "test-only pin, nothing to ask" class that skips the findings holding pattern. The invariant it protects (#5240: one condition, one wording across both TursoDriver faces) is currently guarded one-way only, so a reword of either package drifts the pair with every suite green.

Serial-constraint note for the executing seat: same package family as #8567 (both grew out of #8445) — do not run them in one batch if #8567's chosen home ends up touching driver-turso's parity suite; otherwise they are file-disjoint (#8567 is driver-sql/types-side, this card is driver-turso tests only).

Size/model suggestion: S (mechanical, gate-judged), mode:subagent, model: sonnet.

Triage seat Routine, session session_01KKqo1q7JddqjVbabF1ujMj.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop, drivers lane
Session: session_01VoxQqG5FiUHZKCST7KDoZC
Branch: claude/issue-8568-cross-face-refusal-parity-pin
Worktree: objectstack-issue-8568
Domain: domain:drivers
File surface: packages/drivers/driver-turso/src/turso-local-remote-unique-parity.test.ts + .changeset/ or the skip-changeset label (test-only — the dev decides and states which) (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: opus — deviating from triage's sonnet, reasoned below
Serial constraints cleared: this file was last moved by #8413 (1d1ca8e99, MERGED). #8567 is pm:queue but unclaimed and undispatched, so no overlap today; per triage's note the two stay file-disjoint unless #8567's chosen home reaches this suite — if I dispatch #8567 later I will hold it serial against this branch rather than batch them.

Premise verified on origin/main @ 2342ee42

• The parity suite exists with 8 pins; the refusal pin at :223 ("answers a real code and status — never a raw SqliteError") is the remote-only one this card extends.
• driver-turso depends on @objectstack/driver-sql (workspace:*) — confirmed in its package.json. That is the fact the card's placement argument rests on: this package can import both faces, and driver-sql cannot import back.

Why opus rather than triage's sonnet

Triage graded it "mechanical, gate-judged". I don't think the failure mode is a missed gate. The entire product of this card is a pin that actually tests the invariant — and a wrong pin is green. The specific way to get it wrong is well-marked: asserting each face's message against its own literal instead of asserting the two runtime messages against each other. The literal form passes forever while the two faces drift, which is the exact defect being fixed, re-created inside its own fix.

That is judgment in the design, not correctness a gate adjudicates — the S-but-not-mechanical case that takes M treatment. This card exists because a previous pin was subtly one-way; spending a tier to avoid producing a second one is the cheaper side of that trade.

---

Generated by Claude Code