@voltro/cli 0.44.0 → 0.44.1

package/CHANGELOG.md

@@ -39,6 +39,22 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [0.44.1] — 2026-08-19
+
+### Fixed
+
+- **@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.
+
+  Two defects, and fixing either alone still leaves a reader stuck.
+
+  **`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.
+
+  **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.
+
+  `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.
+
+---
+
 ## [0.44.0] — 2026-08-19
 
 ### ⚠ BREAKING

package/dist/bin.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import { r as e } from "./commands-fsnezHLH.js";
+import { r as e } from "./commands-CYkHTox2.js";
 import { a as t } from "./nodeEnvironment-cGFAj1J8.js";
 import { t as n } from "./loadEnv-D9nEOClM.js";
 import { n as r } from "./cliError-BmdYnghb.js";

package/dist/{commands-fsnezHLH.js → commands-CYkHTox2.js}

@@ -469,7 +469,7 @@ var c = () => {
 		name: "data",
 		summary: "Export/import + backup/restore of app data. Logical (rows + optional assets): export <dir> [--tenant <id>|--tables a,b] [--assets] [--compression zstd|gzip|none] [--consistency live|snapshot]; import <dir> [--assets] [--no-verify]. Native (rows ONLY — no blobs): backup <dir> / restore <dir> (pg_dump/mariadb-dump/…). Resumable; typed-NDJSON; content-addressed assets on the logical path.",
 		status: "wired",
-		run: (e) => import("./dataCommand-sfpGV694.js").then((t) => t.runDataCommand(e)),
+		run: (e) => import("./dataCommand-WFn8CM11.js").then((t) => t.runDataCommand(e)),
 		help: {
 			usage: "<export|import|backup|restore> <dir> [options]",
 			flags: [

package/dist/{dataCommand-sfpGV694.js → dataCommand-WFn8CM11.js}

@@ -553,9 +553,12 @@ var A = class extends Error {
 	if (t?._tag !== "RowsRefusedError" || !Array.isArray(t.rows)) return;
 	let n = t.rows, r = n.filter((e) => !e.derived), i = Number(t.totalCount ?? n.length), a = Number(t.primaryCount ?? r.length);
 	F.error(`import refused ${i} row(s), of which ${a} are the actual failures — the rest could not land because a row they reference did not.`);
+	let o = Array.isArray(t.byTable) ? t.byTable : [];
+	o.length > 1 && F.error(`  by table: ${o.map((e) => `${e.table} ${e.refused}`).join(", ")}`);
 	for (let e of r) F.error(`  ${e.table} ${e.id}  ${e.reason}`);
-	let o = i - a;
-	o > 0 && F.error(`  … and ${o} row(s) behind them. Fix the ${a} above and re-run; they resolve with their parents.`);
+	n.length < i && F.error(`  (the list above is capped at ${n.length} of ${i} — the counts by table are complete)`);
+	let s = i - a;
+	s > 0 && F.error(`  … and ${s} row(s) behind them. Fix the ${a} above and re-run; they resolve with their parents.`);
 }, Ue = async (e) => {
 	let t = z(e, "--target") === "api", n = z(e, "--bundle-key"), i = B(e);
 	if (!i && !(t && n)) return F.error("usage: voltro data import <bundleDir> [--target direct|api] [--api-url <url>] [--token <secret>] [--timeout <seconds>] [--bundle-key <storage-key>] [--tables a,b] [--mode upsert|append|replace] [--on-conflict skip|fail] [--atomic] [--assets] [--no-verify] [--force] [--allow-live] [--dry-run]  (--force: import despite schema drift AND cross-dialect warnings; --dry-run: report what would move, write nothing)"), 1;

package/dist/index.js

@@ -1,4 +1,4 @@
-import { a as e, i as t, n, o as r, r as i, t as a } from "./commands-fsnezHLH.js";
+import { a as e, i as t, n, o as r, r as i, t as a } from "./commands-CYkHTox2.js";
 import { r as o } from "./templates-BR-fb4SP.js";
 //#region src/index.ts
 var s = "framework";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/cli",
-  "version": "0.44.0",
+  "version": "0.44.1",
   "description": "The `voltro` CLI — dev server, codegen, migrations, project scaffolding, agent-docs seeding, and production serve.",
   "keywords": [
     "voltro",
@@ -727,22 +727,22 @@
     "@effect/platform-node": "^0.108.0",
     "@effect/sql": "^0.52.0",
     "@effect/workflow": "^0.19.0",
-    "@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",
+    "@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.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. |
+| **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.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. |
+| **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`
 
@@ -2745,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`)
 
@@ -2977,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/whats-new.md

@@ -1,4 +1,4 @@
-# What's new in 0.44.0
+# 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
@@ -7,32 +7,14 @@ workaround for something that shipped two versions ago.
 
 BREAKING entries name a codemod; run `voltro update` to apply it.
 
-### ⚠ 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.
-
-  **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.
-
-  Migration: `runImport(...)` now resolves to `{ manifest, tablesWritten, rowsWritten, tablesSkipped, rowsSkipped, fullyResumed }`. Read `.manifest` where you read the manifest before.
-
-  **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.
-
-  `--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.
-
-  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.
-
-  **`voltro update` carries you across this** — codemod `0.44.0/01_import-outcome`.
-
 ### Fixed
 
-- **@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.
-
-  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.
+- **@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.
 
-  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 defects, and fixing either alone still leaves a reader stuck.
 
-  Both ends are closed, and they are independent on purpose:
+  **`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.
 
-  - **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 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 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.
+  `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.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",
+    "@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.44.0",
+    "@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.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",
+    "@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.44.0",
+    "@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.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/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.44.0",
+    "@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.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",
+    "@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.44.0",
+    "@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.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",
+    "@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.44.0",
+    "@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.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",
+    "@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.44.0",
+    "@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.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",
+    "@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.44.0",
+    "@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.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/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.44.0",
+    "@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.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",
+    "@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.44.0",
+    "@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.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",
+    "@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.44.0",
+    "@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.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",
+    "@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.44.0",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -12,17 +12,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@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/workflow": "0.44.0",
+    "@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/workflow": "0.44.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.44.0",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

package/templates/apps/api-feature-flags/package.json

@@ -13,18 +13,18 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.44.0",
-    "@voltro/database": "0.44.0",
-    "@voltro/env": "0.44.0",
-    "@voltro/plugin-flags": "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",
+    "@voltro/cli": "0.44.1",
+    "@voltro/database": "0.44.1",
+    "@voltro/env": "0.44.1",
+    "@voltro/plugin-flags": "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.44.0",
+    "@voltro/testing": "0.44.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"