@voltro/cli 0.1.5 → 0.2.0

package/dist/dev-DFhyP4GC.js

@@ -0,0 +1,2 @@
+import { o as e } from "./dev-CZ2WE3zn.js";
+export { e as loadApiConfig };

package/dist/index.js

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/cli",
-  "version": "0.1.5",
+  "version": "0.2.0",
   "description": "The `voltro` CLI — dev server, codegen, migrations, project scaffolding, agent-docs seeding, and production serve.",
   "keywords": [
     "voltro",
@@ -49,31 +49,25 @@
     "@effect/workflow": "^0.18.2",
     "@tailwindcss/vite": "^4.3.2",
     "@vitejs/plugin-react": "^6.0.3",
-    "@voltro/ai": "0.1.5",
-    "@voltro/cache": "0.1.5",
-    "@voltro/data-transfer": "0.1.5",
-    "@voltro/database": "0.1.5",
-    "@voltro/env": "0.1.5",
-    "@voltro/kv": "0.1.5",
-    "@voltro/logger": "0.1.5",
-    "@voltro/plugin-auth": "0.1.5",
-    "@voltro/plugin-broadcast": "0.1.5",
-    "@voltro/plugin-mail": "0.1.5",
-    "@voltro/plugin-storage": "0.1.5",
-    "@voltro/plugin-webhooks": "0.1.5",
-    "@voltro/protocol": "0.1.5",
-    "@voltro/runtime": "0.1.5",
-    "@voltro/serverless": "0.1.5",
-    "@voltro/sql-mssql": "0.1.5",
-    "@voltro/sql-mysql": "0.1.5",
-    "@voltro/sql-postgres": "0.1.5",
-    "@voltro/sql-sqlite": "0.1.5",
-    "@voltro/sql-turso": "0.1.5",
-    "@voltro/workflow": "0.1.5",
+    "@voltro/ai": "0.2.0",
+    "@voltro/cache": "0.2.0",
+    "@voltro/data-transfer": "0.2.0",
+    "@voltro/database": "0.2.0",
+    "@voltro/env": "0.2.0",
+    "@voltro/kv": "0.2.0",
+    "@voltro/logger": "0.2.0",
+    "@voltro/plugin-auth": "0.2.0",
+    "@voltro/plugin-broadcast": "0.2.0",
+    "@voltro/plugin-mail": "0.2.0",
+    "@voltro/plugin-storage": "0.2.0",
+    "@voltro/plugin-webhooks": "0.2.0",
+    "@voltro/protocol": "0.2.0",
+    "@voltro/runtime": "0.2.0",
+    "@voltro/serverless": "0.2.0",
+    "@voltro/workflow": "0.2.0",
     "chokidar": "^5.0.0",
     "esbuild": "^0.28.0",
     "ioredis": "^5.11.1",
-    "pg": "^8.22.0",
     "tsx": "^4.23.0",
     "vite": "^8.1.4"
   },

package/templates/agent-docs/ai.md

@@ -18,27 +18,27 @@ The implementation is the [Vercel AI SDK](https://sdk.vercel.ai) wrapped behind
 ## The model
 
 ```text
-                 ┌─────────────────────────────────────────┐
-                 │  Vercel AI SDK                          │
-                 │   anthropic / openai / gateway / mock    │
-                 └────────────────┬────────────────────────┘
-                                  │
-                                  ▼
-┌─────────────────────────────────────────────────────────────────┐
-│  @voltro/ai                                                      │
-│    generateText(...) / generateObject(...)                       │
-│    streamText(...)                                                │
-│    embed(...) / embedMany(...)                                    │
-└────┬─────────────────────────┬──────────────────────────────────┘
-     │                         │
-     ▼                         ▼
-┌──────────────────────────────┐   ┌──────────────────────────────────┐
-│  *.agent.tsx (descriptor)    │   │  *.tool.tsx                      │
-│   defineAgent({ name, input })│   │   defineTool({ name, input,      │
-│  *.agent.server.tsx (executor)│   │     output })                    │
-│   defineAgentExecutor(desc, { │   │   typed + wired on the executor  │
-│     system, tools, model })   │   │                                  │
-└──────────────────────────────┘   └──────────────────────────────────┘
+               ┌───────────────────────────────────────┐
+               │  Vercel AI SDK                        │
+               │   anthropic / openai / gateway / mock │
+               └───────────────────┬───────────────────┘
+                                   │
+                                   ▼
+┌──────────────────────────────────────────────────────────────────────┐
+│  @voltro/ai                                                          │
+│    generateText(...) / generateObject(...)                           │
+│    streamText(...)                                                   │
+│    embed(...) / embedMany(...)                                       │
+└────────────────┬────────────────────────────────────┬────────────────┘
+                 │                                    │
+                 ▼                                    ▼
+┌────────────────────────────────┐   ┌─────────────────────────────────┐
+│  *.agent.tsx (descriptor)      │   │  *.tool.tsx                     │
+│   defineAgent({ name, input }) │   │   defineTool({ name, input,     │
+│  *.agent.server.tsx (executor) │   │     output })                   │
+│   defineAgentExecutor(desc, {  │   │   typed + wired on the executor │
+│     system, tools, model })    │   │                                 │
+└────────────────────────────────┘   └─────────────────────────────────┘
 ```
 
 ## What's in this section

package/templates/agent-docs/authentication.md

@@ -20,18 +20,18 @@ Voltro's auth story ships as a plugin: `@voltro/plugin-auth`. It's server-side p
 ## The pieces
 
 ```text
-┌───────────────────────────────────────────────────────────────┐
-│  Browser                                                      │
-│    POST /auth/signin   ────────┐                              │
-│    Cookie: voltro:session=...  │                              │
+┌────────────────────────────────────────────────────────────────┐
+│  Browser                                                       │
+│    POST /auth/signin   ────────┐                               │
+│    Cookie: voltro:session=...  │                               │
 └───────────────────────────────┬─┘                              │
-                                │  Set-Cookie (HttpOnly, Secure)│
+                                │  Set-Cookie (HttpOnly, Secure) │
                                 ▼                                │
-┌───────────────────────────────────────────────────────────────┐
-│  api app                                                      │
+┌────────────────────────────────────────────────────────────────┐
+│  api app                                                       │
 │    handleSignIn → verifyPassword → issueSession                │
-│    readSession  → HMAC verify    → Subject                    │
-└───────────────────────────────────────────────────────────────┘
+│    readSession  → HMAC verify    → Subject                     │
+└────────────────────────────────────────────────────────────────┘
                                 ▲
                                 │  ctx.subject (typed)
                                 │

package/templates/agent-docs/cli.md

@@ -610,7 +610,7 @@ What it does for a web app:
 3. **Pre-builds the SSR bundle** — every page module compiled to `dist/server/ssrEntry.js` so `voltro start` doesn't need a Vite middleware loader at runtime.
 4. **Copies `public/`** into `dist/`.
 
-For api apps, `voltro build` bundles the discovery-walked sources + dependencies into a single Node ESM entry at `dist/api.js`. Production servers run it via `node dist/api.js`.
+For api apps, `voltro build` precompiles the whole handler closure — every procedure, workflow, subscriber, reaction, aggregate, agent, webhook, cron, startup, `app.config`, and their shared `database`/`lib` deps — into a single esbuild bundle at `.framework/dist-api/apiEntry.js` (the framework + npm deps stay external). `voltro serve` loads that bundle automatically at boot and resolves every handler from it, so production never transpiles TypeScript at runtime. Without a build, `voltro serve` still loads each source module on demand (via the `tsx` loader) exactly as `voltro dev` does — the build is an optimisation, not a requirement.
 
 `voltro build` takes a single optional app directory and parses no flags — the SSR bundle is always attempted, and the SSG pre-render always runs for `static`-mode pages.
 

package/templates/agent-docs/data.md

@@ -36,16 +36,16 @@ sandbox; it resets on refresh):
 └──────────────────────────┬───────────────────────────────────────┘
                            │  @effect/rpc over WebSocket
                            ▼
-┌──────────────────────────────────────────────────────────────────┐
-│  api app                                                         │
-│    *.query.ts    + *.query.server.ts     — reactive reads         │
-│    *.mutation.ts + *.mutation.server.ts  — transactional writes   │
-│    *.action.ts   + *.action.server.ts    — external I/O / unary   │
-│    *.stream.ts   + *.stream.server.ts    — one-shot element push  │
+┌────────────────────────────────────────────────────────────────────┐
+│  api app                                                           │
+│    *.query.ts    + *.query.server.ts     — reactive reads          │
+│    *.mutation.ts + *.mutation.server.ts  — transactional writes    │
+│    *.action.ts   + *.action.server.ts    — external I/O / unary    │
+│    *.stream.ts   + *.stream.server.ts    — one-shot element push   │
 │    *.route.tsx                            — public raw-HTTP route  │
 │    *.workflow.tsx  + *.trigger.tsx        — durable work + events  │
 │    *.agent.tsx                            — persisted AI chat      │
-└──────────────────────────────────────────────────────────────────┘
+└────────────────────────────────────────────────────────────────────┘
 ```
 
 Most of it goes through one WebSocket (REST routes are the public raw-HTTP exception). Queries and streams are both streaming RPCs, but they mean different things: a query emits reactive snapshot/delta envelopes; a stream emits plain elements and then finishes.

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

@@ -24,6 +24,24 @@ DB_URL=postgresql://user:pass@host:5432/db?sslmode=require
 
 `DB_DIALECT` picks the driver; `DB_URL` is the connection string for the provider. When a single URL doesn't fit, the discrete `DB_HOST` / `DB_PORT` / `DB_USER` / `DB_PASSWORD` / `DB_DATABASE` fields are the dialect-agnostic alternative (and `PG_HOST` / `PG_PORT` / `PG_USER` / `PG_PASSWORD` / `PG_DATABASE` are accepted as a fallback). Env always wins over `app.config.ts`'s `store:` field.
 
+## Declare your dialect's driver
+
+Each app declares the driver package for its DB dialect as a dependency — the CLI does not bundle every driver, so a production image only ships the one your app actually uses (a memory-store app ships none, and never pulls e.g. turso's ~90 MB native binary):
+
+| Dialect | Driver package |
+| --- | --- |
+| `postgres` | `@voltro/sql-postgres` |
+| `mysql` / `mariadb` | `@voltro/sql-mysql` |
+| `mssql` | `@voltro/sql-mssql` |
+| `sqlite` | `@voltro/sql-sqlite` |
+| `turso` | `@voltro/sql-turso` |
+
+```sh
+pnpm add @voltro/sql-postgres      # in the app that uses store: 'postgres'
+```
+
+Scaffolded projects already declare the right driver, and `voltro add mssql` adds `@voltro/sql-mssql` for you. If a driver is missing at boot, `voltro serve` fails with a message naming the exact package to install — it never silently falls back. A `store: 'memory'` app needs no driver.
+
 ## Providers at a glance
 
 | Provider | Voltro dialect | Pooling | Notes |

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

@@ -1175,38 +1175,38 @@ What prod boot DOES is compare the declared-schema fingerprint against the lates
 └────────────────┬────────────────┘
                  │
                  ▼
-┌─────────────────────────────────┐
-│ 2. CI runs `voltro db plan`     │
+┌──────────────────────────────────┐
+│ 2. CI runs `voltro db plan`      │
 │    against a staging-style       │
 │    snapshot. The printed plan    │
 │    (classes + fingerprints) goes │
 │    into the PR for review        │
-└────────────────┬────────────────┘
+└────────────────┬─────────────────┘
                  │
                  ▼
-┌─────────────────────────────────┐
-│ 3. Reviewer reads the plan      │
+┌──────────────────────────────────┐
+│ 3. Reviewer reads the plan       │
 │    classification, fingerprints  │
 │    + DSL annotations             │
 │    Approves PR                   │
-└────────────────┬────────────────┘
+└────────────────┬─────────────────┘
                  │
                  ▼
-┌─────────────────────────────────┐
-│ 4. Merge to main                │
+┌──────────────────────────────────┐
+│ 4. Merge to main                 │
 │    CI/CD deploys new image       │
 │    BEFORE traffic switch a       │
 │    one-shot job runs             │
 │    `voltro db apply` against     │
 │    the prod DB (re-diffs live)   │
-└────────────────┬────────────────┘
+└────────────────┬─────────────────┘
                  │
                  ▼
-┌─────────────────────────────────┐
-│ 5. Traffic switches             │
-│    Prod boot: fingerprint match  │
+┌───────────────────────────────────┐
+│ 5. Traffic switches               │
+│    Prod boot: fingerprint match   │
 │    → serves                       │
-└─────────────────────────────────┘
+└───────────────────────────────────┘
 ```
 
 There's a slot for the apply step in every common deploy tool (k8s init container, ECS task pre-deploy hook, Heroku release phase, Cloud Run job-on-deploy, Fly.io `release_command`). The shape is identical: run a one-shot container/process that holds the migration credentials + executes `voltro db apply`. It re-diffs the live DB against the deployed code's declared schema and applies the resulting plan — there is no pre-serialised plan file to pass; the apply re-computes the diff at run time. The serving process never gets the migration-grade credentials.

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

@@ -1499,14 +1499,14 @@ At runtime, every `ChangeEvent` consults this map BEFORE triggering a re-query.
 Stage 1 — the dependency graph tracks per-table dependency. When `posts` changes, the dispatcher finds every subscription whose dependent-table set includes `posts` and triggers a re-query. After the re-query, a shallow row-set compare (JSON.stringify per row) suppresses the delta if the result is shape-identical to the last delivered snapshot.
 
 ```text
-┌──────────────────────────────────────────────────────────────────┐
-│ Subscription: users.with({ posts: { with: { author: true } } })  │
-│                                                                   │
+┌───────────────────────────────────────────────────────────────────────┐
+│ Subscription: users.with({ posts: { with: { author: true } } })       │
+│                                                                       │
 │   change(users)     → re-query  → diff vs lastDelivered → maybe delta │
 │   change(posts)     → re-query  → diff vs lastDelivered → maybe delta │
-│                                                                   │
-│   change(orgs)      → no-op (not in dependency graph)             │
-└──────────────────────────────────────────────────────────────────┘
+│                                                                       │
+│   change(orgs)      → no-op (not in dependency graph)                 │
+└───────────────────────────────────────────────────────────────────────┘
 ```
 
 This is CORRECT but expensive: every write to a dependent table costs a SQL round-trip, even when the write touched a column the subscription doesn't care about.

package/templates/agent-docs/deployment.md

@@ -374,6 +374,34 @@ The app is only stopped when, continuously for the grace window:
 
 A long-sleeping workflow (`sleep('3 days')`) is exactly the case dormancy is built for: the app stops, and the orchestrator brings a fresh process up when the sleep is due — the workflow resumes from its journal.
 
+## Diagnosing cold-start latency
+
+The flip side of scale-to-zero is a cold start on the first hit after an idle period. Every `voltro serve` boot logs how long it took to become ready:
+
+```text
+serve: ready in 1910ms
+```
+
+To see WHERE those milliseconds go, set `VOLTRO_BOOT_TIMING=1` — the same line gains a per-phase breakdown:
+
+```text
+serve: ready in 1910ms  { bootMs: 1910, phases: { modules: 1872, config: 0, discover: 18, store: 9, plugins: 1, workflow: 1, ready: 9 } }
+```
+
+The phases, in boot order:
+
+| Phase | What it covers |
+| --- | --- |
+| `modules` | node init + loading and compiling the JS module graph (the framework + your app). On a scale-to-zero container this is almost always the dominant phase — it is the cost of evaluating the dependency graph on a cold process, and it scales inversely with your CPU allotment. No app-level change shrinks it — **precompiling the app (`voltro build`) removes only the transpile of your own source files, not the framework graph load.** |
+| `config` | loading `app.config.ts` + the typed-env gate |
+| `discover` | walking the app + loading discovered primitives (plus the precompiled bundle, when `voltro build` produced one) |
+| `store` | opening the data store + cache/kv facades — a real SQL dialect includes the connection handshake here |
+| `plugins` | plugin bind + lifecycle activation |
+| `workflow` | the durable-workflow engine |
+| `ready` | serveApi's own setup — handler layers, subscribers, reactions, aggregates, the HTTP listener |
+
+Read this from the container's own logs at its real CPU allotment, not a beefy dev machine: a `modules` phase that dwarfs everything else means the cold start is dominated by evaluating the dependency graph (raise the container's CPU, or keep one instance warm); a fat `store` phase points at the database connection instead. `VOLTRO_BOOT_TIMING` adds a handful of `performance.now()` calls and one log line — it is safe to leave on in production.
+
 ## Tiers (Voltro Cloud — coming soon)
 
 Managed cloud hosting is not yet available; the Pro / Enterprise rows below are the planned managed tiers. Today you self-host and run `voltro dormancy` yourself.

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.1.5",
-    "@voltro/cli": "0.1.5",
-    "@voltro/database": "0.1.5",
-    "@voltro/env": "0.1.5",
-    "@voltro/protocol": "0.1.5",
-    "@voltro/runtime": "0.1.5",
+    "@voltro/ai": "0.2.0",
+    "@voltro/cli": "0.2.0",
+    "@voltro/database": "0.2.0",
+    "@voltro/env": "0.2.0",
+    "@voltro/protocol": "0.2.0",
+    "@voltro/runtime": "0.2.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.1.5",
+    "@voltro/testing": "0.2.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -12,16 +12,17 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@voltro/cli": "0.1.5",
-    "@voltro/database": "0.1.5",
-    "@voltro/env": "0.1.5",
-    "@voltro/plugin-auth": "0.1.5",
-    "@voltro/protocol": "0.1.5",
-    "@voltro/runtime": "0.1.5",
+    "@voltro/cli": "0.2.0",
+    "@voltro/database": "0.2.0",
+    "@voltro/env": "0.2.0",
+    "@voltro/plugin-auth": "0.2.0",
+    "@voltro/protocol": "0.2.0",
+    "@voltro/runtime": "0.2.0",
+    "@voltro/sql-postgres": "0.2.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.1.5",
+    "@voltro/testing": "0.2.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.1.5",
-    "@voltro/database": "0.1.5",
-    "@voltro/env": "0.1.5",
-    "@voltro/plugin-multitenancy": "0.1.5",
-    "@voltro/protocol": "0.1.5",
-    "@voltro/runtime": "0.1.5",
+    "@voltro/cli": "0.2.0",
+    "@voltro/database": "0.2.0",
+    "@voltro/env": "0.2.0",
+    "@voltro/plugin-multitenancy": "0.2.0",
+    "@voltro/protocol": "0.2.0",
+    "@voltro/runtime": "0.2.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.1.5",
+    "@voltro/testing": "0.2.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.1.5",
-    "@voltro/database": "0.1.5",
-    "@voltro/env": "0.1.5",
-    "@voltro/plugin-deactivation": "0.1.5",
-    "@voltro/protocol": "0.1.5",
-    "@voltro/runtime": "0.1.5",
+    "@voltro/cli": "0.2.0",
+    "@voltro/database": "0.2.0",
+    "@voltro/env": "0.2.0",
+    "@voltro/plugin-deactivation": "0.2.0",
+    "@voltro/protocol": "0.2.0",
+    "@voltro/runtime": "0.2.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.1.5",
+    "@voltro/testing": "0.2.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.1.5",
-    "@voltro/database": "0.1.5",
-    "@voltro/env": "0.1.5",
-    "@voltro/plugin-mail": "0.1.5",
-    "@voltro/plugin-multitenancy": "0.1.5",
-    "@voltro/protocol": "0.1.5",
-    "@voltro/runtime": "0.1.5",
+    "@voltro/cli": "0.2.0",
+    "@voltro/database": "0.2.0",
+    "@voltro/env": "0.2.0",
+    "@voltro/plugin-mail": "0.2.0",
+    "@voltro/plugin-multitenancy": "0.2.0",
+    "@voltro/protocol": "0.2.0",
+    "@voltro/runtime": "0.2.0",
     "effect": "^3.21.2",
     "react": "^19.0.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.1.5",
+    "@voltro/testing": "0.2.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.1.5",
-    "@voltro/database": "0.1.5",
-    "@voltro/env": "0.1.5",
-    "@voltro/plugin-multitenancy": "0.1.5",
-    "@voltro/plugin-storage": "0.1.5",
-    "@voltro/protocol": "0.1.5",
-    "@voltro/runtime": "0.1.5",
-    "@voltro/sql-mysql": "0.1.5",
+    "@voltro/cli": "0.2.0",
+    "@voltro/database": "0.2.0",
+    "@voltro/env": "0.2.0",
+    "@voltro/plugin-multitenancy": "0.2.0",
+    "@voltro/plugin-storage": "0.2.0",
+    "@voltro/protocol": "0.2.0",
+    "@voltro/runtime": "0.2.0",
+    "@voltro/sql-mysql": "0.2.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.1.5",
+    "@voltro/testing": "0.2.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.1.5",
-    "@voltro/database": "0.1.5",
-    "@voltro/env": "0.1.5",
-    "@voltro/plugin-multitenancy": "0.1.5",
-    "@voltro/plugin-storage": "0.1.5",
-    "@voltro/protocol": "0.1.5",
-    "@voltro/runtime": "0.1.5",
+    "@voltro/cli": "0.2.0",
+    "@voltro/database": "0.2.0",
+    "@voltro/env": "0.2.0",
+    "@voltro/plugin-multitenancy": "0.2.0",
+    "@voltro/plugin-storage": "0.2.0",
+    "@voltro/protocol": "0.2.0",
+    "@voltro/runtime": "0.2.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.1.5",
+    "@voltro/testing": "0.2.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.1.5",
-    "@voltro/database": "0.1.5",
-    "@voltro/env": "0.1.5",
-    "@voltro/plugin-governance": "0.1.5",
-    "@voltro/plugin-multitenancy": "0.1.5",
-    "@voltro/protocol": "0.1.5",
-    "@voltro/runtime": "0.1.5",
+    "@voltro/cli": "0.2.0",
+    "@voltro/database": "0.2.0",
+    "@voltro/env": "0.2.0",
+    "@voltro/plugin-governance": "0.2.0",
+    "@voltro/plugin-multitenancy": "0.2.0",
+    "@voltro/protocol": "0.2.0",
+    "@voltro/runtime": "0.2.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.1.5",
+    "@voltro/testing": "0.2.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.1.5",
-    "@voltro/database": "0.1.5",
-    "@voltro/env": "0.1.5",
-    "@voltro/plugin-multitenancy": "0.1.5",
-    "@voltro/protocol": "0.1.5",
-    "@voltro/runtime": "0.1.5",
-    "@voltro/workflow": "0.1.5",
+    "@voltro/cli": "0.2.0",
+    "@voltro/database": "0.2.0",
+    "@voltro/env": "0.2.0",
+    "@voltro/plugin-multitenancy": "0.2.0",
+    "@voltro/protocol": "0.2.0",
+    "@voltro/runtime": "0.2.0",
+    "@voltro/workflow": "0.2.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.1.5",
+    "@voltro/testing": "0.2.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

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