@voltro/cli 0.42.0 → 0.43.1

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

@@ -1,4 +1,4 @@
-# What's new in 0.42.0
+# What's new in 0.43.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,95 +7,67 @@ workaround for something that shipped two versions ago.
 
 BREAKING entries name a codemod; run `voltro update` to apply it.
 
-### ⚠ BREAKING
-
-- **@voltro/cli, @voltro/data-transfer** — **Two security defects on the data-transfer surface, both found by using the feature rather than by reading it.**
-
-  **A `{ profile }` in an admin-export request could name a PATH.** `loadProfile` resolved the client's string with `resolve(cwd, x)` — which returns an absolute path unchanged and lets `../` traverse — and the resolved file is `await import()`ed, which RUNS it. So a holder of the data-transfer secret could make the api process execute any file on the pod: an escalation from "can export prod data" to "can run code", and chainable on an instance whose object storage is a filesystem the same caller can write to.
-
-  `POST /_voltro/admin/export` now accepts a NAME only — `[A-Za-z0-9_-]{1,64}`, resolved under `data-profiles/` and checked to be contained there. **Migration: if you passed a path over `--target api`, move the file to `data-profiles/<name>.ts` and pass `<name>`.** `voltro data export --profile` on a DIRECT target still accepts a path: it runs on the operator's own machine, where a path is not an escalation. No user-authored code changes, so `codemod: none`.
-
-  **An unrecognised masking action copied the value through.** `applyAction` ended in `return input.value`, so a profile with a typo in the action shape (`{ action: 'fake', kind: 'email' }` instead of `{ fake: 'email' }`) exported every row of a `.sensitive()` column verbatim — with a 200 and an audit line counting the column as masked. Measured against a live instance: a masked export of two users came back carrying both real addresses.
-
-  The applier now throws, and `planMasking` refuses the policy BEFORE a row is read: `MaskingError` gained `invalidActions`, reported separately from `unclassified` because the fixes differ — one needs a classification, the other needs the policy corrected.
-
-### Added
-
-- **@voltro/runtime** — A write the database refuses on an integrity rule now raises a typed `ConstraintViolation` instead of an opaque `SqlError`. It carries `{ kind, table, operation, constraint?, column? }`, where `kind` is one of `foreignKey` · `foreignKeyInUse` · `unique` · `notNull` · `check`. Declare it in a procedure's `error:` to pattern-match it; undeclared it still reaches the client as an `InternalError` carrying its own sentence rather than `Failed to execute statement`.
-
-  It carries NAMES and never the driver's message, which on most engines contains row data — postgres attaches the complete failing row to a not-null and a check violation, mysql and mssql echo the duplicate value. Classification is measured against live postgres 17, MySQL 8.4, MariaDB 11, SQL Server 2022 and sqlite.
-
-  Raised from one guard covering every write op (insert · insertMany · upsert · insertIgnore · update · updateMany · delete · deleteMany · hardDelete · patchJson); the tenant-FK case still resolves to `TenantScopeViolation` first.
-
 ### Fixed
 
-- **@voltro/cli, @voltro/data-transfer** — `voltro data import|export` — four defects on the `--target api` path, all found by a consumer seeding a fresh cluster from a bundle.
-
-  **A flag this command does not read is now an ERROR.** `--dry-run` and `--tables` were accepted on the import path and dropped in silence: a preview against a production-shaped cluster ran the import instead (2905 rows, then a 500), and a run narrowed to a one-row table wrote all 10 593. Both are one defect — an argument parser that ignores what it does not understand — so every `voltro data` subcommand now declares the flags it reads per target and refuses the rest, naming the flag and what to use instead.
-
-  **`--dry-run` and `--tables` now work on the import, on BOTH targets.** A dry run reaches every verdict a real run reaches (schema fit, cross-dialect portability, mode legality, the table selection) and stops before the first write; the api path carries them as `x-import-dry-run` / `x-import-tables` and echoes `{ dryRun: true, wrote: false }`. A `--tables` name the bundle does not carry is refused, listing what it does. `--dry-run` on an api EXPORT is refused rather than ignored — previewing a read protects nothing.
-
-  **The schema-drift pre-flight compares the INTERSECTION, not whole schemas.** A bundle's fingerprint covers its source schema regardless of export scope, and two environments never have identical whole schemas, so the check refused every cross-environment seed with a diff whose every line said the difference changes nothing — making `--force` the routine way to import and removing the protection it guards. It now reports only what would break the load: a carried table or column the target lacks, a type mismatch, or a column the target REQUIRES that the bundle carries no value for.
-
-  **A failed row says why.** `reason` was `Failed to execute statement` for every one of 2905 rows. It now names the constraint and the rule (`foreign key tasks_laneId_fkey: the referenced row does not exist [23503]`), or the driver's own message with its code, or — where there is no driver under the failure — the error from the layer that refused.
-
-  Also: `voltro data inspect` accepts a directory bundle instead of dying inside the archive reader with a JSON parse error (`--target api` always unpacks into a directory, even when the path ends in `.vbundle`).
-
-  **Three more, found by running the whole thing against live MariaDB and MySQL** rather than against sqlite:
-
-  - A re-run of a COMPLETED import wrote nothing and reported the bundle's full row count — the resume ledger lives in the bundle directory, so truncating a target and re-importing printed `import complete … 10593 rows` over an empty database. Resume is right; being quiet about it was not. It now warns, names the skipped tables, and says which ledger file to delete. - The deferred-FK recovery pass OVERWROTE the diagnosis. When a held row cannot be written, the resolver retries it with every `reference` column nulled to break a cycle — and that attempt's failure replaced the original reason, so a row whose real problem was one column reported a not-null violation on a column the framework itself had nulled. The recovery attempt no longer records a reason. - MySQL/MariaDB errno **1364** (a statement that OMITS a column which is NOT NULL with no default) is classified as a not-null violation. postgres reports 23502 for that situation and mssql 515, so the mysql family was the only one where "you did not supply a required column" came back unclassified.
-- **@voltro/database** — CHECK constraints were invisible to introspection on **MySQL** — and with them every `.oneOf()` column and every `json_valid` marker.
+- **@voltro/database** — A write recorder that fails inside someone's transaction now says which recorder, on which write, and what the database actually said.
 
-  `information_schema.check_constraints` differs between the two engines of the family: MariaDB carries `TABLE_NAME`, MySQL does not have that column at all. The introspector selected it, the query errored, and an `Effect.orElseSucceed` turned that into an empty list. A swallowed error and an empty result read identically, which is why this needed a two-engine test to surface. The query JOINs `information_schema.table_constraints` for the name now, which both engines answer.
+  `@effect/sql` renders every driver failure as `SqlError: Failed to execute statement` — one sentence that fits a missing column, a dangling foreign key, an over-long value and a duplicate key equally. The driver's own words hang off a SYMBOL on a `FiberFailure`, so a caller who reaches for `.cause` gets `undefined` and concludes there is nothing there.
 
-  `parseEnumCheck` also learned MySQL's rendering. The same clause is stored differently:
+  That is expensive precisely where recorders run: the caller's write was ordinary, and what failed was framework machinery one table over. The message now reads
 
-  mariadb 11 `status` in ('draft','live','done') mysql 8.4 (`status` in (_latin1'draft',_latin1'live',_latin1'done'))
+  ```
+  write recorder '_voltro_row_history' failed while recording an update on 'users':
+  Duplicate entry 'rowver_…' for key 'PRIMARY' [code=ER_DUP_ENTRY errno=1062 …]
+  ```
 
-  MySQL puts a charset introducer before each literal, which the pattern — written against MariaDB's form — did not read. Both are pinned in `enumCheckParity.test.ts`.
+  and the original error is kept as `cause` for anyone who does walk the chain. The failure still takes the transaction down — that is the guarantee and it is unchanged.
 
-  Neither fix completes the round trip on MySQL: `.oneOf()` still comes back unclassified there. That is asserted as a known gap in `oneOfCheck.mariadb.integration.test.ts` (which fails the moment it starts working) and written up in `plans/open/framework/mysql-oneof-roundtrip.md`.
-- **@voltro/database** — `voltro db apply` works on MySQL. It could not create a table with an index, and could not drop a column, on that engine at all.
+  `describeDriverError` (`@voltro/database`) is the shared summariser, built on the existing cause extractor rather than a second walker. It returns nothing when the chain carries nothing driver-shaped, so an ordinary programming error from a recorder arrives as itself instead of wrapped in prose about a database.
+- **@voltro/database** — On MariaDB, a `varchar` column could introspect as `json` because a DIFFERENT table had a json column with the same column name.
 
-  `IF [NOT] EXISTS` outside `CREATE`/`DROP TABLE` is a MariaDB extension — MySQL rejects it with ER_PARSE_ERROR (measured on 8.4 for `CREATE INDEX IF NOT EXISTS`, `ALTER TABLE … DROP COLUMN IF EXISTS`, and `ADD COLUMN IF NOT EXISTS`). The applier emitted the first two, because `@effect/sql-mysql2` reports the dialect `mysql` for both engines and the shared branch had only ever run against MariaDB. A `reference()` column gets an index by default, so in practice most tables were affected.
+  MariaDB names a column-level CHECK after the COLUMN, and those names are unique per table, not per schema. `information_schema.check_constraints` on MySQL has no `TABLE_NAME`, so the introspector recovered it by joining `table_constraints` on `(schema, constraint_name)` — which on MariaDB cross-products every same-named check across every table. Measured on 11.8:
 
-  The applier now asks the SERVER which engine it is (`SELECT VERSION()`; MariaDB stamps itself into the string) and emits the plain form on MySQL. The idempotency `IF [NOT] EXISTS` provided moves into the statement runner, which tolerates exactly the errnos meaning "already in the requested state" — 1061 for a duplicate index name, 1091 for dropping something absent. The engine is read from the connection rather than from `DB_DIALECT` or `variant`, because the DDL has to be legal for the server that receives it and those are what an operator typed.
+  ```
+  a.payload  LONGTEXT      CHECK (json_valid(`payload`))
+  b.payload  VARCHAR(255)  CHECK (`payload` in ('x','y'))
+  
+  join result:  a → json_valid, a → in(…), b → json_valid, b → in(…)
+  ```
 
-  Verified against live MySQL 8.4 and MariaDB 11: a schema evolution — create, add column, add index, drop column — applied through `applyPlan` on both, converging at every step, plus a replayed plan (what a resume does) that must not error on the statements it repeats.
+  So `b.payload` reads as `json`, and `a.payload` picks up an enum it does not have. Downstream that is not a cosmetic label: the planner emits a blocked `alter-column-type` with `from: 'json'` that no `.narrowedFrom()` can honestly acknowledge, because the premise is false — and since the data-transfer manifest records introspected types, the same misreading travels into the bundle and reappears as schema drift on import.
 
-  **sqlite had the same defect, found by the new cross-dialect scenario on its first run.** `ALTER TABLE … DROP COLUMN IF EXISTS` is accepted by postgres, mssql and MariaDB and rejected by sqlite — and the generic emitter, shaped for postgres, is what sqlite used. So `voltro db apply` could not drop a column on sqlite either. The conditional form is now emitted only where it is legal, and the "already dropped" case is tolerated per dialect (`idempotentDdl.ts`).
+  MariaDB's own `check_constraints` HAS `TABLE_NAME`. The introspector asks for it directly now and keeps the join as the MySQL path, where check-constraint names are schema-unique and the join is sound. That asymmetry is why a single-engine test could not see this: the wrong query passes on MySQL.
+- **@voltro/database** — `voltro db apply` could not drop a CHECK constraint on the mysql family at all, and each of the three reasons hid the next.
 
-  `runDialectParity` gained a schema-evolution scenario — create, add column, add index, drop column, applied for real with a convergence check after each step — so the migration APPLIER is now covered on all five dialects. It previously had one scenario covering one op kind, while twenty-two covered the store; that split is why four emitter defects survived.
+  **1. `DROP CHECK` is MySQL-8 syntax.** MariaDB has never had it — measured on 11.8, `ALTER TABLE t DROP CHECK c` is `ERROR 1064`, while `DROP CONSTRAINT c` works on both engines. A plan containing a `drop-check` therefore died on the first one, on a family whose migrations are NOT atomic: the run stopped with the earlier statements committed and no rollback.
 
-  **And a fifth, found by making one MariaDB-only suite two-sided.** `text().unique()` on an unbounded text column created a table on MariaDB and failed the CREATE outright on MySQL: `BLOB/TEXT column 'x' used in key specification without a key length`. The bring-up emitter (`migrate.ts`) wrote an inline `UNIQUE`; the declarative applier had always written a separate PREFIXED unique index. The two emitters disagreeing on one statement is the failure shape this package's own notes describe, and only one engine said so.
+  **2. The name was assumed, not read.** The applier dropped `<table>_<column>_check` — which is only what its own `add-check` would have named it. A CHECK created at table bring-up is INLINE and UNNAMED, so the server names it (`CONSTRAINT_1` / `<table>_chk_1` / the column name). Dropping a name that does not exist reports "does not exist", which is indistinguishable from the "already gone" a resume legitimately produces — so the statement succeeded, the constraint stayed, and the plan re-proposed the identical `drop-check` forever. The name comes from the catalog now.
 
-  `migrate.ts` emits the prefixed index now, through the same `indexStmt` that already owns the per-dialect `IF NOT EXISTS` rule, and names it `<table>_<column>_key` to match the applier's — so the two paths produce the same object.
+  **3. A column-level CHECK cannot be dropped by name on MariaDB at all.** Measured: the catalog lists it under the column's name, `DROP CONSTRAINT` on that name answers 1091, and only redefining the column removes it. The applier now drops by catalog name, ASKS whether the constraint survived, and redefines the column when it did — so a rebuild happens only in the case that needs one.
 
-  **Note the behaviour change on MariaDB.** It accepted the inline form by backing it with a HASH long-unique index, whose hidden `DB_ROW_HASH_n` column breaks the binlog CDC reader (documented in `packages/database/CLAUDE.md`). Uniqueness on such a column is now enforced on the first 191 characters rather than the whole value — which is what `voltro db apply` already did, and what MySQL can express at all. Bound the column with `text().maxLength(n)` if you need full-value uniqueness.
-- **@voltro/sql-mysql** — `insertIgnore` on MySQL was a different feature from `insertIgnore` on MariaDB — and the difference could turn a conflict into an error.
+  **And the same investigation closed the MySQL `.oneOf()` round-trip gap.** `parseEnumCheck` was documented as handling MySQL's rendering and did not: MySQL backslash-escapes the string DELIMITERS (`_utf8mb4\'draft\'`), and the parser rewrote those to the SQL doubling `''` — which is how a quote INSIDE a value is written. Every delimiter became escaped content, every value came back empty, and the filter dropped them. `.oneOf()` now round-trips on MySQL, and the suite that asserted the gap as a known one asserts the round-trip instead.
 
-  The whole diagnostic apparatus — the refusal to report a REJECTED write as a conflict, and the message naming the constraint that actually fired — sat behind a `variant === 'mariadb'` branch. MySQL took an `else` that used no `INSERT IGNORE` at all: look for a row matching the conflict columns, insert if there is none. That cannot hold the one property the method exists for. A caller that looks before anyone else writes sees nothing, so the write it then makes is the one that raises the duplicate-key error `insertIgnore` promises never to raise — reproduced deterministically against both engines with an uncommitted holder (the lookup cannot see the holder's row; the insert cannot proceed until it commits).
+  Plus, on a failed apply: the error now states how many operations were already applied and whether this dialect rolls back. The ledger held that number; it never reached the operator, who had to re-plan and diff the counts to learn how far the run got.
+- **@voltro/plugin-versioning** — `versioningPlugin({ timing: 'in-transaction' })` built its history row's primary key from `(rowId, version)` while the version counter three lines above was scoped to `(tableName, rowId)`. Two versioned tables carrying the same row id therefore collided — permanently.
 
-  Underneath sat the reason a straight port would still have produced nothing: **MySQL answers a PREPARED `SHOW WARNINGS` with 1295 ER_UNSUPPORTED_PS**, and the warning read is deliberately failure-tolerant (a diagnostic must never replace the caller's real problem), so it returned an empty list — indistinguishable from a statement that raised nothing. MariaDB accepts both protocols. The read goes through the text protocol now, the same spelling the binlog path already used for `SHOW MASTER STATUS`.
+  The shape is not exotic: `actors.id === users.id` is what the framework's own audit trail asks for, an `actors` row whose id is the user's so an audited write satisfies `createdBy → actors`. In an app that follows it, every user row has a twin.
 
-  Both engines now run one `INSERT IGNORE` and reach one decision function. What differs is only the probe for "did it land": MariaDB has `INSERT IGNORE … RETURNING *`; MySQL has no RETURNING, so the row's own key answers instead. `SELECT ROW_COUNT()` — the obvious alternative — cannot be used: measured on both engines, it reports 1/0 correctly but CLEARS the warning list on MySQL, and run the other way round returns `-1` because `SHOW WARNINGS` is then the last statement. The count and the diagnosis cannot both be had; the diagnosis is the one worth having.
+  The collision does not heal, and that is what turns a duplicate into an outage. The second table's insert fails, so its history row is never written, so `maxOf` for that table stays `null`, so the next attempt computes the same version and the same id. Every write to that row is dead from then on — surfacing as `ER_DUP_ENTRY` on an ordinary `store.update`, naming a row id in a table the caller never wrote to.
 
-  Found by converting the suite that covers this to run on both engines, which is also where every MySQL assertion in it had been reporting the driver's generic `Failed to execute statement`.
-- **@voltro/database** — A `reference()` column now creates a real foreign key on **MySQL**. It did not before: MySQL/InnoDB parses a column-inline `REFERENCES` clause and discards it — no constraint, no warning, the `CREATE TABLE` succeeds — while MariaDB honours the identical clause. Both engines reach the same emitter (the driver reports the dialect `mysql` for either), and every mysql-family integration suite in the repo runs against MariaDB, so referential integrity that postgres, MariaDB, mssql and sqlite all enforced was silently absent on MySQL.
+  The key is `(table, rowId, version)` now — the same shape the post-commit path always built. It stays deterministic (no clock, no process-local counter), which is what lets it survive a replica restart; it just carries every part of the key it claims to be unique over.
 
-  Both emitters now write a table-level `CONSTRAINT <table>_<column>_fkey FOREIGN KEY …` inside the `CREATE TABLE`, which both engines honour and which `CREATE TABLE IF NOT EXISTS` keeps idempotent. Existing MariaDB schemas are unaffected — the introspected snapshot carries no constraint name, so nothing re-plans.
+  **No cleanup is needed for rows already written.** They keep their old ids and belong to whichever table wrote them; the new keys cannot collide with them, and `byRow` is not unique. An app blocked by this is unblocked by the upgrade alone.
 
-  Verified against live MySQL 8.4: the constraint is in the catalog, the server refuses an orphan row, introspection reads it back, and the re-plan is empty.
-- **@voltro/sql-turso, @voltro/testing** — A migration on turso applied correctly and then reported itself as failed: `voltro db apply` ran an `add-column`, re-planned to prove convergence, saw the column still missing, proposed the same operation again, and the second execution died with `duplicate column name`. No fingerprint was recorded, so every subsequent boot re-proposed the same work — and the error named the migration applier, which had done nothing wrong.
+  Covered twice: the recorder against a port that refuses duplicates (the mechanism, including that a repeat does not settle), and two versioned tables sharing an id against live postgres (the real primary key, inside the caller's transaction). The suite that existed exercised ONE table, which cannot produce a collision at all — and read exactly like a suite that covered this.
 
-  The client caches one prepared statement per connection per SQL text, and a prepared statement carries the schema it was prepared against. So a cached `PRAGMA table_info(t)` keeps answering with the old columns after a DDL — it is never re-prepared, so sqlite's schema-cookie re-preparation never runs. The invalidation for this existed, on the unprepared path (`sql.unsafe`) only, and the migration path sends its DDL through the PREPARED one. The statement that changed the schema and the cache that had to be dropped were on the same connection, one function apart, with nothing connecting them.
+### Internal (no consumer-facing effect)
 
-  Any schema-changing statement now drops that connection's cached statements, whichever path it arrived on.
+- **@voltro/sql-mysql** — Two test-only defects in `sql-mysql`, both found by a release gate, both of the same family: a check that could not fail, and a failure reported in the wrong place. No product code changed.
 
-  Three hypotheses were measured and disproven before this one — an applier retry (each operation is issued once), an MVCC snapshot (two raw libsql clients both see the DDL), and a pool-wide cache problem (four connections held open together, the PRAGMA prepared on each, a DDL on one: the other three answer correctly, because SQLite bumps the schema cookie and the driver re-prepares on the connections that did not make the change).
+  **An assertion that could not fail.** `dropCheckSyntax.integration.test.ts` fell back to a HAND-BUILT plan when the planner produced no operations — and the fabricated operation was a `drop-check`, which is exactly what the next line asserts the plan contains. So an engine whose planner stopped emitting it would have been handed one and reported green. The fallback is deleted; both engines produce the operation now, which is what this release fixed, and the assertion is load-bearing again (4/4 on mysql AND mariadb without it).
 
-  The two `runDialectParity` scenarios that drive the migration applier were skipped for turso on the strength of that misreading. They run now, and the per-fixture opt-out that carried the skip is deleted: it was holding a defect open while reading like a documented limitation.
+  It surfaced as a TYPE error rather than a false pass, because the fallback's object widened `plan` into a union `applyPlan` does not accept. Worth noting which check caught it: `vitest` transpiles without type-checking, so the suite was green and only `tsc` objected — the gate's `typecheck` and `lint` steps are what went red.
 
-  **`apiSurface: compatible`, and the reason is a date rather than an argument.** Removing `DialectFixture.skipApplierScenarios` moves a line in `@voltro/testing`'s golden, so the changelog's narrowing detector flags it — and it is right to, because that detector's baseline is `origin/main`. But the field never reached a RELEASE: it was added after `v0.41.0` and deleted before this one, both inside the same unreleased range. `git show v0.41.0:packages/testing/etc/testing-dialect.api.md` does not contain it. No published version ever offered it, so no consumer can have set it, and there is nothing to migrate.
+  **A wait that gave up in silence.** `waitFor` in both binlog CDC suites looped to a deadline and then RETURNED, so a "prove the reader is live" wait that expired let the test carry on, kill the binlog dump thread, and fail twenty lines later on `expect(ids).toContain('todo_wd_before')` — an assertion about a different claim, in a different place. It throws now, naming the wait and the window, and all twelve call sites carry a label.
 
-  Worth writing down because the first reading of this was wrong in the safe direction: it was filed `BREAKING` with a codemod on the strength of "an optional field disappeared from a published package's surface", which is the right instinct and the wrong conclusion here. **"Removed relative to main" is not "removed relative to what users have"** — a symbol that lives and dies between two tags trips the detector while breaking nobody, and the difference is only visible by asking the last TAG rather than the last commit.
+  The window is named too: `FIRST_ATTACH_MS = 30_000`, up from 12 s. The reasoning is the 40 s window already in the same file, whose comment says a re-attach plus binlog catch-up takes longer under a loaded full-suite run — a FIRST attach does both and only skips the backoff, so 12 s beside 40 s was an asymmetry the file's own reasoning did not support. That is an argument from the neighbouring comment, not a measurement; if it expires again, `waitFor` now says which wait and for how long, and that number is the one to argue with rather than raising this one twice.

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

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

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