@voltro/cli 0.43.2 → 0.44.0

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.0",
   "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.0",
+    "@voltro/cache": "0.44.0",
+    "@voltro/data-transfer": "0.44.0",
+    "@voltro/database": "0.44.0",
+    "@voltro/env": "0.44.0",
+    "@voltro/kv": "0.44.0",
+    "@voltro/logger": "0.44.0",
+    "@voltro/plugin-auth": "0.44.0",
+    "@voltro/plugin-broadcast": "0.44.0",
+    "@voltro/plugin-mail": "0.44.0",
+    "@voltro/plugin-storage": "0.44.0",
+    "@voltro/plugin-webhooks": "0.44.0",
+    "@voltro/protocol": "0.44.0",
+    "@voltro/runtime": "0.44.0",
+    "@voltro/serverless": "0.44.0",
+    "@voltro/workflow": "0.44.0",
     "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.0** | `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.0** | `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

@@ -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. |
@@ -2760,7 +2761,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 +2822,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 +2942,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:

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.0
 
 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
@@ -7,29 +7,32 @@ workaround for something that shipped two versions ago.
 
 BREAKING entries name a codemod; run `voltro update` to apply it.
 
-### Fixed
+### ⚠ BREAKING
+
+- **@voltro/data-transfer, @voltro/cli** — `runImport` returns an `ImportOutcome` instead of the bundle's `Manifest`, and `--mode replace` runs as ONE transaction by default.
 
-- **@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.
+  **Why the return type changed.** The summary line counted the rows the BUNDLE carries, not the rows the run wrote. Those differ most exactly where it matters: a bundle directory carries its own resume ledger, so a copied directory imports nothing — correctly, with a warning naming the file to delete — and the run then printed `import complete … rows: 242950` over a target it had not touched. The warning was one line above, which is one line too far for anyone piping the output through `tail -1`. The outcome carries `rowsWritten`, `rowsSkipped` and `fullyResumed`, the CLI reports written-vs-carried, and a fully-skipped run says so on its LAST line.
 
-  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.
+  Migration: `runImport(...)` now resolves to `{ manifest, tablesWritten, rowsWritten, tablesSkipped, rowsSkipped, fullyResumed }`. Read `.manifest` where you read the manifest before.
 
-  Three changes:
+  **Why replace is atomic now.** The all-or-nothing guarantee was written for the emptying step, and read — reasonably — as covering the run. A replace that died partway through the LOAD left the target emptied of its old rows and holding part of the new ones, measured on a live instance over sixteen minutes. There is no useful state for a replace to stop in, so it is a default rather than a flag you have to know about. It also closes the window that produced that failure: with the tables emptied and the load uncommitted, a concurrent writer in the application waits instead of inserting a row the bundle is about to insert too.
 
-  - `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.
+  `--no-atomic` (CLI) / `atomic: false` (API) opts out. The trade is stated where it bites: every write to those tables waits for the load, and on postgres the bulk `COPY` loader cannot join a transaction it does not own — an atomic run now says that once rather than being quietly slower.
 
-  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.
+  Two smaller things from the same report: `--mode replace` against a running instance warns about the empty-target window when it is NOT atomic, and the `--target api` upload reports progress per chunk plus a line explaining that the final request stays open for the whole import — sixteen minutes of silence is indistinguishable from a hang, and one operator killed a run that had finished.
 
-  - `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.
+  **`voltro update` carries you across this** — codemod `0.44.0/01_import-outcome`.
+
+### Fixed
 
-  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.
+- **@voltro/sql-mysql, @voltro/sql-postgres, @voltro/sql-sqlite, @voltro/sql-mssql, @voltro/data-transfer** — A write and its write-recorders now succeed or fail together on every SQL dialect, and the data importer's retry is idempotent.
 
-  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.
+  A recorder (a versioning trail, an audit log) runs on the caller's connection and is ALLOWED to fail — a recorder that throws must take the write down with it, that is its contract. Outside a caller transaction the two were not one unit: the row's statement committed on its own, and the recorder's INSERT ran afterwards as a second autocommit statement. So a recorder that threw left a COMMITTED row behind a write that reported failure. Measured directly: `insert` throws, the row is in the table, and a second attempt at the same row is `ER_DUP_ENTRY` on PRIMARY.
 
-  `--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.
+  Anything that retries a failed write then meets its own row. The data importer retries by design — it holds a row whose write failed and tries again once the remaining tables have streamed — so a `--mode replace` that had just emptied a table failed on a duplicate key IN that table. From outside, that is the impossible-looking thing: an import that emptied a table and then failed because something was already in it. Reproduced verbatim, including the table name and `[ER_DUP_ENTRY/1062]`, by putting the old retry back.
 
-  Two more, found by measuring rather than by reading:
+  Both ends are closed, and they are independent on purpose:
 
-  - **`--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.
+  - **The cause.** A table that HAS recorders writes inside a transaction now, so the row and the trail commit together or not at all — on mysql, mariadb, postgres, sqlite and mssql, verified by one suite that asks all five the same question. A table with no recorders — the default — takes the direct path unchanged; `recordsTable` is a Map-size check first, so it costs one comparison. - **The defence.** The importer's retry upserts instead of inserting in `replace` mode. That covers every OTHER way a write can land while reporting failure: a driver timeout on a write the server applied, a connection lost after the commit, a concurrent writer inserting the same key. It is sound precisely because the table was emptied by this same run — there is nothing in it that is not ours.
 
-  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.
+  The test that pinned the divergence went red when the fix landed, exactly as its own note said it would, and is inverted with that note kept.

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.0",
+    "@voltro/cli": "0.44.0",
+    "@voltro/database": "0.44.0",
+    "@voltro/env": "0.44.0",
+    "@voltro/protocol": "0.44.0",
+    "@voltro/runtime": "0.44.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.0",
     "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.0",
+    "@voltro/database": "0.44.0",
+    "@voltro/env": "0.44.0",
+    "@voltro/plugin-auth": "0.44.0",
+    "@voltro/protocol": "0.44.0",
+    "@voltro/runtime": "0.44.0",
+    "@voltro/sql-postgres": "0.44.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.0",
     "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.0",
+    "@voltro/database": "0.44.0",
+    "@voltro/env": "0.44.0",
+    "@voltro/plugin-multitenancy": "0.44.0",
+    "@voltro/protocol": "0.44.0",
+    "@voltro/runtime": "0.44.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.0",
     "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.0",
+    "@voltro/database": "0.44.0",
+    "@voltro/env": "0.44.0",
+    "@voltro/plugin-deactivation": "0.44.0",
+    "@voltro/protocol": "0.44.0",
+    "@voltro/runtime": "0.44.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.0",
     "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.0",
+    "@voltro/database": "0.44.0",
+    "@voltro/env": "0.44.0",
+    "@voltro/plugin-mail": "0.44.0",
+    "@voltro/plugin-multitenancy": "0.44.0",
+    "@voltro/protocol": "0.44.0",
+    "@voltro/runtime": "0.44.0",
     "effect": "^3.22.0",
     "react": "^19.0.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.0",
     "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.0",
+    "@voltro/database": "0.44.0",
+    "@voltro/env": "0.44.0",
+    "@voltro/plugin-multitenancy": "0.44.0",
+    "@voltro/plugin-storage": "0.44.0",
+    "@voltro/protocol": "0.44.0",
+    "@voltro/runtime": "0.44.0",
+    "@voltro/sql-mysql": "0.44.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.0",
     "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.0",
+    "@voltro/database": "0.44.0",
+    "@voltro/env": "0.44.0",
+    "@voltro/plugin-multitenancy": "0.44.0",
+    "@voltro/protocol": "0.44.0",
+    "@voltro/runtime": "0.44.0",
+    "@voltro/sql-sqlite": "0.44.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.0",
     "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.0",
+    "@voltro/database": "0.44.0",
+    "@voltro/env": "0.44.0",
+    "@voltro/plugin-multitenancy": "0.44.0",
+    "@voltro/plugin-storage": "0.44.0",
+    "@voltro/protocol": "0.44.0",
+    "@voltro/runtime": "0.44.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.0",
     "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.0",
+    "@voltro/cms": "0.44.0",
+    "@voltro/database": "0.44.0",
+    "@voltro/env": "0.44.0",
+    "@voltro/plugin-auth": "0.44.0",
+    "@voltro/plugin-multitenancy": "0.44.0",
+    "@voltro/protocol": "0.44.0",
+    "@voltro/runtime": "0.44.0",
+    "@voltro/sql-postgres": "0.44.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.0",
     "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.0",
+    "@voltro/database": "0.44.0",
+    "@voltro/env": "0.44.0",
+    "@voltro/local-first": "0.44.0",
+    "@voltro/plugin-multitenancy": "0.44.0",
+    "@voltro/protocol": "0.44.0",
+    "@voltro/runtime": "0.44.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.0",
     "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.0",
+    "@voltro/database": "0.44.0",
+    "@voltro/env": "0.44.0",
+    "@voltro/plugin-governance": "0.44.0",
+    "@voltro/plugin-multitenancy": "0.44.0",
+    "@voltro/protocol": "0.44.0",
+    "@voltro/runtime": "0.44.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.43.2",
+    "@voltro/testing": "0.44.0",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"