@voltro/runtime 0.41.0 → 0.43.0

package/CHANGELOG.md

@@ -39,6 +39,194 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [0.43.0] — 2026-08-18
+
+### ⚠ BREAKING
+
+- **@voltro/data-transfer, @voltro/cli** — `DanglingReferenceError` is now `RowsRefusedError`, and it separates the rows that failed from the rows that failed because those rows did.
+
+  **The name.** The import raised it for EVERY row still refused after deferred-FK resolution, whatever the reason — a NOT NULL violation, a duplicate key, a value the database computes for itself. The tag named ONE possible cause and put it where a reader looks first, so any other refusal arrived mislabelled. The new name states the outcome; each row's `reason` states the cause, which is where a cause can honestly be claimed.
+
+  **The split.** A row is `derived` when one of its reference columns holds the primary key of another row that also failed in this run: it could not have landed whatever it contained, so its reason describes the parent's problem. The relation is transitive, decided from the DATA (the failed ids against the reference-typed values), so no schema knowledge is needed. `primaryCount` is the number an operator acts on, `rows` lists primary failures FIRST so the cap never spends its budget on consequences, and the CLI leads with both numbers:
+
+  ```
+  import refused 300 row(s), of which 1 are the actual failures — the rest could
+  not land because a row they reference did not.
+    teams t1  foreign key teams_ibfk_1: the referenced row does not exist [1452]
+    … and 299 row(s) behind them. Fix the 1 above and re-run; they resolve with
+    their parents.
+  ```
+
+  In an FK-dense bundle one refused parent takes its whole subtree with it, so the length of a flat list says how connected the data is, not how many problems there are — and the single row that explains all of them sits somewhere in the middle of it.
+
+  The codemod rewrites the import and every use of the symbol. It does NOT rewrite a tag STRING (`Effect.catchTag('DanglingReferenceError', …)`, `err._tag === '…'`) — change those to `'RowsRefusedError'` — and the payload gained `primaryCount` plus a `derived` flag per row.
+
+### Fixed
+
+- **@voltro/cli** — `voltro doctor`'s `subject-write-no-guard` rule reads the DESCRIPTOR before it reports. It looked only at the executor, and the access decision is not declared there.
+
+  Every form of access decision the framework has — `internal: true`, `guards: [...]`, `openAccess:` — is declared on the DESCRIPTOR. So an app that declares them properly got a finding for each one, and on a codebase whose procedures are mostly `internal: true` the rule fires on essentially all of them and is wrong essentially every time.
+
+  That is worse than a rule that finds nothing: it is the longest line in the report and it reads like a security finding, so it teaches the reader to skim the place a real finding would have appeared.
+
+  The premise was structurally impossible for most of them, and the framework says so itself: `security.defaultDeny` refuses at boot any wire-exposed procedure declaring neither `guards:` nor `openAccess:`. So "an anonymous caller reaches the write" can only be true of an `openAccess` procedure. That is what the rule looks for now — plus the handler check it always honoured, plus an ownership comparison against `subject.id`, which is the refusal the rule says is missing. Where no descriptor can be read, it says nothing: the claim is about a declaration, and a finding whose evidence was never opened is the failure mode this fixes.
+
+  The `use:` line changed with it. It recommended `.guard(requireScope('…'))`; the shipped guide teaches declarative `guards:` and calls a hand-written per-executor scope check the thing `guards:` exists to delete. A rule may not recommend the shape the guide argues against.
+- **@voltro/database, @voltro/data-transfer** — A `voltro data` transfer no longer carries GENERATED column values, and no longer loses every row that has one.
+
+  The export wrote the computed values into the bundle and the import sent them back in the `INSERT` column list. MariaDB refuses that for any value except NULL (`1906: The value specified for generated column 'x' in table 't' has been ignored`); postgres refuses a non-DEFAULT value outright. So the transfer failed per ROW, not per table, and only for the rows whose generated value was non-NULL.
+
+  That selectivity is the dangerous part. `.uniqueActive()` lowers to exactly such a column on mysql/mariadb — a STORED generated column holding the key while the row is live and NULL once it is soft-deleted — so the refused rows are the LIVE ones and the accepted ones are the tombstones. A table can come out looking like "a few rows failed" or empty, depending only on how many of its rows are deleted, and any table with a foreign key into it fails behind it.
+
+  Both ends are fixed from one source of truth: **introspection now reports generated columns on every dialect** (`generatedAs`, from `information_schema.generation_expression` on mysql/mariadb, `is_generated` on postgres, `PRAGMA table_xinfo`'s hidden flag on sqlite, `sys.computed_columns` on mssql). It was declared-side only before — invisible to the planner, which does not compare it, and load-bearing for anything that writes rows back.
+
+  The exporter omits those columns, values and all. The importer strips them from every incoming row using the TARGET's snapshot, because a bundle already written still carries them and a file on disk is data, read where it is.
+
+  **`voltro serve`'s admin export/import needed a second fix, and without it this one reached only the direct transport.** The running instance hands those handlers `declaredSnapshot(tables)` — no dialect — and `.uniqueActive()` lowers to a generated column only when the snapshot knows the engine. So over `--target api` the snapshot described a schema with no generated columns while the database had several, and the export wrote their values back into the bundle exactly as before. It passes the dialect now (the variable was already on the next line).
+
+  `generatedAs` is also kept OUT of the schema fingerprint. Introspection can read the fact back but not a comparable value — the engine returns its own normalisation of the expression, never the declared spelling — so hashing it would make declared and live disagree permanently: a schema nobody touched reporting a changed declaration on every boot, and a transfer target that matches its bundle exactly refused as drifted.
+
+  Covered by a live mariadb→mariadb and mysql→mysql round trip over a `.uniqueActive()` table with live and soft-deleted rows, asserting the target recomputed the value rather than that the row merely arrived.
+- **@voltro/sql-mysql** — On mysql/mariadb, a write REJECTED by the database through `insertIgnore` was reported as a conflict when the caller was not inside a transaction — and never reached the caller as a typed `ConstraintViolation` at all.
+
+  Two causes, both measured against live MySQL 8.4 and MariaDB 11.
+
+  **The connection.** `INSERT IGNORE` demotes every error to a warning, so the store reads `SHOW WARNINGS` to tell a rejection from a conflict. That describes the last statement on a CONNECTION, and outside a transaction every statement acquires its own from the pool — so the read was unattributable and came back empty. The rejected write then surfaced as "the insert was skipped as a conflict, but no existing row matches conflictColumns […] the constraint that fired is unknown", whose enumeration lists only conflict causes. A rejection described as a conflict is the exact sentence this path was fixed once already for producing; it survived on the path that had no transaction to read on. The store now pins one connection for the whole decision — the same pinning `insertRecoverAutoId` does for `LAST_INSERT_ID()`.
+
+  **The classification.** The store swallowed the driver's error and raised a prose one of its own, so `classifyConstraintViolation` had nothing to read: this was the one write path where the typed error could not fire, while every other one produced it. The warning IS the driver's payload — `INSERT IGNORE` only changed how it was delivered — so it is handed on in the shape the driver would have thrown. A rejection now arrives as the same `ConstraintViolation { kind: 'foreignKey', … }` a plain `insert` produces. Nothing new crosses the wire: the classifier extracts the constraint NAME as a delimited group, never the sentence.
+
+  This is the default `voltro data import` path (`--mode append`, `--on-conflict skip`, without `--atomic`), so a row rejected by a foreign key was reported to the operator as a conflict with an unknown cause.
+
+  `constraintViolation.integration.test.ts` now asserts the `insertIgnore` seam per dialect against live postgres 17, MySQL 8.4, MariaDB 11 and SQL Server 2022. It was the missing assertion behind a claim derived from the wiring — the classification does sit on all ten write paths, which is not the same as a classifiable error arriving on all ten.
+- **@voltro/protocol, @voltro/runtime** — The framework's store errors — `ConstraintViolation`, `TenantScopeViolation`, `TenantRowNotFound`, `ServerOnlyColumnWrite`, `TableValidationFailed`, `StoreOperationFailed` — are exported from `@voltro/protocol` and can therefore be declared in a descriptor's `error:` union. They could not be.
+
+  They lived in `@voltro/runtime`, which reaches `node:child_process`, `node:http` and `node:crypto`. A descriptor is loaded VALUE-LEVEL by the web client (the `RpcClient` needs every procedure's Schema), so a descriptor importing from there is refused at boot by the browser-safety guard — correctly. The typed half of these errors was therefore unreachable: the docs told you to declare them, and the boot said no.
+
+  What that leaves is the untyped half only. The error still arrives as an `InternalError` carrying a readable sentence, so telling `foreignKey` ("the row you picked is gone") from `foreignKeyInUse` ("this row is still referenced") — two different messages for the user — means parsing that sentence. Over a set of generated delete mutations that is a string comparison per procedure, which is the thing the typed error exists to delete.
+
+  `@voltro/runtime` re-exports all six, so server code is unchanged. The classes have no server dependency of any kind — the file imports `Schema` from `effect` and nothing else, and `browserSafetyGuard.test.ts` now pins a descriptor that declares one, so moving them back reads as a boot failure rather than as a passing rename.
+- **@voltro/database, @voltro/sql-mysql** — A blocked `alter-column-type` told every dialect to write a postgres cast.
+
+  The refusal is correct — a bare type change may not be value-preserving, so it is refused until acknowledged. Its `fix:` line was not:
+
+  ```
+  acknowledge it on the column: `.narrowedFrom('json', { using: 'meta::text' })`
+  ```
+
+  `USING <expr>` is postgres syntax and a postgres capability. The mysql arm of the applier emits `MODIFY COLUMN`, the mssql arm `ALTER COLUMN`, and sqlite rebuilds the table — none of them can carry a cast expression and none of them reads `using`. So an operator on any other engine was handed a line to paste into their schema containing syntax their database has never seen, inside an argument that is discarded. A refusal is read as an instruction, and the more carefully it is read the more thoroughly a wrong one is followed.
+
+  The fix line is dialect-aware now: postgres keeps the `using` half, everything else gets `.narrowedFrom('<type>')` plus the fact that the engine converts in place — because a refusal that offers no expressible fix reads as "the framework cannot do this at all".
+
+  Covered on live MySQL and MariaDB by both halves at once: what the refusal SAYS, and that following it applies AND converges with the row intact. A message test alone would keep passing over a broken apply; a convergence test alone is what let the wrong message survive this long.
+
+  Also on the same path: `upsert` with a PARTIAL row (one omitting a NOT NULL column that has no default) failed on MariaDB and succeeded on MySQL. The native `INSERT … ON DUPLICATE KEY UPDATE` validates its insert half even when only the update half runs, so the row was rejected although the target existed and only needed patching. A partial row takes the lookup path on both engines now; the single-statement form still covers the complete-row case, which is what a data transfer and every generated CRUD write send.
+- **@voltro/sql-mysql** — On MariaDB, `upsert` could write a DIFFERENT row than the one it was given and report success.
+
+  `INSERT … ON DUPLICATE KEY UPDATE` fires on ANY unique key, not on the one named in `conflictColumns`. So an incoming row whose (say) `email` already belonged to a different primary key updated THAT row instead — and since `id` is excluded from the SET list, the row the caller handed over was never written. Measured on a live server: the call returned a row, the target kept the old id, the new row was absent, and the existing row had silently taken the incoming values. A bulk transfer on top of that prints `import complete` over missing data, which is the worst failure shape available: there is nothing to investigate.
+
+  The two engines of the family disagreed here, which is part of why it survived. The non-RETURNING path (MySQL) looks the row up by `conflictColumns` first, does not find it, and lets the INSERT fail with a duplicate-key error. Loud was always right.
+
+  Both refuse now, with a message naming both ids and the fact that the collision was on a constraint other than the one named. The check runs inside a transaction — a short one of the store's own when the caller is not already in one — so the wrong row is rolled back rather than reported after the fact: detecting this afterwards still leaves someone else's row overwritten.
+
+---
+
+## [0.42.0] — 2026-08-17
+
+### ⚠ BREAKING
+
+- **@voltro/cli, @voltro/data-transfer** — **Two security defects on the data-transfer surface, both found by using the feature rather than by reading it.**
+
+  **A `{ profile }` in an admin-export request could name a PATH.** `loadProfile` resolved the client's string with `resolve(cwd, x)` — which returns an absolute path unchanged and lets `../` traverse — and the resolved file is `await import()`ed, which RUNS it. So a holder of the data-transfer secret could make the api process execute any file on the pod: an escalation from "can export prod data" to "can run code", and chainable on an instance whose object storage is a filesystem the same caller can write to.
+
+  `POST /_voltro/admin/export` now accepts a NAME only — `[A-Za-z0-9_-]{1,64}`, resolved under `data-profiles/` and checked to be contained there. **Migration: if you passed a path over `--target api`, move the file to `data-profiles/<name>.ts` and pass `<name>`.** `voltro data export --profile` on a DIRECT target still accepts a path: it runs on the operator's own machine, where a path is not an escalation. No user-authored code changes, so `codemod: none`.
+
+  **An unrecognised masking action copied the value through.** `applyAction` ended in `return input.value`, so a profile with a typo in the action shape (`{ action: 'fake', kind: 'email' }` instead of `{ fake: 'email' }`) exported every row of a `.sensitive()` column verbatim — with a 200 and an audit line counting the column as masked. Measured against a live instance: a masked export of two users came back carrying both real addresses.
+
+  The applier now throws, and `planMasking` refuses the policy BEFORE a row is read: `MaskingError` gained `invalidActions`, reported separately from `unclassified` because the fixes differ — one needs a classification, the other needs the policy corrected.
+
+### Added
+
+- **@voltro/runtime** — A write the database refuses on an integrity rule now raises a typed `ConstraintViolation` instead of an opaque `SqlError`. It carries `{ kind, table, operation, constraint?, column? }`, where `kind` is one of `foreignKey` · `foreignKeyInUse` · `unique` · `notNull` · `check`. Declare it in a procedure's `error:` to pattern-match it; undeclared it still reaches the client as an `InternalError` carrying its own sentence rather than `Failed to execute statement`.
+
+  It carries NAMES and never the driver's message, which on most engines contains row data — postgres attaches the complete failing row to a not-null and a check violation, mysql and mssql echo the duplicate value. Classification is measured against live postgres 17, MySQL 8.4, MariaDB 11, SQL Server 2022 and sqlite.
+
+  Raised from one guard covering every write op (insert · insertMany · upsert · insertIgnore · update · updateMany · delete · deleteMany · hardDelete · patchJson); the tenant-FK case still resolves to `TenantScopeViolation` first.
+
+### Fixed
+
+- **@voltro/cli, @voltro/data-transfer** — `voltro data import|export` — four defects on the `--target api` path, all found by a consumer seeding a fresh cluster from a bundle.
+
+  **A flag this command does not read is now an ERROR.** `--dry-run` and `--tables` were accepted on the import path and dropped in silence: a preview against a production-shaped cluster ran the import instead (2905 rows, then a 500), and a run narrowed to a one-row table wrote all 10 593. Both are one defect — an argument parser that ignores what it does not understand — so every `voltro data` subcommand now declares the flags it reads per target and refuses the rest, naming the flag and what to use instead.
+
+  **`--dry-run` and `--tables` now work on the import, on BOTH targets.** A dry run reaches every verdict a real run reaches (schema fit, cross-dialect portability, mode legality, the table selection) and stops before the first write; the api path carries them as `x-import-dry-run` / `x-import-tables` and echoes `{ dryRun: true, wrote: false }`. A `--tables` name the bundle does not carry is refused, listing what it does. `--dry-run` on an api EXPORT is refused rather than ignored — previewing a read protects nothing.
+
+  **The schema-drift pre-flight compares the INTERSECTION, not whole schemas.** A bundle's fingerprint covers its source schema regardless of export scope, and two environments never have identical whole schemas, so the check refused every cross-environment seed with a diff whose every line said the difference changes nothing — making `--force` the routine way to import and removing the protection it guards. It now reports only what would break the load: a carried table or column the target lacks, a type mismatch, or a column the target REQUIRES that the bundle carries no value for.
+
+  **A failed row says why.** `reason` was `Failed to execute statement` for every one of 2905 rows. It now names the constraint and the rule (`foreign key tasks_laneId_fkey: the referenced row does not exist [23503]`), or the driver's own message with its code, or — where there is no driver under the failure — the error from the layer that refused.
+
+  Also: `voltro data inspect` accepts a directory bundle instead of dying inside the archive reader with a JSON parse error (`--target api` always unpacks into a directory, even when the path ends in `.vbundle`).
+
+  **Three more, found by running the whole thing against live MariaDB and MySQL** rather than against sqlite:
+
+  - A re-run of a COMPLETED import wrote nothing and reported the bundle's full row count — the resume ledger lives in the bundle directory, so truncating a target and re-importing printed `import complete … 10593 rows` over an empty database. Resume is right; being quiet about it was not. It now warns, names the skipped tables, and says which ledger file to delete. - The deferred-FK recovery pass OVERWROTE the diagnosis. When a held row cannot be written, the resolver retries it with every `reference` column nulled to break a cycle — and that attempt's failure replaced the original reason, so a row whose real problem was one column reported a not-null violation on a column the framework itself had nulled. The recovery attempt no longer records a reason. - MySQL/MariaDB errno **1364** (a statement that OMITS a column which is NOT NULL with no default) is classified as a not-null violation. postgres reports 23502 for that situation and mssql 515, so the mysql family was the only one where "you did not supply a required column" came back unclassified.
+- **@voltro/database** — CHECK constraints were invisible to introspection on **MySQL** — and with them every `.oneOf()` column and every `json_valid` marker.
+
+  `information_schema.check_constraints` differs between the two engines of the family: MariaDB carries `TABLE_NAME`, MySQL does not have that column at all. The introspector selected it, the query errored, and an `Effect.orElseSucceed` turned that into an empty list. A swallowed error and an empty result read identically, which is why this needed a two-engine test to surface. The query JOINs `information_schema.table_constraints` for the name now, which both engines answer.
+
+  `parseEnumCheck` also learned MySQL's rendering. The same clause is stored differently:
+
+  mariadb 11 `status` in ('draft','live','done') mysql 8.4 (`status` in (_latin1'draft',_latin1'live',_latin1'done'))
+
+  MySQL puts a charset introducer before each literal, which the pattern — written against MariaDB's form — did not read. Both are pinned in `enumCheckParity.test.ts`.
+
+  Neither fix completes the round trip on MySQL: `.oneOf()` still comes back unclassified there. That is asserted as a known gap in `oneOfCheck.mariadb.integration.test.ts` (which fails the moment it starts working) and written up in `plans/open/framework/mysql-oneof-roundtrip.md`.
+- **@voltro/database** — `voltro db apply` works on MySQL. It could not create a table with an index, and could not drop a column, on that engine at all.
+
+  `IF [NOT] EXISTS` outside `CREATE`/`DROP TABLE` is a MariaDB extension — MySQL rejects it with ER_PARSE_ERROR (measured on 8.4 for `CREATE INDEX IF NOT EXISTS`, `ALTER TABLE … DROP COLUMN IF EXISTS`, and `ADD COLUMN IF NOT EXISTS`). The applier emitted the first two, because `@effect/sql-mysql2` reports the dialect `mysql` for both engines and the shared branch had only ever run against MariaDB. A `reference()` column gets an index by default, so in practice most tables were affected.
+
+  The applier now asks the SERVER which engine it is (`SELECT VERSION()`; MariaDB stamps itself into the string) and emits the plain form on MySQL. The idempotency `IF [NOT] EXISTS` provided moves into the statement runner, which tolerates exactly the errnos meaning "already in the requested state" — 1061 for a duplicate index name, 1091 for dropping something absent. The engine is read from the connection rather than from `DB_DIALECT` or `variant`, because the DDL has to be legal for the server that receives it and those are what an operator typed.
+
+  Verified against live MySQL 8.4 and MariaDB 11: a schema evolution — create, add column, add index, drop column — applied through `applyPlan` on both, converging at every step, plus a replayed plan (what a resume does) that must not error on the statements it repeats.
+
+  **sqlite had the same defect, found by the new cross-dialect scenario on its first run.** `ALTER TABLE … DROP COLUMN IF EXISTS` is accepted by postgres, mssql and MariaDB and rejected by sqlite — and the generic emitter, shaped for postgres, is what sqlite used. So `voltro db apply` could not drop a column on sqlite either. The conditional form is now emitted only where it is legal, and the "already dropped" case is tolerated per dialect (`idempotentDdl.ts`).
+
+  `runDialectParity` gained a schema-evolution scenario — create, add column, add index, drop column, applied for real with a convergence check after each step — so the migration APPLIER is now covered on all five dialects. It previously had one scenario covering one op kind, while twenty-two covered the store; that split is why four emitter defects survived.
+
+  **And a fifth, found by making one MariaDB-only suite two-sided.** `text().unique()` on an unbounded text column created a table on MariaDB and failed the CREATE outright on MySQL: `BLOB/TEXT column 'x' used in key specification without a key length`. The bring-up emitter (`migrate.ts`) wrote an inline `UNIQUE`; the declarative applier had always written a separate PREFIXED unique index. The two emitters disagreeing on one statement is the failure shape this package's own notes describe, and only one engine said so.
+
+  `migrate.ts` emits the prefixed index now, through the same `indexStmt` that already owns the per-dialect `IF NOT EXISTS` rule, and names it `<table>_<column>_key` to match the applier's — so the two paths produce the same object.
+
+  **Note the behaviour change on MariaDB.** It accepted the inline form by backing it with a HASH long-unique index, whose hidden `DB_ROW_HASH_n` column breaks the binlog CDC reader (documented in `packages/database/CLAUDE.md`). Uniqueness on such a column is now enforced on the first 191 characters rather than the whole value — which is what `voltro db apply` already did, and what MySQL can express at all. Bound the column with `text().maxLength(n)` if you need full-value uniqueness.
+- **@voltro/sql-mysql** — `insertIgnore` on MySQL was a different feature from `insertIgnore` on MariaDB — and the difference could turn a conflict into an error.
+
+  The whole diagnostic apparatus — the refusal to report a REJECTED write as a conflict, and the message naming the constraint that actually fired — sat behind a `variant === 'mariadb'` branch. MySQL took an `else` that used no `INSERT IGNORE` at all: look for a row matching the conflict columns, insert if there is none. That cannot hold the one property the method exists for. A caller that looks before anyone else writes sees nothing, so the write it then makes is the one that raises the duplicate-key error `insertIgnore` promises never to raise — reproduced deterministically against both engines with an uncommitted holder (the lookup cannot see the holder's row; the insert cannot proceed until it commits).
+
+  Underneath sat the reason a straight port would still have produced nothing: **MySQL answers a PREPARED `SHOW WARNINGS` with 1295 ER_UNSUPPORTED_PS**, and the warning read is deliberately failure-tolerant (a diagnostic must never replace the caller's real problem), so it returned an empty list — indistinguishable from a statement that raised nothing. MariaDB accepts both protocols. The read goes through the text protocol now, the same spelling the binlog path already used for `SHOW MASTER STATUS`.
+
+  Both engines now run one `INSERT IGNORE` and reach one decision function. What differs is only the probe for "did it land": MariaDB has `INSERT IGNORE … RETURNING *`; MySQL has no RETURNING, so the row's own key answers instead. `SELECT ROW_COUNT()` — the obvious alternative — cannot be used: measured on both engines, it reports 1/0 correctly but CLEARS the warning list on MySQL, and run the other way round returns `-1` because `SHOW WARNINGS` is then the last statement. The count and the diagnosis cannot both be had; the diagnosis is the one worth having.
+
+  Found by converting the suite that covers this to run on both engines, which is also where every MySQL assertion in it had been reporting the driver's generic `Failed to execute statement`.
+- **@voltro/database** — A `reference()` column now creates a real foreign key on **MySQL**. It did not before: MySQL/InnoDB parses a column-inline `REFERENCES` clause and discards it — no constraint, no warning, the `CREATE TABLE` succeeds — while MariaDB honours the identical clause. Both engines reach the same emitter (the driver reports the dialect `mysql` for either), and every mysql-family integration suite in the repo runs against MariaDB, so referential integrity that postgres, MariaDB, mssql and sqlite all enforced was silently absent on MySQL.
+
+  Both emitters now write a table-level `CONSTRAINT <table>_<column>_fkey FOREIGN KEY …` inside the `CREATE TABLE`, which both engines honour and which `CREATE TABLE IF NOT EXISTS` keeps idempotent. Existing MariaDB schemas are unaffected — the introspected snapshot carries no constraint name, so nothing re-plans.
+
+  Verified against live MySQL 8.4: the constraint is in the catalog, the server refuses an orphan row, introspection reads it back, and the re-plan is empty.
+- **@voltro/sql-turso, @voltro/testing** — A migration on turso applied correctly and then reported itself as failed: `voltro db apply` ran an `add-column`, re-planned to prove convergence, saw the column still missing, proposed the same operation again, and the second execution died with `duplicate column name`. No fingerprint was recorded, so every subsequent boot re-proposed the same work — and the error named the migration applier, which had done nothing wrong.
+
+  The client caches one prepared statement per connection per SQL text, and a prepared statement carries the schema it was prepared against. So a cached `PRAGMA table_info(t)` keeps answering with the old columns after a DDL — it is never re-prepared, so sqlite's schema-cookie re-preparation never runs. The invalidation for this existed, on the unprepared path (`sql.unsafe`) only, and the migration path sends its DDL through the PREPARED one. The statement that changed the schema and the cache that had to be dropped were on the same connection, one function apart, with nothing connecting them.
+
+  Any schema-changing statement now drops that connection's cached statements, whichever path it arrived on.
+
+  Three hypotheses were measured and disproven before this one — an applier retry (each operation is issued once), an MVCC snapshot (two raw libsql clients both see the DDL), and a pool-wide cache problem (four connections held open together, the PRAGMA prepared on each, a DDL on one: the other three answer correctly, because SQLite bumps the schema cookie and the driver re-prepares on the connections that did not make the change).
+
+  The two `runDialectParity` scenarios that drive the migration applier were skipped for turso on the strength of that misreading. They run now, and the per-fixture opt-out that carried the skip is deleted: it was holding a defect open while reading like a documented limitation.
+
+  **`apiSurface: compatible`, and the reason is a date rather than an argument.** Removing `DialectFixture.skipApplierScenarios` moves a line in `@voltro/testing`'s golden, so the changelog's narrowing detector flags it — and it is right to, because that detector's baseline is `origin/main`. But the field never reached a RELEASE: it was added after `v0.41.0` and deleted before this one, both inside the same unreleased range. `git show v0.41.0:packages/testing/etc/testing-dialect.api.md` does not contain it. No published version ever offered it, so no consumer can have set it, and there is nothing to migrate.
+
+  Worth writing down because the first reading of this was wrong in the safe direction: it was filed `BREAKING` with a codemod on the strength of "an optional field disappeared from a published package's surface", which is the right instinct and the wrong conclusion here. **"Removed relative to main" is not "removed relative to what users have"** — a symbol that lives and dies between two tags trips the detector while breaking nobody, and the difference is only visible by asking the last TAG rather than the last commit.
+
+---
+
 ## [0.41.0] — 2026-08-17
 
 ### ⚠ BREAKING

package/dist/index.d.ts

@@ -5,12 +5,16 @@ import { AuthMiddleware } from '@voltro/protocol';
 import { AuthStrategy } from '@voltro/protocol';
 import { CaughtUpVerdict } from '@voltro/database';
 import { ChangeEvent } from '@voltro/database';
+import { classifyConstraintViolation } from '@voltro/database';
 import { clearRetentions } from '@voltro/database';
 import { ConnectionCredential } from '@voltro/protocol';
 import { ConnectionInfo } from '@voltro/protocol';
 import { ConnectionInfoMiddleware } from '@voltro/protocol';
 import { ConnectionKind } from '@voltro/protocol';
 import { ConnectionState } from '@voltro/protocol';
+import { ConstraintFacts } from '@voltro/database';
+import { ConstraintKind } from '@voltro/database';
+import { ConstraintViolation } from '@voltro/protocol';
 import { Context } from 'effect';
 import { createServer } from 'node:http';
 import { Cron } from 'effect';
@@ -27,6 +31,7 @@ import { EventPayloadInvalid } from '@voltro/protocol';
 import { EventPayloadTooLarge } from '@voltro/protocol';
 import { EventResumePoint } from '@voltro/protocol';
 import { EventStreamEvent } from '@voltro/protocol';
+import { extractDbCause } from '@voltro/database';
 import { Fiber } from 'effect';
 import { FieldCipher } from '@voltro/database';
 import * as http from 'node:http';
@@ -40,6 +45,8 @@ import { InspectedStep } from '@voltro/workflow';
 import { InspectedWorkflow } from '@voltro/workflow';
 import { InspectStore } from '@voltro/workflow';
 import { inspectWorkflow } from '@voltro/workflow';
+import { isForeignKeyViolation } from '@voltro/database';
+import { isQueryTimeout } from '@voltro/database';
 import { Kv } from '@voltro/kv';
 import { KvStoreShape } from '@voltro/kv';
 import { Layer } from 'effect';
@@ -70,9 +77,12 @@ import { Sampler } from '@opentelemetry/sdk-trace-base';
 import { Schedule } from 'effect';
 import { Schema } from 'effect';
 import { ScopeError } from '@voltro/protocol';
+import { ServerOnlyColumnWrite } from '@voltro/protocol';
 import { SpanProcessor } from '@opentelemetry/sdk-trace-base';
 import { spawn } from 'node:child_process';
 import { SqlClient } from '@effect/sql';
+import { StoreError } from '@voltro/protocol';
+import { StoreOperationFailed } from '@voltro/protocol';
 import { Stream } from 'effect';
 import { Subject } from '@voltro/protocol';
 import { SubjectResolution } from '@voltro/protocol';
@@ -81,6 +91,9 @@ import { SubscriptionEvent } from '@voltro/protocol';
 import { sweepRetention } from '@voltro/database';
 import { SyncLogger } from '@voltro/logger';
 import { TableLike } from '@voltro/database';
+import { TableValidationFailed } from '@voltro/protocol';
+import { TenantRowNotFound } from '@voltro/protocol';
+import { TenantScopeViolation } from '@voltro/protocol';
 import { Tracer } from 'effect';
 import { Unauthenticated } from '@voltro/protocol';
 import { WorkflowParentClosePolicy } from '@voltro/protocol';
@@ -1001,7 +1014,7 @@ export declare interface AppContext {
      *
      * This was typed as the OLD string-emitter facade (`emit(name, data)`) long
      * after that facade was deleted, so the documented call was a `tsc` error
-     * while the runtime carried only `publish` — a consumer measured
+     * while the runtime carried only `publish` — a deployment measured
      * `eventKeys: ["publish"], emitType: undefined` with a cron probe because the
      * type and the docs disagreed and they could not tell which was lying.
      *
@@ -1510,7 +1523,7 @@ export declare const bindMutation: <Input, Output, E = never>(execute: (input: I
  * ~2 KB for a one-line cause, with the message at the END so every tool that
  * truncates shows the useless half.
  *
- * A consumer met it with `TenantScopeViolation`. Adding that tag to
+ * A deployment met it with `TenantScopeViolation`. Adding that tag to
  * `INFRA_ERROR_TAGS` would have been wrong: `effectStore.ts` documents
  * `error: Schema.Union(TenantScopeViolation, StoreOperationFailed, …)` as a
  * supported declaration, so an app that DECLARES it must still receive it
@@ -1692,7 +1705,7 @@ export declare interface CacheScopeLeak {
  * serving another org's rows out of memory, with a TTL. The author has to be
  * wrong exactly once, in a field whose two legal values differ by one word.
  *
- * A consumer named this precisely while asking for the third option: *"'global'
+ * A deployment named this precisely while asking for the third option: *"'global'
  * would share across tenant boundaries. For data derived from
  * `subject.tenantId` that is not a cache, it is a leak."* They chose to
  * recompute an org-wide figure once per employee rather than write it — the
@@ -1864,6 +1877,8 @@ export declare const CLAIM_RETENTION_BUCKETS = 64;
  */
 export declare const claimGraceMs: (bucketWidthMs: number | undefined) => number;
 
+export { classifyConstraintViolation }
+
 /**
  * Decide whether a state-changing request may proceed.
  *
@@ -2129,6 +2144,12 @@ export declare interface ConnectionTokens {
     readonly scopes: ReadonlyArray<string>;
 }
 
+export { ConstraintFacts }
+
+export { ConstraintKind }
+
+export { ConstraintViolation }
+
 export declare type CoordinatedEffect = () => void | CoordinatedTickOutcome | Promise<void | CoordinatedTickOutcome>;
 
 export declare interface CoordinatedScheduleDeps {
@@ -2827,7 +2848,7 @@ export declare const DEFAULT_ROW_FILTER_RETRY: Schedule.Schedule<unknown, unknow
  * `error:` union. It cannot match, by definition: a defect is precisely the
  * thing that is not in the union. What reached the browser was the entire
  * decode tree — every union member, the full `ExitEncoded<…>` type, and the
- * real cause on the last line. ~2 KB of type names, which one consumer's
+ * real cause on the last line. ~2 KB of type names, which one deployment's
  * account page rendered verbatim where a reason belonged, and which every app
  * otherwise has to condense heuristically to avoid putting a schema on screen.
  *
@@ -3010,7 +3031,7 @@ export declare class DeleteBuilder {
  *  nothing at all. Reporting a fixed 1 for all of them (which this used to do)
  *  turned the `rows` attribute into a liveness signal that reads like a data
  *  signal: an `employees.me` that resolved to `null` still traced `rows=1`, and
- *  a downstream consumer used exactly that span to conclude the server had
+ *  a downstream deployment used exactly that span to conclude the server had
  *  produced a value when it had not. Absent is 0, a single value is 1, an array
  *  is its length. */
 export declare const deliveredRowCount: (value: unknown) => number;
@@ -3274,7 +3295,7 @@ export declare const drainForShutdown: (options: {
     readonly exit: () => void;
     /** How the drain ended, for the caller to report. A completed drain and one
      *  CUT at the deadline are different incidents and were indistinguishable in
-     *  the log — asked for by a consumer who could see neither. */
+     *  the log — asked for by a deployment who could see neither. */
     readonly onOutcome?: (outcome: {
         readonly reason: "drained" | "deadline";
         readonly ms: number;
@@ -3363,7 +3384,7 @@ export declare const enableGraphObservation: () => void;
  * `cipher.encrypt(JSON.stringify(v))` — two encodings, one `enc:v1:` envelope,
  * nothing to tell them apart. The doc above promises these helpers "expose the
  * SAME registered cipher so those paths can encrypt on write and decrypt on read
- * by hand", and a consumer read that as interchangeable, which it said and was
+ * by hand", and a deployment read that as interchangeable, which it said and was
  * not: their session rows written here were unreadable through the store, and
  * the error blamed the key.
  */
@@ -3546,7 +3567,7 @@ export declare class EventBus {
         /**
          * Called SYNCHRONOUSLY at attach with the route's current watermarks.
          *
-         * It is how a consumer learns where the stream stood the instant it joined,
+         * It is how a deployment learns where the stream stood the instant it joined,
          * with no window for a publish to slip in between reading and subscribing.
          * The bridge needs it because a delivery dropped BEFORE the client's first
          * read would otherwise be invisible: with no baseline, the first serial it
@@ -3562,7 +3583,7 @@ export declare class EventBus {
      * since its last serial (from the watermark, which survives ring eviction);
      * `replayed` is what we can actually hand over. An origin the client never
      * mentioned is one that appeared while it was away, so everything retained
-     * from it is owed. A `gap` is emitted BEFORE the replay so a consumer reading
+     * from it is owed. A `gap` is emitted BEFORE the replay so a deployment reading
      * in order learns it is behind before it starts processing.
      */
     private replayForResume;
@@ -3649,7 +3670,7 @@ export declare interface EventEnvelope {
     /** `tenant · event · key`, NUL-separated — built by `eventRoute`, read with
      *  `parseEventRoute`. Never construct or split one by hand. */
     readonly route: string;
-    /** Declared event name, carried separately so a consumer of the raw envelope
+    /** Declared event name, carried separately so a deployment of the raw envelope
      *  (broadcast bridge, inspect, metrics) needn't re-parse the route. */
     readonly event: string;
     /** Publishing instance. Serials are only comparable WITHIN one origin. */
@@ -4304,7 +4325,7 @@ export declare interface ExperimentVariantSpec {
  *  when the header is missing/invalid (no parent → a fresh root span). */
 export declare const externalSpanFromTraceparent: (header: string | undefined | null) => Tracer.ExternalSpan | undefined;
 
-export declare const extractDbCause: (err: unknown) => Record<string, unknown>;
+export { extractDbCause }
 
 export declare interface FieldChange {
     readonly from: unknown;
@@ -4877,10 +4898,7 @@ export declare const isExpectationDefinition: (value: unknown) => value is Expec
 
 export declare const isExperimentDefinition: (value: unknown) => value is ExperimentDefinition;
 
-/** Foreign-key-violation SQLSTATE / errno across dialects (pg 23503, mysql/maria
- *  1452, mssql 547, sqlite). Used to turn an opaque tenant-FK SqlError into a
- *  typed error. */
-export declare const isForeignKeyViolation: (dbCause: Record<string, unknown>) => boolean;
+export { isForeignKeyViolation }
 
 /**
  * True iff the app is idle at this instant on every axis AND no wakeup is
@@ -4935,14 +4953,7 @@ export declare const isOrglessUserSubject: (subject: {
     readonly tenantId?: string | null;
 } | null | undefined) => boolean;
 
-/** A query cancelled for exceeding the `statementTimeoutMs` deadline, across
- *  dialects: pg `57014` (query_canceled — what `statement_timeout` raises),
- *  MySQL `3024` (ER_QUERY_TIMEOUT), MariaDB `1969` (ER_STATEMENT_TIMEOUT), mssql
- *  `ETIMEOUT` (tedious request timeout), sqlite `SQLITE_INTERRUPT`. NOT a
- *  transient error — a re-run just repeats the runaway, so it must not retry
- *  (`servePipeline`'s transient set deliberately excludes it). Lets a consumer /
- *  observability layer name the failure instead of reading an opaque SqlError. */
-export declare const isQueryTimeout: (dbCause: Record<string, unknown>) => boolean;
+export { isQueryTimeout }
 
 /**
  * Optimistic-concurrency guard: an undo is safe only when the row still looks
@@ -5200,7 +5211,7 @@ export declare const makeActionRunner: (deps: ActionRunnerDeps) => (action: Muta
  *
  * The bucket keying makes claims self-expiring as a DECISION: a crashed
  * winner doesn't block the next firing (= next bucket = new key). It did
- * not make them self-expiring as ROWS, and that distinction cost a consumer
+ * not make them self-expiring as ROWS, and that distinction cost a deployment
  * their whole deployment — 86 214 rows / 33 MB over two days, read in full
  * on every claim check, ten of a fifteen-slot pooler pinned on the scan, an
  * SSR render behind them at 300 490 ms, and a `rollout restart` that could
@@ -5644,7 +5655,7 @@ export declare const materializeIvm: (shape: AggregateShape, state: IvmState) =>
 }>;
 
 /** Told when the membership changes. `restarted` is a `left` + `joined` pair
- *  for one id, reported as such so a consumer drops the old state rather than
+ *  for one id, reported as such so a deployment drops the old state rather than
  *  resuming it. */
 export declare type MembershipEvent = {
     readonly kind: 'joined';
@@ -5668,7 +5679,7 @@ export declare interface MembershipHeartbeat {
      *
      * Carried as an IDENTITY, never compared to our clock. Its job is to make a
      * restart distinguishable from a hiccup: an instance that comes back with a
-     * NEW `startedAt` is a fresh process whose owned state is gone, so a consumer
+     * NEW `startedAt` is a fresh process whose owned state is gone, so a deployment
      * must drop what it held for the old one rather than resume it. A returning
      * instance with the SAME value only ever missed a few beats.
      */
@@ -8741,32 +8752,7 @@ export declare interface ServeRequestContext {
  */
 export declare const serverOnlyColumnNames: (tableName: string) => ReadonlyArray<string>;
 
-/**
- * A generated CRUD write (`crud.create` / `crud.update`) was handed a
- * `.serverOnly()` column in its INPUT.
- *
- * `.serverOnly()` is the WIRE-exposure axis: the column never crosses the
- * boundary in EITHER direction. Reads strip it; a write that accepts it is the
- * same violation mirrored — mass assignment of a column the schema declared the
- * client may not see, let alone set.
- *
- * Refused rather than silently stripped: a stripped field makes an attack
- * indistinguishable from a no-op and leaves an honest caller wondering why the
- * value it sent never landed. `columns` names what was rejected so the fix
- * (drop the field from the descriptor's input schema, or from the caller) is
- * mechanical.
- */
-export declare class ServerOnlyColumnWrite extends ServerOnlyColumnWrite_base {
-}
-
-declare const ServerOnlyColumnWrite_base: Schema.TaggedErrorClass<ServerOnlyColumnWrite, "ServerOnlyColumnWrite", {
-    readonly _tag: Schema.tag<"ServerOnlyColumnWrite">;
-} & {
-    /** The table the write targeted. */
-    table: typeof Schema.String;
-    /** The `.serverOnly()` columns the input tried to set. */
-    columns: Schema.Array$<typeof Schema.String>;
-}>;
+export { ServerOnlyColumnWrite }
 
 /** One leak: a wire query that declares a serverOnly column in its output. */
 export declare interface ServerOnlyLeak {
@@ -9041,12 +9027,7 @@ export declare interface StoreCredentialInput {
     readonly now?: () => Date;
 }
 
-/**
- * Discriminated union of all framework-owned store errors. Use it on
- * a mutation's `error:` schema when you want every kind surfaced
- * typed to the client.
- */
-export declare type StoreError = TenantScopeViolation | TenantRowNotFound | ServerOnlyColumnWrite | StoreOperationFailed | TableValidationFailed;
+export { StoreError }
 
 export declare interface StoreMiddlewareContext {
     readonly subject: Subject;
@@ -9072,25 +9053,7 @@ export declare interface StoreMiddlewareContext {
     readonly rowFilter?: RowFilterScope;
 }
 
-/**
- * Anything else the underlying `DataStore` raised during a write or
- * query. `cause` is the stringified original error — sufficient for
- * logs + UI, doesn't try to serialise complex error chains across the
- * rpc boundary. The `_tag` discriminator stays cheap to pattern-match.
- */
-export declare class StoreOperationFailed extends StoreOperationFailed_base {
-}
-
-declare const StoreOperationFailed_base: Schema.TaggedErrorClass<StoreOperationFailed, "StoreOperationFailed", {
-    readonly _tag: Schema.tag<"StoreOperationFailed">;
-} & {
-    /** Which DataStore op was attempted: 'query' | 'insert' | 'update' | 'delete' | 'hardDelete'. */
-    operation: typeof Schema.String;
-    /** The table the op targeted. */
-    table: typeof Schema.String;
-    /** `String(originalError)` — round-trip-safe diagnostic form. */
-    cause: typeof Schema.String;
-}>;
+export { StoreOperationFailed }
 
 /**
  * Drop `columns` from every row. Preserves array AND per-row object identity when
@@ -9363,30 +9326,7 @@ export declare interface TableRoutingStats {
     readonly distinctTupleKeys: number;
 }
 
-/**
- * Pre-INSERT row validation against a table's `.validate(Schema)`
- * decoder failed. The MutationStore runs the table's `insertSchema`
- * AFTER defaults + computed + audit/tenant stamps; failure means
- * the stamped row didn't satisfy the decoder. `issues` is the
- * formatted ArrayFormatter output (cheap to render in UI, doesn't
- * leak the original Schema instance).
- */
-export declare class TableValidationFailed extends TableValidationFailed_base {
-}
-
-declare const TableValidationFailed_base: Schema.TaggedErrorClass<TableValidationFailed, "TableValidationFailed", {
-    readonly _tag: Schema.tag<"TableValidationFailed">;
-} & {
-    /** The table the row targeted. */
-    table: typeof Schema.String;
-    /** Top-level explanation for logs + UI ("user.email failed pattern check"). */
-    summary: typeof Schema.String;
-    /** Flat list of `{ path, message }` per failing leaf. Path uses dot-notation. */
-    issues: Schema.Array$<Schema.Struct<{
-        path: typeof Schema.String;
-        message: typeof Schema.String;
-    }>>;
-}>;
+export { TableValidationFailed }
 
 /** The standing compute-cost attribution for one tenant — the chargeback /
  *  showback row + the "why is my bill high" breakdown. Maintained incrementally:
@@ -9404,59 +9344,9 @@ export declare interface TenantCostState {
     readonly lastUpdatedAt: number | null;
 }
 
-/**
- * A keyed-by-primary-key write (`ctx.store.update(table, id, patch)`,
- * `delete(table, id)`, `hardDelete(table, id)`, `patchJson(table, id, …)`) on a
- * `tenant()`-scoped table did not resolve to a row inside the CALLER's tenant.
- *
- * **One error for two situations, on purpose.** It is raised identically when
- * the row does not exist at all and when it exists but belongs to another
- * tenant, and it carries no field that separates them. That is the whole point:
- *
- *   - Reporting "forbidden" for a foreign row and "not found" for a missing one
- *     turns any keyed write into a cross-tenant EXISTENCE ORACLE — an attacker
- *     walks ids and learns which ones are real in someone else's tenant, which
- *     is exactly the isolation the `tenant()` mixin exists to provide.
- *   - Collapsing the other way — silently affecting zero rows — is worse than
- *     either: the handler reads it as "the row is gone", not "you may not touch
- *     it", so a genuine isolation breach shows up in an app as a confusing
- *     absent-row branch and never as a security signal.
- *
- * So both cases fail LOUDLY and IDENTICALLY. `id` is the key the caller itself
- * supplied — never another tenant's data.
- */
-export declare class TenantRowNotFound extends TenantRowNotFound_base {
-}
+export { TenantRowNotFound }
 
-declare const TenantRowNotFound_base: Schema.TaggedErrorClass<TenantRowNotFound, "TenantRowNotFound", {
-    readonly _tag: Schema.tag<"TenantRowNotFound">;
-} & {
-    /** The table the keyed write targeted. */
-    table: typeof Schema.String;
-    /** The primary key the CALLER supplied. Echoing it leaks nothing. */
-    id: typeof Schema.String;
-    /** Human-readable explanation for diagnostics + UI. */
-    reason: typeof Schema.String;
-}>;
-
-/**
- * A write was attempted against a `tenant()`-scoped table, but the
- * authenticated subject's `tenantId` is null — either anonymous, or
- * an apiKey / serviceAccount without a tenant binding. Refusing the
- * write at the boundary is the safe default; a future "system writes"
- * subject type can opt out.
- */
-export declare class TenantScopeViolation extends TenantScopeViolation_base {
-}
-
-declare const TenantScopeViolation_base: Schema.TaggedErrorClass<TenantScopeViolation, "TenantScopeViolation", {
-    readonly _tag: Schema.tag<"TenantScopeViolation">;
-} & {
-    /** The table the violating write targeted. */
-    table: typeof Schema.String;
-    /** Human-readable explanation for diagnostics + UI. */
-    reason: typeof Schema.String;
-}>;
+export { TenantScopeViolation }
 
 export declare type TimeBucket = 'minute' | 'hour' | 'day' | 'week' | 'month';
 
@@ -9710,7 +9600,7 @@ export declare interface TransportSecurityOptions {
  * `on:` takes a `defineEvent` descriptor and reads its NAME, so the trigger and
  * the producer cannot drift: rename the event and this call site moves with it,
  * where the string form silently stops matching and the workflow simply never
- * runs again. That failure is exactly what a consumer reported having with their
+ * runs again. That failure is exactly what a deployment reported having with their
  * own string channels — `on-game-scores` beside `games/evo5/on-game-scores`,
  * both live, one dead since the day it was written — and it is the reason the
  * string form is going away rather than being kept as an alternative.
@@ -9767,7 +9657,7 @@ export declare type TupleSource = (req: {
      * The whole caller, not just their id.
      *
      * `subjectId` alone cannot express a credential that is NARROWER than the
-     * person holding it, and an API key is exactly that. A consumer reported it
+     * person holding it, and an API key is exactly that. A deployment reported it
      * precisely: their key carries its binding in `metadata` (`keyType`,
      * `teamId`), while `subject.id` is the OWNING USER — so a tuple source could
      * only resolve the owner's memberships and was blind to which team the key