@voltro/cli 0.45.0 → 0.47.0

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

@@ -1,4 +1,4 @@
-# What's new in 0.45.0
+# What's new in 0.47.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,101 +7,28 @@ workaround for something that shipped two versions ago.
 
 BREAKING entries name a codemod; run `voltro update` to apply it.
 
-### ⚠ BREAKING
+### Changed
 
-- **@voltro/protocol, @voltro/cli, @voltro/voltro** — `source:` on a query is now typed against the app's own tables, so a typo or a missed rename is a compile error instead of a subscription that goes quiet.
+- **@voltro/database, @voltro/data-transfer, @voltro/cli, @voltro/plugin-storage** — A `--mode replace` no longer writes per-row history, and three things that were reported alongside it.
 
-  A `source:` is matched by NAME against change events, so a name matching nothing does not break the query — it makes it permanently silent: it compiles, boots, serves its first snapshot and never updates. From the outside that reads as a feature that does nothing, with a correct write path and green tests behind it. The boot has warned about this since 0.26.0, on both paths; a warning is read once, and a rename lands in a diff where nobody is checking strings.
+  **Write recorders are suspended for a `replace`.** A replace SETS a state; it does not change rows, so a per-row history entry describes something that did not happen. A deployment measured what that costs: they run `versioningPlugin({ timing: 'in-transaction' })` on 70 of 80 tables, so one import wrote 242 950 history rows and doubled the write load of the most expensive run they make — and those rows were the source of refused writes they spent three rounds diagnosing.
 
-  `voltro dev` writes `voltro-tables.generated.d.ts` beside the generated rpc group, augmenting `VoltroTableNames` with the FULL live set — app entities, plugin `extendSchema.tables` and the framework's own — from the same binding the boot audit resolves against, so the type and the warning cannot disagree about which tables exist. `source:` narrows to those names.
+  The deciding argument is not the cost. **The import path had already decided this, and the recorder was the one layer that did not hear.** These routes write through the RAW store on purpose — no tenant scoping, no row filter, no `audit()` stamping. A recorder fired anyway because it hangs one level below the wrapper. Suspending it makes the layers agree.
 
-  Nothing changes at runtime: these are still string literals, so a descriptor carrying them is as browser-loadable as before. That is what ruled out accepting the table VALUE — a descriptor is loaded value-level by the web client, and a table value drags `@voltro/database` across that boundary.
+  Suspended for `replace` only: an `upsert` or an `append` CHANGES existing state, which is exactly what a recorder is for. Scoped per execution context rather than by a switch, because an import runs while the app serves requests and a process-global flag would silently drop recording for everything concurrent with it. And every such run SAYS what it suspended — dropping history quietly would be the same defect in a nicer costume.
 
-  **Breaking, and filed that way after being written up as additive.** The test is not whether a symbol disappeared, it is whether code that compiled can stop: `['tasks', 'agent_messages']` was assignable and is not, which is the whole point where the name is stale and an obstacle where the source is genuinely computed. `normalizeSource`'s parameter narrowed with it. The wide shape stays public as `ReactivitySourceValue` for the computed case.
+  This also removes the reason a staged `replace` used to fall back. A recorder is keyed by table name, so a staged write found none and the recorder never ran; rather than record inconsistently, the run took the slower path. For the deployment above that meant the staged path could never activate — permanently, on every environment.
 
-  The break does NOT land at upgrade time, which is why the codemod is a written note rather than a transform: right after `voltro update` the generated file does not exist, `keyof VoltroTableNames` is `never`, `TableName` falls back to `string`, and everything compiles as before. The narrowing switches on at the next `voltro dev` — a different command, by which point the change that caused it is no longer what the reader is looking at. A transform could not have found the sites either, since the type that rejects them has not been generated yet. And the two things `tsc` flags — a stale name versus a runtime-computed one — want opposite fixes, so the mechanical one (widen the annotation) would convert every defect this surfaces back into the quiet subscription it exists to expose.
+  **`voltro codegen` wrote a truncated table declaration.** It discovered tables with the walk that collects the rpc GROUP's inputs — descriptors, workflows, events, and deliberately no `*.entity.ts`. So the generated `voltro-tables.generated.d.ts` listed the framework's tables plus `actors`, which the framework injects. Measured downstream: 37 names where a `voltro dev` boot writes 117, and 299 `TS2322` errors from every `source:` naming one of their own tables. The way in was our own message — `voltro test` refuses a stale rpc group and tells you to run `voltro codegen`. Table discovery has its own walk now, and a test compares the two walks' RESULTS on a real tree rather than trusting they mean the same thing.
 
-  Delete the generated file and `source:` widens back to `string`.
+  **The eager-relation doctor rule missed the state that is most wrong.** It resolved relations only against the tables a query already DECLARED, on the reasoning that the base is virtually always in `source:`. Measured: a query reading `projects` while declaring only `projectTeams` produced no finding at all, while the same query with the base added produced two. The base is a fact about the executor, so it is read from the executor now.
 
-  One deliberate asymmetry, stated because it is one: runtime READERS of a descriptor's source stay wide (`ReactivitySourceValue`). Narrow where an author writes, stay wide where the framework reads — a reader that refused an unknown name would be asserting a fact it cannot check, and the first thing it would reject is the stale name it exists to report.
+  **A rollback capture says when its path shares the root filesystem.** The 409 answered "is storage configured", which is not the question — a `filesystem` provider pointed at a container directory with no volume behind it passes it and dies with the pod. What a process CAN observe is that a mounted volume is a different filesystem: `pathDurability` compares device ids, and a capture landing on the same device as `/` says so. Three-valued on purpose, and explicitly not an alarm on a development machine, where everything is one device and nothing is a pod.
 
-### Added
+  **And the import records ITSELF, once.** Dropping per-row history left an operator asking "was this data imported, and when" with nothing to read, and trading too much for none is not obviously the better trade. `_voltro_data_imports` carries one row per RUN: the mode, the transport, the bundle, the SOURCE deployment's schema fingerprint, the counts, and — for the run an operator is actually looking for — the failure. It is written for a failed import as well as a finished one; a trail that only records successes goes quiet exactly when it is needed.
 
-- **@voltro/cli** — `voltro doctor` reports a query that eager-loads a relation and does not declare its table in `source:` — the failure that looks like a broken feature and is not.
+  Best effort, unlike the interrupted-replace marker, and the difference is deliberate: the marker is a safety interlock and a run that cannot write it must not proceed, while history is valuable and not load-bearing. A target that has not been migrated yet still imports, and says the trace could not be written.
 
-  The write lands, a reload shows it, every test of the write path is green, the name in `source:` is spelled right and the table exists. So neither the typed `source:` nor the boot audit has anything to say, and the only observer is a user watching a panel that does not move.
+  Two things it learned from being wired. The table is `.nonReactive()` — nobody subscribes to "an import happened", and a reactive bookkeeping write showed up in every suite that counts the LOAD's writes. And it is written only when the target actually DECLARES the table: the in-memory store accepts a write to any name, so an absent table cannot be detected by the write failing, and inventing the row would put a framework write into every embedder's counts.
 
-  ```
-  ✗  1 query loads a relation it does not declare:
-     tasks.getById: eager-loads `subTasks` from 'tasks' but does not declare
-     'task_sub_tasks' in `source:` — the view will not update when 'task_sub_tasks' changes.
-  ```
-
-  No exception list, deliberately. An eager-loaded relation is composition by definition — its rows are IN the result — and its table comes from the relation registry, so the missing name is a fact rather than an inference. A many-to-many is reported twice when needed: adding or removing a link writes only the JUNCTION row, so declaring the target alone leaves the list stale on exactly the operation a user performs to change it. A computed `.with()` key yields nothing rather than a guess.
-
-  The general question — every table an executor reads — is NOT answered, on purpose: it needs a compose-versus-restrict judgement a scan can only infer from syntax, and a rule that guesses on a correct codebase teaches its reader to ignore it. Design in `plans/open/framework/source-completeness.md`.
-
-  Two things around it:
-
-  - **The stale-`source:` audit covered queries only, on both boot paths.** A stream carries a `source:` too, and a stale one there is the same permanently quiet subscription with a longer-lived connection behind it. Both paths now take the set from one `auditableSources`. - **`voltro codegen` writes the typed-`source:` declaration too**, from the same shared `declaredTableNames` merge the boots use. Letting it lag was the bad direction: a table added since the last `voltro dev` would make a CORRECT `source:` a type error. Both commands now say what they wrote — the narrowing has a silent no-op if the app's tsconfig does not pick the file up, so the write has to be loud enough that a reader can check.
-
-### Fixed
-
-- **@voltro/database, @voltro/sql-mysql** — A binding failure names the TYPE of every value, so the culprit is read rather than guessed.
-
-  `ER_WRONG_ARGUMENTS` / 1210 reads like a count problem and often is not: a statement with twelve columns and twelve placeholders is internally consistent, and the driver is refusing one VALUE it cannot bind. Measured against a live mariadb 11.8 and mysql 8.4 (mysql2 3.22), binding to a PREPARED statement:
-
-  | value | mariadb | mysql | |---|---|---| | plain object | **1210** | accepted | | array | **1210** | accepted | | bigint | accepted | accepted | | Invalid Date | accepted | 1292 |
-
-  So the same row binds on one engine of the family and not the other — which is how a suite comes to fail on mariadb and pass on mysql in the SAME run, and why the type of each binding is the diagnosis rather than a detail.
-
-  `describeDriverError` now reports `bindings: id:string data:Object changedAt:Date …` beside the placeholder count and the statement. Types only; a value there would be row data in a log line, the same reason the statement is carried only in its placeholder form.
-
-  The types travel as a FIELD, not in a message. That is load-bearing: a failing write recorder rethrows with its own sentence, so anything said only in text is dropped exactly where it is needed. `extractDbCause` collects it like any driver field, so it survives every wrapper between the failing statement and the log.
-- **@voltro/database, @voltro/testing** — A driver error now carries the two numbers a binding failure is made of.
-
-  `ER_WRONG_ARGUMENTS` / errno 1210 means the parameter count did not match the placeholder count — reproduced against mariadb 11.8 by sending one parameter for two `?` — and the message says only `Incorrect arguments to mysqld_stmt_execute`. Neither number was reachable from the error, so an investigation into one of these starts by eliminating hypotheses instead of subtracting.
-
-  `describeDriverError` reports `placeholders=N` and the statement, and the statement is carried ONLY in its placeholder form. That restriction is measured, not cautious: against mysql2 3.22 the prepared path (`execute`) leaves `?` in `err.sql` because the server did the binding, while the text path (`query`) interpolates and the same field then holds row DATA. The placeholder is the discriminator, and the form that keeps it is exactly the form 1210 arises in.
-
-  Alongside it, `reportEngineVersion` (`@voltro/testing`): a dialect suite prints the engine BUILD it ran against. A suite that is green on a developer machine and red in CI is only comparable if both name their software, and the test compose file uses moving tags — so "the same tag" is not the same build, and checking the tag locally observes what it points at today rather than what the runner resolved.
-- **@voltro/database, @voltro/plugin-versioning, @voltro/plugin-flags** — A versioned table whose NAME was long enough could not be written to at all.
-
-  `id()` is `VARCHAR(64)` on mysql / mariadb and `NVARCHAR(64)` on mssql, and unbounded `TEXT` on postgres and sqlite. The versioning recorder built its history key by concatenation — `rowver_<tableName>_<rowId>_<version>`, which is `42 + len(tableName)` characters for a 32-character row id — so a 22-character table name fit and a 23-character one produced `ERROR 1406 (22001): Data too long for column 'id' at row 1`. A recorder runs on EVERY write, so this was not a refused import: it was a table nobody could write to, on three of five dialects, at a boundary no one can see when naming a table.
-
-  `derivedRowId(prefix, …parts)` (`@voltro/database`) derives a deterministic key of CONSTANT width — `rowver_<32 hex>`, 39 characters whatever goes in — joined over a `\u0000` separator so the parts stay injective (a `_`-joined key cannot tell `('a_b','c')` from `('a','b_c')`). Widening the column was the alternative and moves the wall rather than removing it; `id()` is also every user table's PK type. Nothing legible is lost: every table deriving a key this way already stores the parts in their own columns.
-
-  The same construction was in `plugin-flags` (`flag_<key>`, over an unbounded user-chosen flag key) and is fixed with it. A guard scans framework sources for an `id:` composed by interpolation and requires the helper, with an allowlist whose entries each name why their parts cannot grow — and which fails if an entry stops matching.
-
-  Also fixed: the versioning suite's live coverage was postgres-only, and postgres is one of the two dialects where that column is unbounded, so it was structurally incapable of seeing this. `@voltro/sql-mysql` is a test devDep of `@voltro/plugin-versioning` now, with a mysql+mariadb case driving an ordinary insert and update against a 33-character table name.
-- **@voltro/database, @voltro/cli** — Two gaps on the `--target api` path, both about a failure that is present and unreadable.
-
-  **The driver was unreachable behind a WRAPPED rejection.** `extractDbCause` unwrapped a `FiberFailure` at the root only, so one reached through a `.cause` link stopped the walk — it carries `stack`, `message` and `name` and nothing else, which is indistinguishable from "no driver under this". That is exactly the shape a failing write recorder produces: it rethrows `new Error(<what it was doing>, { cause: err })` where `err` is the rejection its own insert made. So the same database refusal classified where no recorder runs and degraded to the bare runtime rendering where one does — which is the difference between the direct importer and an import through a running app with versioning or audit on. The walk now unwraps at every link.
-
-  **And the refusal report was never printed on that transport.** A refusal that crossed HTTP arrives as a 500 whose message embeds the `RowsRefusedError` as JSON; the CLI printed that body raw. So the operator on the transport that exists for "the database is somewhere you cannot open a shell" got the one output that has to be triaged by hand — and tallying the capped row list is how a per-table distribution gets reported that is not the real one. `--target api` now prints the same report as the direct path, `byTable` line and cap notice included.
-- **@voltro/data-transfer, @voltro/cli** — Two reporting defects that made a refused import unreadable, both of the shape "the payload is present and property access is not the way to it".
-
-  **A refusal lost its tag on the mode that raises it most.** `--mode replace` runs in one transaction by default, and rolling that back needs a rejection — which the atomic wrapper obtained by throwing `new Error(Cause.pretty(cause))`, a rendering rather than the failure. From there the typed error could not come back: it was re-wrapped as a `BundleError` carrying itself as text. So `Effect.catchTag('RowsRefusedError', …)` matched nothing on the default path, `ImportError`'s union was a claim that path could not honour, and the CLI's refusal report — which branches on the tag — printed nothing at all. The typed error is thrown and passed through now; `asImportError` is exported for callers who catch the rejection rather than the effect.
-
-  **And the report read the tag off a `FiberFailure`.** What `Effect.runPromise` rejects with does not expose `_tag` by property access, so the renderer took its "not my error" branch on every direct-path run while being wired, tested and correct — the test drove the renderer with the error object, which is not the shape the call site produces. A reported refusal now also ENDS the command instead of being rethrown into `fatal unhandled cli error`: a refusal is a condition with a named cause, not a framework defect.
-
-  **An api host is no longer reported as an unreachable database.** A connect failure carries an address, a port and an errno — the same shape a database driver's carries — and one global handler renders that shape, so `--target api --api-url https://…` against a stopped instance printed `the database is not reachable at <api-host>:443 … Configured by: DB_URL` with `DB_URL` not in play. The transport names its own failure now (`InstanceUnreachable`), and the database explainer declines an endpoint whose PORT cannot be a database — judged by port because a driver reports the resolved address, so a host comparison would silence the real message for anyone naming their database by hostname.
-
-### Internal (no consumer-facing effect)
-
-- **@voltro/sql-postgres** — A test teardown terminated connections its own pool was still closing, and the resulting error failed the RUN rather than any test.
-
-  `clusterColdStart` drops a per-run database, and the runners it spawned are killed with SIGKILL, so their backends never close — hence the deliberate `pg_terminate_backend` before the `DROP`. But `pool.end()` resolves once it has ASKED the pool to close, not once every socket is down, so the terminate could also land on a connection belonging to the test itself. `pg` reports that as an `error` event on the idle client, and an unhandled one takes down the process.
-
-  The shape it took on a release gate is the reason this is written down: **36 of 36 test files green, and the suite exiting 1.** Nothing points at the teardown — the failure is attributed to whichever suite happened to run last, which is a different one each time. A connection error while we are tearing the database down carries no signal, so it is handled where it arises.
-
-  Test-only; no product code changed.
-- **@voltro/plugin-auth** — The TOTP skew-window test uses a fixed secret. Test-only; no product code changed, and the assertion is unchanged.
-
-  It failed once on a release gate — `expected true to be false`, meaning a code two steps outside the ±1 window verified. That is the shape of a security defect, so it was treated as one until measured:
-
-  - `TOTP_SKEW` is 1 and the verify loop checks exactly three counters, compared with `timingSafeEqual`; - `T0` is a constant and the clock is injected, so the only varying input was `generateTotpSecret()`; - over **50 000 fresh secrets**: zero collisions between the ±2 codes and the ±1 window (pure chance predicts ~0.3), zero degenerate secrets, uniform length; - **60 consecutive runs** of the file: green.
-
-  So the implementation is sound and that red was two 6-digit codes coinciding — about six in a million per run. Worth stating plainly: that makes the observed failure a one-in-167 000 event, which fits every measurement and is still remarkable. It was not reproduced.
-
-  The fix is to remove the coin flip rather than to re-run until green. A random secret buys this test nothing — the property under test is the WIDTH of the window, which does not depend on which secret is used. It only buys a rare red that costs a diagnosis cycle and teaches the reader to re-run. Pinned, so the next failure there means the window moved.
+  **Measured at the reported magnitude.** 114 tables, 243 048 rows, real MariaDB, staged replace: the whole run takes 56.5s and the DESTRUCTIVE TRANSACTION takes **1.13s**. The window in which a dead process can leave a half-replaced target is the second number; before this it was the first.

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

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

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

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

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