@voltro/cli 0.43.2 → 0.44.1

package/dist/serveCommand-Dg_E1ev4.js

@@ -0,0 +1,2 @@
+import { n as e } from "./serveCommand-BlnAlNQg.js";
+export { e as runServeDispatch };

package/dist/serveEntry.js

@@ -1,5 +1,5 @@
 import { t as e } from "./loadEnv-D9nEOClM.js";
 import { r as t } from "./appModuleLoader-C9r9mxZt.js";
 import { i as n } from "./dialectDriver-czCHYpeH.js";
-import { t as r } from "./serveCommand-CgK7Kj6j.js";
+import { t as r } from "./serveCommand-BlnAlNQg.js";
 export { e as loadDotEnv, t as registerAppModules, n as registerDriver, r as runServe };

package/dist/{updateCommand-CrI9B4d7.js → updateCommand-BvRidHp6.js}

@@ -1,4 +1,4 @@
-import { n as e, r as t, t as n } from "./codemodRunner-Cnnz4-I7.js";
+import { n as e, r as t, t as n } from "./codemodRunner-BKTnaGOz.js";
 import { basename as r, dirname as i, join as a, relative as o, resolve as s } from "node:path";
 import { existsSync as c, readFileSync as l, readdirSync as u, statSync as d, writeFileSync as f } from "node:fs";
 import { totalmem as p } from "node:os";

package/dist/updateCommand-DcKVmLVN.js

@@ -0,0 +1,2 @@
+import { f as e, p as t } from "./updateCommand-BvRidHp6.js";
+export { e as runApplyCodemods, t as runUpdateCommand };

package/dist/{webhooksCommand-BVNtNsI0.js → webhooksCommand-BfO_JF2b.js}

@@ -222,7 +222,7 @@ createVerifier({ secret: [process.env.WEBHOOK_SECRET, process.env.WEBHOOK_SECRET
 		...t === void 0 ? {} : { payload: t }
 	};
 }, S = u({ scope: "voltro:webhooks" }), C = ["--out", "--name"], w = async (e) => {
-	let { walk: t, loadDiscovered: n } = await import("./dev-DMx-MF2s.js"), { outgoingFromEvents: r } = await import("./webhookDiscovery-il9ti-HE.js");
+	let { walk: t, loadDiscovered: n } = await import("./dev-BZO5aLdr.js"), { outgoingFromEvents: r } = await import("./webhookDiscovery-il9ti-HE.js");
 	return r((await n(await t(e))).events.map((e) => ({
 		file: e.file,
 		descriptor: e.descriptor

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/cli",
-  "version": "0.43.2",
+  "version": "0.44.1",
   "description": "The `voltro` CLI — dev server, codegen, migrations, project scaffolding, agent-docs seeding, and production serve.",
   "keywords": [
     "voltro",
@@ -634,6 +634,12 @@
         "title": "`DanglingReferenceError` → `RowsRefusedError` (named for the outcome, not a guessed cause)",
         "kind": "transform"
       },
+      {
+        "version": "0.44.0",
+        "id": "0.44.0/01_import-outcome",
+        "title": "`runImport` returns an ImportOutcome — read `.manifest` for the bundle",
+        "kind": "manual"
+      },
       {
         "version": "0.5.0",
         "id": "0.5.0/01_one-terminal-exactly-one",
@@ -721,22 +727,22 @@
     "@effect/platform-node": "^0.108.0",
     "@effect/sql": "^0.52.0",
     "@effect/workflow": "^0.19.0",
-    "@voltro/ai": "0.43.2",
-    "@voltro/cache": "0.43.2",
-    "@voltro/data-transfer": "0.43.2",
-    "@voltro/database": "0.43.2",
-    "@voltro/env": "0.43.2",
-    "@voltro/kv": "0.43.2",
-    "@voltro/logger": "0.43.2",
-    "@voltro/plugin-auth": "0.43.2",
-    "@voltro/plugin-broadcast": "0.43.2",
-    "@voltro/plugin-mail": "0.43.2",
-    "@voltro/plugin-storage": "0.43.2",
-    "@voltro/plugin-webhooks": "0.43.2",
-    "@voltro/protocol": "0.43.2",
-    "@voltro/runtime": "0.43.2",
-    "@voltro/serverless": "0.43.2",
-    "@voltro/workflow": "0.43.2",
+    "@voltro/ai": "0.44.1",
+    "@voltro/cache": "0.44.1",
+    "@voltro/data-transfer": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/kv": "0.44.1",
+    "@voltro/logger": "0.44.1",
+    "@voltro/plugin-auth": "0.44.1",
+    "@voltro/plugin-broadcast": "0.44.1",
+    "@voltro/plugin-mail": "0.44.1",
+    "@voltro/plugin-storage": "0.44.1",
+    "@voltro/plugin-webhooks": "0.44.1",
+    "@voltro/protocol": "0.44.1",
+    "@voltro/runtime": "0.44.1",
+    "@voltro/serverless": "0.44.1",
+    "@voltro/workflow": "0.44.1",
     "chokidar": "^5.0.0",
     "ioredis": "^5.11.1",
     "tinyglobby": "^0.2.17",

package/templates/AGENTS.md

@@ -707,7 +707,7 @@ each plugin's own README.
 
 | Topic | Open | Summary |
 |---|---|---|
-| **What's new in 0.43.2** | `node_modules/@voltro/cli/templates/agent-docs/whats-new.md` | Everything that changed in this version. Read it before hand-rolling something the framework may now ship. |
+| **What's new in 0.44.1** | `node_modules/@voltro/cli/templates/agent-docs/whats-new.md` | Everything that changed in this version. Read it before hand-rolling something the framework may now ship. |
 | AI | `node_modules/@voltro/cli/templates/agent-docs/ai.md` | How Voltro treats AI — agents, tools, streaming, RAG — all primitives over the same WebSocket as the rest of the framework. |
 | Authentication | `node_modules/@voltro/cli/templates/agent-docs/authentication.md` | How @voltro/plugin-auth wires password + session-cookie auth across api + web, plus the pluggable identity-strategy protocol. |
 | Caching | `node_modules/@voltro/cli/templates/agent-docs/caching.md` | Voltro's caching layer (@voltro/cache) — an always-on memory default, swappable Redis-compatible backends, a low-level wrap primitive, and automatic query-result invalidation. |

package/templates/agent-docs/_index.md

@@ -9,7 +9,7 @@ each plugin's own README.
 
 | Topic | Open | Summary |
 |---|---|---|
-| **What's new in 0.43.2** | `node_modules/@voltro/cli/templates/agent-docs/whats-new.md` | Everything that changed in this version. Read it before hand-rolling something the framework may now ship. |
+| **What's new in 0.44.1** | `node_modules/@voltro/cli/templates/agent-docs/whats-new.md` | Everything that changed in this version. Read it before hand-rolling something the framework may now ship. |
 | AI | `node_modules/@voltro/cli/templates/agent-docs/ai.md` | How Voltro treats AI — agents, tools, streaming, RAG — all primitives over the same WebSocket as the rest of the framework. |
 | Authentication | `node_modules/@voltro/cli/templates/agent-docs/authentication.md` | How @voltro/plugin-auth wires password + session-cookie auth across api + web, plus the pluggable identity-strategy protocol. |
 | Caching | `node_modules/@voltro/cli/templates/agent-docs/caching.md` | Voltro's caching layer (@voltro/cache) — an always-on memory default, swappable Redis-compatible backends, a low-level wrap primitive, and automatic query-result invalidation. |

package/templates/agent-docs/cli.md

@@ -2607,7 +2607,7 @@ Tenant-scope details:
 
 - **A tenant scope without a tenant id refuses loudly** (`ScopeError`): pass `--tenant <id>` (CLI) or `scope.tenantId` (API/profile). It never falls back to an unfiltered export.
 - **Which tables count as tenant-scoped** comes from the `tenant()` mixin metadata when the CLI / admin endpoint can read the declared schema (authoritative — a table can carry a `tenantId` column *without* being tenant-scoped, e.g. a global `users` table's active-org pointer). Without that metadata the exporter falls back to a documented heuristic: any table with a `tenantId` column.
-- A **cross-tenant reference** (a tenant-A row pointing at a tenant-B row) is never followed — the bundle stays tenant-clean and the reference dangles; importing such a bundle reports it loudly (`DanglingReferenceError`) unless the target already has the row.
+- A **cross-tenant reference** (a tenant-A row pointing at a tenant-B row) is never followed — the bundle stays tenant-clean and the reference dangles; importing such a bundle reports it loudly (`RowsRefusedError`) unless the target already has the row.
 
 ### Consistency: `live` vs `snapshot`
 
@@ -2649,7 +2649,8 @@ whole bundle.
 |---|---|---|
 | `--mode upsert\|append\|replace` | `upsert` | How rows are written. See the table below. |
 | `--on-conflict skip\|fail` | `skip` | `append` only: what to do when the primary key already exists. |
-| `--atomic` | off | Wrap the whole table phase in ONE transaction — live readers see the import all-or-nothing. The live-safe `replace`. |
+| `--atomic` | **on for `replace`**, off otherwise | Wrap the whole table phase in ONE transaction — readers see the import all-or-nothing. |
+| `--no-atomic` | — | Opt out of that. See the trade below. |
 | `--tables a,b` | every table | Import only these tables from the bundle. |
 | `--dry-run` | off | Run every pre-flight and report what WOULD move; write nothing. |
 | `--force` | off | Proceed despite schema drift AND cross-dialect warnings. |
@@ -2744,7 +2745,27 @@ A row whose write fails on a foreign-key constraint — a forward reference from
 2. **FK-shedding** — rows still stuck are written with their FK-bearing columns set to `NULL` (possible wherever those columns are nullable), which breaks row cycles on every dialect without session-level constraint toggles.
 3. **Patch pass** — shed rows are re-written with the full bundle row, restoring the FK values.
 
-Anything still unresolvable — the parent row exists in **neither the bundle nor the target**, or a `NOT NULL` FK cycle — fails with a typed `DanglingReferenceError` naming each offending table + primary key + the database's own reason. Held rows are the exception set, not the data set: memory is bounded by how many rows dangle at load time.
+Anything still unresolvable — the parent row exists in **neither the bundle nor the target**, a `NOT NULL` FK cycle, or a row the target refuses for a reason of its own — fails with a typed `RowsRefusedError`. Held rows are the exception set, not the data set: memory is bounded by how many rows dangle at load time.
+
+#### Reading a refusal
+
+The error carries three things, and they answer different questions:
+
+| Field | What it is |
+|---|---|
+| `totalCount` / `primaryCount` | how many rows were refused, and how many of those are the actual failures. A row is **derived** when one of its reference columns points at another row that also failed — it could not have landed whatever it contained, so it says nothing about itself. In an FK-dense bundle these dominate. |
+| `byTable` | **complete** per-table counts (`refused`, `primary`), worst first. |
+| `rows` | up to 20 refused rows — primary ones first — each with `table`, `id`, `reason`. |
+
+`rows` is **capped and `byTable` is not**, and that distinction is worth one sentence: tallying the tables in the printed list answers "how big is the cap", not "which tables failed". The CLI prints the `byTable` line above the list and says so when the list is truncated.
+
+A row's `reason` is stated as precisely as the driver allows, in three tiers:
+
+1. **the rule, in your schema's vocabulary** — `unique constraint PRIMARY: a row with this value already exists [ER_DUP_ENTRY/1062]`, `foreign key teams_ibfk_1: the referenced row does not exist (import it first, or check the bundle's table order) [ER_NO_REFERENCED_ROW_2/1452]`. The driver's own code is appended, because that is what you grep a log for;
+2. **the driver's own message + code**, for anything it refused that is not one of the five integrity rules — `Data too long for column 'v' at row 1 [ER_DATA_TOO_LONG/1406]`;
+3. **that there was nothing**, when no driver detail is reachable at all: `the database refused the write and the driver gave no detail` — plus `(via …)`, the chain of wrappers, whenever that chain has more than one layer to name. Read this tier as "not a constraint": a guard, a row filter, or a failure whose words did not survive. When it fires, the run also **logs the full rendering** of the first three such rows (table, primary key, and the whole error as it rendered) and counts the rest. That log line is never returned over the wire — it carries our stack frames, and on some engines a driver's sentence carries row data — so on `--target api` you read it in the instance's log.
+
+Unlike the rpc wire, this string DOES include the driver's own words. The audience is the difference: it is read only by whoever ran `voltro data import` — the holder of the data-transfer secret, who supplied the rows and can export the whole target anyway.
 
 ### Write modes (`--mode`)
 
@@ -2760,7 +2781,11 @@ Anything still unresolvable — the parent row exists in **neither the bundle no
 
 The bundle's tables are emptied **as one unit, in one transaction, with referential integrity suspended for the duration** — not table by table. Both halves matter:
 
-- **All or nothing.** A run that cannot finish leaves the target exactly as it found it. Emptying table by table and stopping at the first refusal leaves the target in neither state — and makes a second attempt destroy *more* than the first.
+- **All or nothing — the emptying AND the load.** `--mode replace` runs the whole table phase in ONE transaction by default, so a run that cannot finish leaves the target exactly as it found it. That default is a correction: the guarantee used to cover only the emptying, and a replace that died partway through the *load* left the target emptied of its old rows and holding part of the new ones. There is no useful state for a replace to stop in, which is why it is the default rather than a flag you have to know about.
+
+  One transaction also closes a window that is easy to miss. Between the delete and the load the target is empty, and if the database is being served, the application writes into that gap — a row it creates on demand is then a primary-key conflict against the same row arriving from the bundle. With one transaction the concurrent writer waits instead of racing.
+
+  `--no-atomic` opts out, and the trade is real: every write to those tables waits for the load, so on a bundle that takes minutes, so does the wait. On postgres it also re-enables the bulk `COPY` loader, which cannot join a transaction it does not own — an atomic run says so once rather than being quietly slower.
 - **No ordering can replace the suspension.** MySQL, MariaDB and SQL Server check a foreign key as each *row* is deleted, so a table that references **itself** cannot be emptied at all by ordering tables — the conflict is between two rows of one of them. `createdBy → actors` on the `actors` table is exactly that shape, and it is what an audit mixin on an actor table produces. (Postgres needs no suspension: a multi-table `TRUNCATE` covers the whole set at once.)
 
 What it will **not** do is reach outside the bundle. If a table the bundle does **not** carry holds rows that reference one it does, `replace` refuses **before deleting anything** and names them:
@@ -2817,10 +2842,10 @@ A plain import connects **straight to the database** (not through the running ap
 | Target | How | Guarantees | Use for |
 |---|---|---|---|
 | **direct** (default) | writes straight to the DB | none while live — **guarded**; pass `--allow-live` to override | a stopped target, a replica, a dev/staging DB not serving traffic |
-| **direct + `--atomic`** | wraps truncate+load in ONE transaction | MVCC readers see the import **all-or-nothing** (old until commit, new after) — the live-safe `replace` | replacing a live target's data with no partial-state window |
+| **direct + `--atomic`** (the default for `replace`) | wraps empty+load in ONE transaction | MVCC readers see the import **all-or-nothing** (old until commit, new after) — the live-safe `replace` | replacing a live target's data with no partial-state window |
 | **in-process (`--target api`)** | `voltro data import <dir> --target api --api-url <url> --token <secret>` **uploads** the packed bundle (or, with `--bundle-key`, has the instance **pull it from storage**) to the instance's secret-gated admin endpoint, which imports it **in its own process** through its store | full app pipeline — validation, mixins, **field encryption**, hooks — AND automatic reactivity (in-process writes emit change events, so subscriptions update; no separate resync) | a live merge (incl. PROD) that must honour app invariants |
 
-`--atomic` is the recommended live `replace`: one transaction, so live reads never see a half-loaded table. (It holds a write transaction for the load duration — writes to those tables block, readers don't. A shadow-table rename would shorten that lock window, but for a full replace concurrent writes are discarded on swap anyway, so it isn't the default.)
+`--atomic` is what `replace` does by default (see above): one transaction, so live reads never see a half-loaded table. (It holds a write transaction for the load duration — writes to those tables block, readers don't. A shadow-table rename would shorten that lock window, but for a full replace concurrent writes are discarded on swap anyway, so it isn't the default.)
 
 ### The `--target api` data-transfer endpoints (prod-safe)
 
@@ -2937,6 +2962,17 @@ Net: interrupt an export or import at any point — network drop, `Ctrl-C`, OOM-
 
 The `--target api` path is unaffected: the instance unpacks each upload into a fresh temp directory, so it never carries a ledger between runs.
 
+### What the summary line counts
+
+`import complete … rows: N` counts the rows **this run wrote**, not the rows the bundle carries. The two differ more often than you would think, and the case where they differ most used to read as a success:
+
+```
+import complete — 0 rows written, every table was already applied by an earlier run
+of this bundle directory { rows: 0, carried: 242950, skippedTables: 114, skippedRows: 242950 }
+```
+
+The resume ledger lives **inside the bundle directory**, so copying a bundle copies its ledger, and the copy then imports nothing — correctly, and with a warning that says so and names the file to delete. But the warning is not the last line, and an operator piping the output through `tail -1` sees only the last line. So the last line now tells the truth on its own: `rows` is what was written, `carried` is what the bundle holds, and `skippedRows` is what an earlier run had already applied.
+
 ### Progress & observability
 
 A multi-hour job is not a black box. Both pipelines signal per **table** — never per row, so the reporting never slows the hot path:
@@ -2961,7 +2997,7 @@ yield* runImport({
 
 Every pipeline failure is a **tagged error**, caught by tag with `Effect.catchTag(...)`. The errors that appear on the `runExport` / `runImport` error channels — the **wire errors**, and therefore exactly what the `--target api` admin endpoints surface — are `Schema.TaggedError`, so a handler can declare them on an rpc procedure's `error:` schema and the rpc encoder marshals them across the wire round-trip-safely (no hand-rolled JSON per tag):
 
-`BundleError`, `CodecError`, `IntegrityError`, `CrossDialectError`, `ImportModeError`, `DanglingReferenceError`, `SchemaDriftError`, `MaskingError`, `ScopeError`.
+`BundleError`, `CodecError`, `IntegrityError`, `CrossDialectError`, `ImportModeError`, `RowsRefusedError`, `SchemaDriftError`, `MaskingError`, `ScopeError`.
 
 The two internal errors — `NativeToolError` (native `backup`/`restore`) and `CompressionError` (folded into `BundleError` by the pipelines) — never cross the wire, so they stay plain `Data.TaggedError`: still catchable by tag, just no Schema surface.
 

package/templates/agent-docs/plugins/versioning.md

@@ -134,6 +134,8 @@ Version numbers are 1-based in **both** timings, so switching `timing` does not
 
 **The price is not optional.** That guarantee is only obtainable by being willing to REFUSE. When the history insert fails — disk, lock timeout, constraint, dropped connection — a transaction offers exactly two outcomes: the mutation fails with it, or the error is swallowed and the change commits without its entry, which is post-commit's hole with the cost already paid. There is no third option, so a rare, explained rejection is the shape of the guarantee rather than a defect.
 
+**The refusal takes the row with it.** When the trail's insert fails, the write it covers is rolled back — including a write made OUTSIDE any transaction of your own. That has not always been true: the row's statement committed on its own and the trail ran as a second statement afterwards, so a failing trail left a committed row behind a write that reported failure. Anything that retried that write then met its own row and reported a duplicate key for a row nobody wrote twice. A table with recorders is written inside a transaction now, on every SQL dialect, so "the mutation fails with it" means what it says.
+
 **Why the default is still `'post-commit'`.** In-transaction makes `_voltro_row_history` a hard dependency of every write path it covers: its availability becomes your write path's availability, and every covered write holds its locks longer. Post-commit loses at worst *one entry*; in-transaction can, at worst, stop writes to the covered tables entirely. For a compliance trail the second trade is the right one — for the undo / time-travel use this plugin also serves, it is not.
 
 ### Under CDC, and inside a transaction

package/templates/agent-docs/whats-new.md

@@ -1,4 +1,4 @@
-# What's new in 0.43.2
+# What's new in 0.44.1
 
 Read this FIRST when a task touches an area you have not worked in recently.
 It is the cheapest way to notice that the framework grew the thing you were
@@ -9,27 +9,12 @@ BREAKING entries name a codemod; run `voltro update` to apply it.
 
 ### Fixed
 
-- **@voltro/sql-mysql, @voltro/database, @voltro/cli** — The mysql-family binlog reader no longer keeps a table excluded after the very migration that fixed it.
+- **@voltro/database, @voltro/data-transfer, @voltro/cli** — A refused import row reported `(FiberFailure) SqlError: Failed to execute statement` — our runtime's rendering of a rejection, marker and stack frames and all — instead of the constraint that fired. It names neither a rule, nor a code, nor even which layer refused, and every row refused for the same cause carries it identically.
 
-  A UNIQUE on an unbounded text column is a MariaDB hash long-unique, whose hidden `DB_ROW_HASH_n` column the reader can never account for — so the table is held out of binlog capture and the exclusion is reported. `voltro dev` builds its store BEFORE it migrates (kv, cross-replica broadcast and the analytics mirror all need one), so on a boot whose own auto-migration bounds the column, that finding was drawn from a schema that stopped existing about a second later. The exclusion then outlived its cause for the life of the process, and the message — correct when written, and typically the only error line in the boot log — went on describing the pre-migration database.
+  Two defects, and fixing either alone still leaves a reader stuck.
 
-  Three changes:
+  **`Cause.squash` elects a branch, and first is a position, not a ranking.** A `Cause` is a tree, and a transaction routinely produces one with more than one leaf: the statement that failed, and whatever the rollback or a finalizer did on the way out. When the first leaf was the bare wrapper, the driver error sitting in the sibling branch was never looked at. Measured: `sequential(bareSqlError, sqlErrorWithDriver)` classified as nothing while the same two branches in the opposite order classified as `unique constraint PRIMARY … [ER_DUP_ENTRY/1062]`. `extractDbCause` flattens failures AND defects now, in Cause order, expanding a nested `FiberFailure` leaf, and elects the branch that names a driver — the others' chains are appended rather than dropped.
 
-  - `DataStore.refreshChangeCaptureExclusions()` (optional; implemented by the mysql-family store) re-runs the probe and re-points the LIVE reader, in both directions — schema work that CREATES the condition now excludes the table immediately instead of after three failed writes. `voltro dev` calls it once, after all its schema work. `voltro serve` needs no equivalent: it builds its store after every schema step and never applies DDL itself. - The definitive message now states its own durability — that it is the schema as read at reader attach, and that applying the remedy does not by itself lift the exclusion. - On a boot that will re-check, the finding is reported as a provisional note rather than as a verdict, so a boot that fixes the condition leaves no error line about it. The note escalates to the full verdict on its own if the re-check never runs. - Two reader fixes the re-check depended on: applying a new exclusion set now WAITS for a reconnect already in flight (it is what applies the set, so resolving before it landed meant the caller's next write hit the old filter), and the reconnect loop no longer keeps resuming from an offset it has just jumped away from — that turned one purged offset into a reconnect every watchdog interval, forever, delivering nothing.
-- **@voltro/data-transfer, @voltro/database, @voltro/sql-mysql, @voltro/sql-postgres, @voltro/sql-sqlite, @voltro/sql-mssql, @voltro/cli** — `voltro data import --mode replace` no longer leaves a target in neither state, and now works against schemas that have foreign keys.
+  **A row's reason may never read like a stack trace.** The runtime rendering is stripped before any tier looks at the text, so the failure mode cannot return invisibly. And when no driver detail is reachable at all, the reason now names the CHAIN of wrappers the failure passed through — the difference between "the database refused this row" and "the connection died mid-import" — while the run logs the full rendering of the first few such failures. Never returned over the wire: it carries frames, and on some engines a driver's sentence carries row data.
 
-  The delete step ran table by table and stopped at the first refusal, so a run that could not finish left dozens of tables emptied and nothing loaded — and a second attempt destroyed more than the first, because it got further before hitting the same wall. The wall itself was not exotic: MySQL, MariaDB and SQL Server check a foreign key as each ROW is deleted, so a table that references ITSELF cannot be emptied by any ordering of the tables. `createdBy → actors` on the `actors` table is exactly that shape, and it is what an audit mixin on an actor table produces.
-
-  - `DataStore.emptyTables()` (per dialect) empties the whole set as one unit, in one transaction, with referential integrity suspended for the duration — `FOREIGN_KEY_CHECKS` on the mysql family, a multi-table `TRUNCATE` on postgres, `defer_foreign_keys` on sqlite, per-table `NOCHECK`/`WITH CHECK CHECK` on mssql. All-or-nothing on every engine, including under `--atomic`, where it runs on the transaction the import already holds. - A **pre-flight refusal**: if a table OUTSIDE the bundle holds rows referencing one inside it, the import refuses before deleting anything and names the tables, the columns and the row counts. Those rows cannot be restored from the bundle, so forcing it is not an option. An EMPTY outside table blocks nothing. - Table-level failures carry the driver's own reason and code, the way row-level failures already did. `truncate <table> failed: Failed to execute statement` fits every plausible cause equally; the classification that produced `foreign key <name>: … [ER_NO_REFERENCED_ROW_2/1452]` one level down now applies one level up. The word "truncate" is gone from the message too — the step issues DELETE, and naming a statement it does not run sends whoever reads it to reproduce the wrong thing. - A typed refusal reaching the `--target api` transport keeps its text: the admin import endpoint answers `409` with the reason instead of flattening it to `import failed`, on the one transport where the operator has no other way to see it.
-
-  The bulk empty emits no change events, where the per-table loop emitted one per row. An import through `--target api` now asks every live subscription to re-read once it lands — the coarse refresh the framework already uses after a broadcast gap — so neither the missing deletes nor a table the bundle carries EMPTY leaves a subscriber holding rows that are gone. Wired where the route is mounted, which is the one place both boot paths share.
-
-  On postgres the emptying is a `DELETE` per table, not a `TRUNCATE`, and the difference is not performance: postgres refuses `TRUNCATE` on a table with ANY incoming foreign key, rows or not, while the mysql family refuses a DELETE only when rows actually reference the doomed ones. A `TRUNCATE` version made an EMPTY table outside the bundle block a replace on postgres and not on mariadb — one import, refused on one engine and accepted on the other, over a table holding nothing.
-
-  `--target api` also no longer times out on a full bundle. Both api-target calls went through `fetch`, whose undici default gives up after 300 s — a bound on the caller's database size, on a call whose response arrives only when the import does. They wait as long as the instance needs now, stream the body instead of buffering the whole bundle, and take `--timeout <seconds>` when a deadline is wanted. If one is hit, the message says the instance is probably still importing — and gives different advice for `replace` than for the idempotent modes, since re-running the first while it is mid-flight would empty the target under it.
-
-  Two more, found by measuring rather than by reading:
-
-  - **`--atomic` on postgres could not import a bundle that needed the deferred-FK repair at all.** A failed statement aborts the transaction there, and that repair depends on a row whose parent has not loaded yet failing, being held, and being retried — so the first such row poisoned every write after it. Every tolerated write now runs inside a savepoint. Per-row savepoints measured 2.40x the time of none on 5 000 rows, so they are amortised: one savepoint per batch of 200, and a batch that fails rolls back whole and replays row by row. The mysql family and sqlite leave a transaction usable after a failed statement and pay nothing for any of this. - **The replace pre-flight asked the caller's snapshot.** Over `--target api` that is the app's DECLARED schema, which cannot show a table the app stopped declaring but the database still has — and rows in a table nobody declares are exactly the rows nobody is watching. `DataStore.incomingForeignKeys()` reads the live catalog per dialect; the snapshot remains the fallback for stores without one.
-
-  A bundle bigger than one chunk is now uploaded as a series of short requests, so a proxy body cap or an ingress read timeout has nothing large to choke on, and the switch is automatic — the packer's stream is buffered one chunk ahead, so a small bundle is sent exactly as before and nobody has to know in advance which table is the big one. The import still runs ONCE, at the end, over the whole bundle. Resume is byte-exact (`packBundle` is deterministic over a directory, which this package now asserts), guarded by a bundle key so a different bundle under the same upload id is refused rather than spliced into the partial one, and by a contiguity check so a mis-ordered append cannot produce an archive that only fails later during decode. `--chunk-size <mb>` overrides the 16 MiB default.
+  `RowsRefusedError` also gained `byTable`: **complete** per-table counts. `rows` is capped at 20, so per-table counts tallied off the printed list sum to the cap rather than to the failure — and nothing else in the payload offered any.

package/templates/apps/api-ai/package.json

@@ -12,16 +12,16 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/ai": "0.43.2",
-    "@voltro/cli": "0.43.2",
-    "@voltro/database": "0.43.2",
-    "@voltro/env": "0.43.2",
-    "@voltro/protocol": "0.43.2",
-    "@voltro/runtime": "0.43.2",
+    "@voltro/ai": "0.44.1",
+    "@voltro/cli": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/protocol": "0.44.1",
+    "@voltro/runtime": "0.44.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

package/templates/apps/api-auth/package.json

@@ -13,17 +13,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.43.2",
-    "@voltro/database": "0.43.2",
-    "@voltro/env": "0.43.2",
-    "@voltro/plugin-auth": "0.43.2",
-    "@voltro/protocol": "0.43.2",
-    "@voltro/runtime": "0.43.2",
-    "@voltro/sql-postgres": "0.43.2",
+    "@voltro/cli": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/plugin-auth": "0.44.1",
+    "@voltro/protocol": "0.44.1",
+    "@voltro/runtime": "0.44.1",
+    "@voltro/sql-postgres": "0.44.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

package/templates/apps/api-backend/package.json

@@ -16,16 +16,16 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.43.2",
-    "@voltro/database": "0.43.2",
-    "@voltro/env": "0.43.2",
-    "@voltro/plugin-multitenancy": "0.43.2",
-    "@voltro/protocol": "0.43.2",
-    "@voltro/runtime": "0.43.2",
+    "@voltro/cli": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/plugin-multitenancy": "0.44.1",
+    "@voltro/protocol": "0.44.1",
+    "@voltro/runtime": "0.44.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

package/templates/apps/api-backend-deactivation/package.json

@@ -13,16 +13,16 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.43.2",
-    "@voltro/database": "0.43.2",
-    "@voltro/env": "0.43.2",
-    "@voltro/plugin-deactivation": "0.43.2",
-    "@voltro/protocol": "0.43.2",
-    "@voltro/runtime": "0.43.2",
+    "@voltro/cli": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/plugin-deactivation": "0.44.1",
+    "@voltro/protocol": "0.44.1",
+    "@voltro/runtime": "0.44.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

package/templates/apps/api-backend-mail/package.json

@@ -13,18 +13,18 @@
   "dependencies": {
     "@react-email/components": "^1.0.12",
     "@react-email/render": "^1.4.0",
-    "@voltro/cli": "0.43.2",
-    "@voltro/database": "0.43.2",
-    "@voltro/env": "0.43.2",
-    "@voltro/plugin-mail": "0.43.2",
-    "@voltro/plugin-multitenancy": "0.43.2",
-    "@voltro/protocol": "0.43.2",
-    "@voltro/runtime": "0.43.2",
+    "@voltro/cli": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/plugin-mail": "0.44.1",
+    "@voltro/plugin-multitenancy": "0.44.1",
+    "@voltro/protocol": "0.44.1",
+    "@voltro/runtime": "0.44.1",
     "effect": "^3.22.0",
     "react": "^19.0.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

package/templates/apps/api-backend-mariadb/package.json

@@ -13,18 +13,18 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.43.2",
-    "@voltro/database": "0.43.2",
-    "@voltro/env": "0.43.2",
-    "@voltro/plugin-multitenancy": "0.43.2",
-    "@voltro/plugin-storage": "0.43.2",
-    "@voltro/protocol": "0.43.2",
-    "@voltro/runtime": "0.43.2",
-    "@voltro/sql-mysql": "0.43.2",
+    "@voltro/cli": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/plugin-multitenancy": "0.44.1",
+    "@voltro/plugin-storage": "0.44.1",
+    "@voltro/protocol": "0.44.1",
+    "@voltro/runtime": "0.44.1",
+    "@voltro/sql-mysql": "0.44.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

package/templates/apps/api-backend-sqlite/package.json

@@ -13,17 +13,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.43.2",
-    "@voltro/database": "0.43.2",
-    "@voltro/env": "0.43.2",
-    "@voltro/plugin-multitenancy": "0.43.2",
-    "@voltro/protocol": "0.43.2",
-    "@voltro/runtime": "0.43.2",
-    "@voltro/sql-sqlite": "0.43.2",
+    "@voltro/cli": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/plugin-multitenancy": "0.44.1",
+    "@voltro/protocol": "0.44.1",
+    "@voltro/runtime": "0.44.1",
+    "@voltro/sql-sqlite": "0.44.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

package/templates/apps/api-backend-storage/package.json

@@ -11,17 +11,17 @@
     "test": "voltro test"
   },
   "dependencies": {
-    "@voltro/cli": "0.43.2",
-    "@voltro/database": "0.43.2",
-    "@voltro/env": "0.43.2",
-    "@voltro/plugin-multitenancy": "0.43.2",
-    "@voltro/plugin-storage": "0.43.2",
-    "@voltro/protocol": "0.43.2",
-    "@voltro/runtime": "0.43.2",
+    "@voltro/cli": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/plugin-multitenancy": "0.44.1",
+    "@voltro/plugin-storage": "0.44.1",
+    "@voltro/protocol": "0.44.1",
+    "@voltro/runtime": "0.44.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

package/templates/apps/api-cms/package.json

@@ -13,19 +13,19 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.43.2",
-    "@voltro/cms": "0.43.2",
-    "@voltro/database": "0.43.2",
-    "@voltro/env": "0.43.2",
-    "@voltro/plugin-auth": "0.43.2",
-    "@voltro/plugin-multitenancy": "0.43.2",
-    "@voltro/protocol": "0.43.2",
-    "@voltro/runtime": "0.43.2",
-    "@voltro/sql-postgres": "0.43.2",
+    "@voltro/cli": "0.44.1",
+    "@voltro/cms": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/plugin-auth": "0.44.1",
+    "@voltro/plugin-multitenancy": "0.44.1",
+    "@voltro/protocol": "0.44.1",
+    "@voltro/runtime": "0.44.1",
+    "@voltro/sql-postgres": "0.44.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

package/templates/apps/api-collab/package.json

@@ -13,17 +13,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.43.2",
-    "@voltro/database": "0.43.2",
-    "@voltro/env": "0.43.2",
-    "@voltro/local-first": "0.43.2",
-    "@voltro/plugin-multitenancy": "0.43.2",
-    "@voltro/protocol": "0.43.2",
-    "@voltro/runtime": "0.43.2",
+    "@voltro/cli": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/local-first": "0.44.1",
+    "@voltro/plugin-multitenancy": "0.44.1",
+    "@voltro/protocol": "0.44.1",
+    "@voltro/runtime": "0.44.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

package/templates/apps/api-data-advanced/package.json

@@ -12,17 +12,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.43.2",
-    "@voltro/database": "0.43.2",
-    "@voltro/env": "0.43.2",
-    "@voltro/plugin-governance": "0.43.2",
-    "@voltro/plugin-multitenancy": "0.43.2",
-    "@voltro/protocol": "0.43.2",
-    "@voltro/runtime": "0.43.2",
+    "@voltro/cli": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/plugin-governance": "0.44.1",
+    "@voltro/plugin-multitenancy": "0.44.1",
+    "@voltro/protocol": "0.44.1",
+    "@voltro/runtime": "0.44.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"