@voltro/cli 0.2.2 → 0.3.0

package/dist/index.d.ts

@@ -7,6 +7,8 @@ export declare type CommandSpec = {
     readonly summary: string;
     readonly status: 'wired' | 'stub';
     readonly run: (args: ReadonlyArray<string>) => Promise<number>;
+    /** Internal command — dispatchable but omitted from `voltro help`. */
+    readonly hidden?: boolean;
 };
 
 export declare const dispatch: (argv: ReadonlyArray<string>) => Promise<number>;

package/dist/index.js

@@ -1,4 +1,4 @@
-import { i as e, n as t, r as n, t as r } from "./commands-DQy4812j.js";
+import { i as e, n as t, r as n, t as r } from "./commands-CXESev-z.js";
 //#region src/index.ts
 var i = "framework";
 //#endregion

package/dist/{serveCommand-93rRdEp0.js → serveCommand-Dttqe5Ms.js}

@@ -1,6 +1,6 @@
-import { A as e, B as t, C as n, D as r, E as i, G as a, H as o, Kt as s, L as c, O as l, Q as u, R as d, S as f, T as p, U as ee, V as te, W as ne, X as re, Y as m, Z as ie, _ as ae, b as oe, d as se, f as h, g as ce, h as g, i as _, it as v, j as le, k as ue, m as de, n as fe, o as pe, p as y, q as me, s as b, t as x, tt as S, v as C, w as he, x as ge, y as w, z as _e } from "./dev--jHe1vcu.js";
+import { A as e, B as t, C as n, D as r, E as i, G as a, H as o, Kt as s, L as c, O as l, Q as u, R as d, S as f, T as p, U as ee, V as te, W as ne, X as re, Y as m, Z as ie, _ as ae, b as oe, d as se, f as h, g as ce, h as g, i as _, it as v, j as le, k as ue, m as de, n as fe, o as pe, p as y, q as me, s as b, t as x, tt as S, v as C, w as he, x as ge, y as w, z as _e } from "./dev-x_VqbV_8.js";
 import { a as ve, r as ye } from "./startupRunner-DhlX9nqd.js";
-import { a as T, t as be } from "./apiBuild-o70rjpVJ.js";
+import { a as T, t as be } from "./apiBuild-DdgYydVJ.js";
 import { join as xe } from "node:path";
 import { pathToFileURL as Se } from "node:url";
 import { Cause as Ce, Effect as E, Layer as D, ManagedRuntime as we } from "effect";

package/dist/serveEntry.js

@@ -1,4 +1,4 @@
-import { At as e, nt as t } from "./dev--jHe1vcu.js";
+import { At as e, nt as t } from "./dev-x_VqbV_8.js";
 import { a as n } from "./startupRunner-DhlX9nqd.js";
-import { t as r } from "./serveCommand-93rRdEp0.js";
+import { t as r } from "./serveCommand-Dttqe5Ms.js";
 export { e as loadDotEnv, n as registerAppModules, t as registerDriver, r as runServe };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/cli",
-  "version": "0.2.2",
+  "version": "0.3.0",
   "description": "The `voltro` CLI — dev server, codegen, migrations, project scaffolding, agent-docs seeding, and production serve.",
   "keywords": [
     "voltro",
@@ -52,27 +52,30 @@
     "@effect/platform-node": "^0.107.0",
     "@effect/sql": "^0.51.1",
     "@effect/workflow": "^0.18.2",
+    "@voltro/ai": "0.3.0",
+    "@voltro/cache": "0.3.0",
+    "@voltro/data-transfer": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/kv": "0.3.0",
+    "@voltro/logger": "0.3.0",
+    "@voltro/plugin-auth": "0.3.0",
+    "@voltro/plugin-broadcast": "0.3.0",
+    "@voltro/plugin-mail": "0.3.0",
+    "@voltro/plugin-storage": "0.3.0",
+    "@voltro/plugin-webhooks": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
+    "@voltro/serverless": "0.3.0",
+    "@voltro/workflow": "0.3.0",
+    "chokidar": "^5.0.0",
+    "ioredis": "^5.11.1",
+    "ts-morph": "^28.0.0"
+  },
+  "optionalDependencies": {
     "@tailwindcss/vite": "^4.3.2",
     "@vitejs/plugin-react": "^6.0.3",
-    "@voltro/ai": "0.2.2",
-    "@voltro/cache": "0.2.2",
-    "@voltro/data-transfer": "0.2.2",
-    "@voltro/database": "0.2.2",
-    "@voltro/env": "0.2.2",
-    "@voltro/kv": "0.2.2",
-    "@voltro/logger": "0.2.2",
-    "@voltro/plugin-auth": "0.2.2",
-    "@voltro/plugin-broadcast": "0.2.2",
-    "@voltro/plugin-mail": "0.2.2",
-    "@voltro/plugin-storage": "0.2.2",
-    "@voltro/plugin-webhooks": "0.2.2",
-    "@voltro/protocol": "0.2.2",
-    "@voltro/runtime": "0.2.2",
-    "@voltro/serverless": "0.2.2",
-    "@voltro/workflow": "0.2.2",
-    "chokidar": "^5.0.0",
     "esbuild": "^0.28.0",
-    "ioredis": "^5.11.1",
     "tsx": "^4.23.0",
     "vite": "^8.1.4"
   },

package/templates/AGENTS.core.md

@@ -220,8 +220,22 @@ primitive → just save; the supervised dev loop respawns and regenerates.
   But DO call `assertOwnTenant(input.tenantId, ctx.request.subject)` (from
   `@voltro/plugin-multitenancy/guard`) in custom mutations that write raw rows,
   and declare `error: TenantMismatch` — subscriptions are auto-scoped, writes are not.
+- **Gate authorization declaratively with `guards:`.** Add
+  `guards: [{ scope: 'notes:write' }]` to `defineMutation`/`defineQuery`/`defineAction`
+  — the framework enforces it BEFORE the executor (before the txn opens), fails
+  with a typed `ScopeError` (auto-merged into the wire error union), and checks the
+  caller's EFFECTIVE scopes (raw ∪ rbac roles). Guards are browser-safe DATA (scope
+  strings + a pure `resource: (input) => id` extractor — never a server fn). Use the
+  in-handler `ctx.access.has(scope)` / `yield* ctx.access.require(scope)` (or rbac's
+  `permission()`) only for checks that need LOADED data (row ownership).
 - **Don't store secrets in the schema or in `Subject`.** Declare env via
   `defineEnv` (`configuration.md`); carry only ids in `Subject`.
+- **In production, `voltro build` BEFORE `voltro serve`.** A production
+  (`NODE_ENV=production`) serve REQUIRES the precompiled serve bundle and fails
+  loud if it's missing — production never transpiles on demand. The generated
+  Dockerfiles already do `voltro build` then `voltro serve`; if you write your
+  own prod start, build first. (`voltro dev` + a non-prod local `serve` still use
+  tsx.) Depth: the deployment topic.
 - **Don't copy prod data down unmasked.** `voltro data export` (and
   `--target api`) reads REAL rows — PII included. Copying prod → dev/stage MUST
   go through a masking profile (`--profile`; classify columns `.sensitive()` /

package/templates/AGENTS.md

@@ -220,8 +220,22 @@ primitive → just save; the supervised dev loop respawns and regenerates.
   But DO call `assertOwnTenant(input.tenantId, ctx.request.subject)` (from
   `@voltro/plugin-multitenancy/guard`) in custom mutations that write raw rows,
   and declare `error: TenantMismatch` — subscriptions are auto-scoped, writes are not.
+- **Gate authorization declaratively with `guards:`.** Add
+  `guards: [{ scope: 'notes:write' }]` to `defineMutation`/`defineQuery`/`defineAction`
+  — the framework enforces it BEFORE the executor (before the txn opens), fails
+  with a typed `ScopeError` (auto-merged into the wire error union), and checks the
+  caller's EFFECTIVE scopes (raw ∪ rbac roles). Guards are browser-safe DATA (scope
+  strings + a pure `resource: (input) => id` extractor — never a server fn). Use the
+  in-handler `ctx.access.has(scope)` / `yield* ctx.access.require(scope)` (or rbac's
+  `permission()`) only for checks that need LOADED data (row ownership).
 - **Don't store secrets in the schema or in `Subject`.** Declare env via
   `defineEnv` (`configuration.md`); carry only ids in `Subject`.
+- **In production, `voltro build` BEFORE `voltro serve`.** A production
+  (`NODE_ENV=production`) serve REQUIRES the precompiled serve bundle and fails
+  loud if it's missing — production never transpiles on demand. The generated
+  Dockerfiles already do `voltro build` then `voltro serve`; if you write your
+  own prod start, build first. (`voltro dev` + a non-prod local `serve` still use
+  tsx.) Depth: the deployment topic.
 - **Don't copy prod data down unmasked.** `voltro data export` (and
   `--target api`) reads REAL rows — PII included. Copying prod → dev/stage MUST
   go through a masking profile (`--profile`; classify columns `.sensitive()` /

package/templates/agent-docs/_manifest.json

@@ -35,7 +35,7 @@
       "group": null,
       "description": "The voltro CLI — every command, grouped by purpose, with the flags that actually matter.",
       "path": "agent-docs/cli.md",
-      "files": 8
+      "files": 9
     },
     {
       "id": "configuration",

package/templates/agent-docs/cli.md

@@ -25,6 +25,7 @@ The dispatcher routes `voltro <command> [args]` to the matching subcommand and p
 | [Build & run](/docs/cli/build-and-start) | `build`, `start`, `serve` |
 | Deploy | `deploy` (`plan` — auto-detect the target tier per app + function), [`serverless`](/docs/deployment/serverless-functions) (`list` / `dev` / `serve` / `build` / `deploy`), [`static`](/docs/deployment/static-sites) (`hosts` / `deploy`) |
 | [Database](/docs/cli/migrate) | `migrate`, `db` (`plan` / `apply` / `plans` / `drift` / `squash` / `restore-snapshot` / `migrate` / `rollback` / `status` / `seed`) |
+| [Update](/docs/cli/update) | `update` (`--to` / `--dry-run` / `--force` / `--exact`) — bump every `@voltro/*`, install, run the codemods that adapt your source to the new version |
 | [Data transfer](/docs/cli/data) | `data` (`export` / `import` / `unpack` / `inspect` / `backup` / `restore`) — directory + single-file `.vbundle` bundles, streaming assets, masking, at-rest encryption |
 | Ops / infra | `cache` (`status` / `flush` / `invalidate`), `add` (`redis`), `baseline` (`list` / `status` / `set`), `schedule-manifest`, [`storage`](/docs/plugins/storage) (`doctor` / `cors`) |
 | AI / data | `embeddings backfill <table> --text <field> --vector <field>` — (re)embed rows the `vectorEmbedding()` mixin missed (pre-existing rows / a model change); `--dry-run` to preview |
@@ -149,6 +150,7 @@ The HTTP surface is reachable directly too — e.g. `curl -s localhost:4000/_vol
 - [Dev](/docs/cli/dev) — what happens during `voltro dev`
 - [Build & start](/docs/cli/build-and-start) — production paths
 - [Migrate](/docs/cli/migrate) — schema changes end-to-end
+- [Update](/docs/cli/update) — upgrade the framework + run codemods
 - [Inspect & test](/docs/cli/inspect) — debugging + harness
 
 
@@ -1648,3 +1650,60 @@ The manifest is read through a TTL-cached source (~10 seconds): a procedure you
 ## Protocol scope
 
 MCP over JSON-RPC 2.0. `initialize` negotiates the protocol revision (`2025-06-18`, `2025-03-26`, `2024-11-05`) and advertises the `tools`, `resources`, and `prompts` capabilities; methods are `ping`, `tools/list`, `tools/call`, `resources/list`, `resources/read`, `prompts/list`, `prompts/get`. The stdio bin frames this as newline-delimited JSON-RPC; the HTTP bin serves it over Streamable HTTP. Both transports route to the same pure protocol core (`handleMcpRequest`, `callTool`, `listResources`/`readResource`, `listPrompts`/`getPrompt`, `routeHttp`), all exported from `@voltro/mcp`.
+
+
+
+---
+
+<!-- source: en/cli/update.md -->
+## Update
+
+_voltro update — bump the framework to the latest version and run the codemods that adapt your source to any changed APIs._
+
+`voltro update` upgrades an app to the latest framework release. It does three things in order:
+
+1. **Bump** every `@voltro/*` dependency in `package.json` to the target version.
+2. **Install** with your package manager (detected from the lockfile — pnpm / npm / yarn / bun).
+3. **Run the codemods** shipped with the target version — automatic source rewrites for any breaking API change, plus printed manual steps for anything that can't be automated.
+
+```bash
+voltro update                 # bump to the latest published version, install, run codemods
+voltro update --to 0.4.0      # pin an explicit target version
+voltro update --dry-run       # preview the bump + which codemods would run — writes nothing
+voltro update --force         # allow a dirty working tree (not recommended)
+voltro update --exact         # pin exact versions (drop the ^ / ~ range prefix)
+```
+
+## The clean-tree guard
+
+Codemods **rewrite your source**, so you need a clean diff to review afterwards. `voltro update` refuses to run on a dirty git working tree — commit or stash first. Use `--dry-run` to preview without touching anything, or `--force` to override the guard (you accept a mixed diff).
+
+## What gets bumped
+
+Every `@voltro/*` entry in `dependencies` and `devDependencies`, with the range style preserved (`^0.3.0` stays caret, `~0.3.0` stays tilde) unless you pass `--exact`. Non-registry specs (`workspace:*`, `catalog:`, `link:`, …) are left untouched — they're already resolved by your monorepo or catalog.
+
+## Codemods
+
+Each breaking public-API change in a release ships a **codemod**. When you update across that release, `voltro update` applies it:
+
+- A **transform codemod** rewrites your source automatically — renamed imports, moved modules, changed component props, restructured call signatures. The rewrite is scoped to files that actually import the affected symbol.
+- A **manual codemod** prints written steps during the update, only when your app is affected — for changes that can't be mechanically transformed (a behavior change, a descriptor/executor restructure). Where the affected sites can be found but the fix needs your judgment, a codemod inserts `// TODO(voltro-migration): …` markers so you can locate every spot.
+
+Codemods that span multiple versions run in order (e.g. upgrading `0.2.0 → 0.4.0` runs the `0.3.0` and `0.4.0` codemods in sequence). Review the resulting diff before committing.
+
+## The database is separate
+
+`voltro update` does **not** touch your database. Framework-owned `_voltro_*` tables (workflow runs, schedules, …) are reconciled by the declarative differ, not by codemods: when a release changes one of those tables, your next `voltro db apply` (or `voltro dev` boot, which auto-applies) picks up the change. After an update:
+
+```bash
+voltro update
+voltro db apply        # reconcile any changed framework tables — NOT voltro db migrate
+# then run your typecheck to confirm your code compiles against the new API
+```
+
+Use `voltro db apply` (the declarative diff), not `voltro db migrate` (the imperative file-runner) — only the former reconciles framework tables.
+
+## Where to read next
+
+- [Migrate](/docs/cli/migrate) — schema changes end-to-end
+- [Build & start](/docs/cli/build-and-start) — production paths

package/templates/agent-docs/data.md

@@ -389,6 +389,17 @@ The descriptor is the wire contract. The `.mutation.server.ts` file is the serve
 5. Commit the transaction.
 6. Drain the batched change events so matching query subscriptions receive new snapshots or deltas.
 
+## Partial updates: `ctx.store.applyDefined`
+
+A partial-update mutation should set only the fields the caller actually sent — not overwrite an omitted field with `undefined`. Instead of hand-writing `if (input.x !== undefined) patch.x = input.x` per field, use `ctx.store.applyDefined(input, keys)`:
+
+```ts
+const execute = async (input: UpdateNote, ctx: AppContext) =>
+  ctx.store.update('notes', input.id, ctx.store.applyDefined(input, ['title', 'body', 'dueAt']))
+```
+
+It returns a patch containing only the listed keys whose value is not `undefined` (a defined falsy value like `0` / `''` / `false` IS kept). Also importable standalone (`import { applyDefined } from '@voltro/runtime'`) for seeds/tests.
+
 ## Calling From React
 
 ```tsx
@@ -465,6 +476,34 @@ const create = useMutation('app', 'notes.create').withOptimistic((cache, input)
 
 Use `.withoutOptimistic()` for effects that should not preview locally.
 
+### Nested / path-targeted optimistic
+
+By default a `target` patches the **flat top-level row array** a query returns, keyed by `id`. When a query returns a **nested array** — a JSON array column (`snapshot.projects`) or a computed/shaped value — add `path` (and, if the item key isn't `id`, `by`) to patch at **item** granularity, with no hand-written `.withOptimistic` reducer:
+
+```ts
+target: {
+  table: 'projectRoadmaps', op: 'update',
+  path: 'snapshot.projects',                 // dot-path to the nested array in the value
+  identify: (input) => input.projectId,      // which item to patch (default input.id)
+}
+```
+
+- `op: 'insert'` appends (or `order: 'prepend'`) a new item into the nested array — safe even on a computed query (a path insert targets a KNOWN document, not a blind top-level add).
+- `op: 'delete'` filters the item out by its key.
+- `by` overrides the item-key field (default `'id'`).
+
+Add `match` to patch **only** the entries whose current value satisfies a predicate — the guard that stops a patch bleeding across sibling subscriptions sharing a source table:
+
+```ts
+target: {
+  table: 'projectRoadmaps', op: 'update', path: 'snapshot.projects',
+  identify: (i) => i.projectId,
+  match: (value, input) => value.id === input.roadmapId,   // only THIS roadmap's subscription
+}
+```
+
+`path`, `by`, and `match` are browser-safe descriptor data (a dot-path string + a pure predicate) — the same discipline as `identify`/`shape`.
+
 ## Typed Errors
 
 ```ts

package/templates/agent-docs/database/advancedqueries.md

@@ -219,6 +219,33 @@ text().unique()                                 // single-column, on the column
 
 Multi-column uniqueness is declared at the table level with `.unique(name, [cols])` — see [Composite UNIQUE constraints](#composite-unique-constraints) below.
 
+## Unique among ACTIVE rows — `.uniqueActive([...])`
+
+Enforce uniqueness only among the rows that aren't soft-deleted — "one active roadmap per (project, year)", where a soft-deleted roadmap frees the key for a new one:
+
+```ts
+table('project_roadmaps', {
+  id: id(), projectId: text(), year: integer(), deletedAt: timestamp(),
+})
+  .softDelete()
+  .uniqueActive(['projectId', 'year'])            // partial UNIQUE among deletedAt IS NULL
+```
+
+Emits a `CREATE UNIQUE INDEX … WHERE "deletedAt" IS NULL`, so a soft-deleted row leaves the active set and a NEW row with the same key inserts cleanly — no hand-written `generatedAs("CASE WHEN …")` column, and no [resurrection bug](/docs/database/migrations/troubleshooting) where a re-imported soft-deleted key collides. The predicate defaults to the `softDelete()` active set; override it for a custom one:
+
+```ts
+.uniqueActive('byActiveSlug', ['orgId', 'slug'], { where: `"status" = 'open'` })
+```
+
+Cross-dialect:
+
+| Dialect             | Support                                                        |
+|---------------------|----------------------------------------------------------------|
+| postgres / sqlite / mssql | native partial `CREATE UNIQUE INDEX … WHERE`             |
+| mysql / mariadb     | FAILS LOUDLY at migrate — no partial-index support; a full unique index would forbid re-creating a soft-deleted key. Use a generated STORED column + `.unique([...])` there. |
+
+The predicate is emitted verbatim (ANSI double-quoted identifiers, valid on the three supported dialects).
+
 ## When NOT to index
 
 - Tables with <10k rows on a fast disk — the cost of maintaining the index outweighs the seq-scan cost.

package/templates/agent-docs/deployment.md

@@ -411,7 +411,9 @@ voltro build ./apps/api    # produces .framework/dist-api/serveBundle/
 voltro serve ./apps/api    # boots from the bundle automatically
 ```
 
-There is nothing to configure and nothing to opt into: building an API app produces the bundle, and `voltro serve` prefers it whenever it is present. It is fully fallback-safe — a missing, stale, or unreadable bundle silently degrades to the standard boot path, so a bad build can never stop the app from serving. A container image that runs `voltro build` at build time and `voltro serve` at start gets the fast boot for free.
+Building an API app produces the bundle, and `voltro serve` boots from it. In **production** (`NODE_ENV=production`) the bundle is **required** — you run `voltro build` before `voltro serve`, and a bundle-build failure is fatal: production **never transpiles on demand**, so it fails loud rather than silently falling back to the slow tsx path. (`voltro dev` and a non-production local `voltro serve` still fall back to tsx as a convenience.) The generated Dockerfiles already do this: `voltro build` at build time, `voltro serve` at start.
+
+Because production never transpiles, the serve image needs none of the build toolchain. The framework declares `tsx`, `esbuild`, `vite`, and Tailwind as **optional** dependencies of `@voltro/cli`, and the production Dockerfiles isolate the app with `pnpm --prod --no-optional deploy` — which drops that whole tree (and its native binaries) from the image. A serve image ships only what it runs at runtime: your app, the framework, and the one SQL driver you declared.
 
 ## Tiers (Voltro Cloud — coming soon)
 

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

@@ -11,16 +11,16 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/ai": "0.2.2",
-    "@voltro/cli": "0.2.2",
-    "@voltro/database": "0.2.2",
-    "@voltro/env": "0.2.2",
-    "@voltro/protocol": "0.2.2",
-    "@voltro/runtime": "0.2.2",
+    "@voltro/ai": "0.3.0",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.2",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -12,17 +12,17 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.2.2",
-    "@voltro/database": "0.2.2",
-    "@voltro/env": "0.2.2",
-    "@voltro/plugin-auth": "0.2.2",
-    "@voltro/protocol": "0.2.2",
-    "@voltro/runtime": "0.2.2",
-    "@voltro/sql-postgres": "0.2.2",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-auth": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
+    "@voltro/sql-postgres": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.2",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -12,16 +12,16 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.2.2",
-    "@voltro/database": "0.2.2",
-    "@voltro/env": "0.2.2",
-    "@voltro/plugin-multitenancy": "0.2.2",
-    "@voltro/protocol": "0.2.2",
-    "@voltro/runtime": "0.2.2",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-multitenancy": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.2",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -12,16 +12,16 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.2.2",
-    "@voltro/database": "0.2.2",
-    "@voltro/env": "0.2.2",
-    "@voltro/plugin-deactivation": "0.2.2",
-    "@voltro/protocol": "0.2.2",
-    "@voltro/runtime": "0.2.2",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-deactivation": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.2",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -12,18 +12,18 @@
   "dependencies": {
     "@react-email/components": "^1.0.12",
     "@react-email/render": "^1.4.0",
-    "@voltro/cli": "0.2.2",
-    "@voltro/database": "0.2.2",
-    "@voltro/env": "0.2.2",
-    "@voltro/plugin-mail": "0.2.2",
-    "@voltro/plugin-multitenancy": "0.2.2",
-    "@voltro/protocol": "0.2.2",
-    "@voltro/runtime": "0.2.2",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-mail": "0.3.0",
+    "@voltro/plugin-multitenancy": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
     "effect": "^3.21.2",
     "react": "^19.0.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.2",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -12,18 +12,18 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.2.2",
-    "@voltro/database": "0.2.2",
-    "@voltro/env": "0.2.2",
-    "@voltro/plugin-multitenancy": "0.2.2",
-    "@voltro/plugin-storage": "0.2.2",
-    "@voltro/protocol": "0.2.2",
-    "@voltro/runtime": "0.2.2",
-    "@voltro/sql-mysql": "0.2.2",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-multitenancy": "0.3.0",
+    "@voltro/plugin-storage": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
+    "@voltro/sql-mysql": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.2",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -10,17 +10,17 @@
     "test": "voltro test"
   },
   "dependencies": {
-    "@voltro/cli": "0.2.2",
-    "@voltro/database": "0.2.2",
-    "@voltro/env": "0.2.2",
-    "@voltro/plugin-multitenancy": "0.2.2",
-    "@voltro/plugin-storage": "0.2.2",
-    "@voltro/protocol": "0.2.2",
-    "@voltro/runtime": "0.2.2",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-multitenancy": "0.3.0",
+    "@voltro/plugin-storage": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.2",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -11,17 +11,17 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.2.2",
-    "@voltro/database": "0.2.2",
-    "@voltro/env": "0.2.2",
-    "@voltro/plugin-governance": "0.2.2",
-    "@voltro/plugin-multitenancy": "0.2.2",
-    "@voltro/protocol": "0.2.2",
-    "@voltro/runtime": "0.2.2",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-governance": "0.3.0",
+    "@voltro/plugin-multitenancy": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.2",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -11,17 +11,17 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.2.2",
-    "@voltro/database": "0.2.2",
-    "@voltro/env": "0.2.2",
-    "@voltro/plugin-multitenancy": "0.2.2",
-    "@voltro/protocol": "0.2.2",
-    "@voltro/runtime": "0.2.2",
-    "@voltro/workflow": "0.2.2",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-multitenancy": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
+    "@voltro/workflow": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.2",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -12,18 +12,18 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.2.2",
-    "@voltro/database": "0.2.2",
-    "@voltro/env": "0.2.2",
-    "@voltro/plugin-flags": "0.2.2",
-    "@voltro/plugin-multitenancy": "0.2.2",
-    "@voltro/protocol": "0.2.2",
-    "@voltro/runtime": "0.2.2",
-    "@voltro/sql-postgres": "0.2.2",
+    "@voltro/cli": "0.3.0",
+    "@voltro/database": "0.3.0",
+    "@voltro/env": "0.3.0",
+    "@voltro/plugin-flags": "0.3.0",
+    "@voltro/plugin-multitenancy": "0.3.0",
+    "@voltro/protocol": "0.3.0",
+    "@voltro/runtime": "0.3.0",
+    "@voltro/sql-postgres": "0.3.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.2.2",
+    "@voltro/testing": "0.3.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }