@voltro/cli 0.25.0 → 0.27.0

package/templates/agent-docs/workflows.md

@@ -525,34 +525,55 @@ Workflow durability and retry are related, but not identical. The engine checkpo
 
 ## Per-step retries
 
-Use `stepModule.retry(...)` when you want retry attempts to appear as separate step attempts in the dashboard:
+Declare a `retry:` policy on `step({...})` and the framework **enforces** it — it compiles the policy to an Effect `Schedule` and retries `execute` for you. No hand-written retry needed:
 
 ```tsx
-import { workflow, step, stepModule } from '@voltro/workflow'
-import { Effect, Schedule, Schema } from 'effect'
+import { workflow, step } from '@voltro/workflow'
+import { Schema } from 'effect'
 
 class ProviderDown extends Schema.TaggedError<ProviderDown>()('ProviderDown', {
   message: Schema.String,
 }) {}
 
-const summary = yield* stepModule.retry(
-  step({
-    name: 'summarise-with-llm',
-    input: { noteId },
-    success: Schema.String,
-    error: ProviderDown,
-    retry: {
-      strategy: 'exponential',
-      maxAttempts: 5,
-      baseDelay: '500 millis',
-    },
-    execute: callLlm(note.body),
-  }),
-  Schedule.exponential('500 millis').pipe(Schedule.recurs(4)),
-)
+const summary = yield* step({
+  name: 'summarise-with-llm',
+  input: { noteId },
+  success: Schema.String,
+  error: ProviderDown,
+  retry: {
+    maxAttempts: 5,
+    strategy: 'exponential',
+    baseDelay: '500 millis',
+  },
+  execute: callLlm(note.body),
+})
 ```
 
-The `retry` field on `step({...})` is metadata for inspection. The actual retry behaviour comes from `stepModule.retry(...)`, `Effect.retry(...)`, or another Effect retry combinator.
+Retries run inside the one step and are transparent to the durable engine — completed steps still checkpoint; the step's final outcome is recorded. `retry: { maxAttempts: 5 }` is already a good policy (exponential backoff, jittered).
+
+### The conditions you actually want
+
+The useful retry question is rarely "how many times" — it's *which* failures, for *how long*, and *how spread out*. The policy covers all of it:
+
+```tsx
+retry: {
+  maxAttempts: 5,                          // total attempts including the first (default 3)
+  strategy: 'exponential',                 // 'exponential' | 'fixed' | 'linear'
+  baseDelay: '500 millis',
+  maxDelay: '30 seconds',                  // ceiling so exponential growth can't run away
+  factor: 2,                               // exponential growth factor
+  jitter: true,                            // full jitter (default true) — anti-thundering-herd
+  maxElapsed: '5 minutes',                 // a total time BUDGET — stop retrying after this
+  retryableErrors: ['ProviderDown'],       // retry ONLY these typed errors; others fail fast
+  respectRetryAfter: true,                 // honor a 429: retryAfter REPLACES this attempt's backoff
+}
+```
+
+- **`retryableErrors`** (or a `retryable: (error) => boolean` predicate) is the important one: retry the *transient* failures, fail *fast* on the permanent ones. A `ValidationError` should never be retried; a `ProviderDown` should.
+- **`maxElapsed`** is a deadline across all attempts, not another count — the right bound when "keep trying for up to 5 minutes" matters more than "try 8 times".
+- **`respectRetryAfter`** uses exactly the delay a provider asked for (a `retryAfterMillis` number, or `retryAfter` in seconds, on the thrown error) as the next delay, replacing the computed backoff for that attempt; falls back to backoff when there is no hint.
+
+Retries here run *inside* the one step attempt, so the step is recorded as a SINGLE row in `_voltro_workflow_run_steps` with its final outcome — the individual in-step retries are not separate rows. `respectRetryAfter` uses the provider's delay AS the next delay (replacing the computed backoff for that attempt), falling back to backoff when the error carries no hint. For per-attempt rows in the dashboard, or a bespoke `Schedule`, use `stepModule.retry(step({...}), schedule)` instead. Do NOT set `retry:` on a step you ALSO wrap in `stepModule.retry` / `Effect.retry`: it would retry twice.
 
 ## What to retry
 
@@ -604,6 +625,64 @@ For ad-hoc ops, the same operation is available manually — the CLI (`voltro wo
 voltro workflows retry wfrun_01H...
 ```
 
+`retry` starts a **fresh execution** — a new execution id, an empty journal, every step runs again. That is the right tool for a short, idempotent job, or when the input itself was wrong (`payloadOverride`). For a long multi-step pipeline where re-doing steps 1…N‑1 is expensive or unsafe, you want the opposite: resume from where it failed.
+
+## Resume from where it failed — `suspendOnFailure`
+
+Declare `suspendOnFailure: true` on a workflow and a failure no longer becomes a terminal `failed` run — it **suspends** with the durable journal intact:
+
+```ts
+export default workflow({
+  name: 'billing.close-month',
+  payload: { orgId: Schema.String },
+  success: Schema.Void,
+  error: Schema.Unknown,
+  idempotencyKey: ({ orgId }) => `billing.close-month:${orgId}`,
+  suspendOnFailure: true,          // a failure suspends (recoverable), not fails (terminal)
+  execute: ({ orgId }) => Effect.gen(function* () {
+    yield* step('snapshot-ledger', /* … */)   // completed steps are journaled
+    yield* step('call-tax-provider', /* … */)  // ← a transient 503 here …
+    yield* step('finalise-invoices', /* … */)
+  }),
+})
+```
+
+When `call-tax-provider` fails, the run goes to `suspended` (not `failed`), carrying the failure reason. Fix the cause, then **resume** — the engine replays `snapshot-ledger` from the journal (it does **not** re-run) and continues from the failed step:
+
+```sh
+voltro workflows resume wfrun_01H...      # re-drives from the failure point
+```
+
+```ts
+await ctx.workflows.resume(run.id)         // the same, from a handler
+```
+
+Because a suspended-on-failure run is **recoverable, not dead**, it shows up under `--status suspended`, NOT in the [dead-letter view](/docs/workflows/debugging) (`voltro workflows list --dead-letter`, which is failed-and-unhandled). Choose per workflow: `suspendOnFailure: true` for a long pipeline where prior work must not be redone; the default (`retry` from scratch) for short idempotent jobs.
+
+## Re-drive a failed run — `redrive`
+
+`suspendOnFailure` is a decision you make **before** the run. What if a run already **failed** — it's sitting in the dead-letter view — and you still want to continue it from where it died, not re-run it from scratch? That is `redrive`:
+
+```sh
+voltro workflows redrive wf_01H...   # re-drive a FAILED run from the step it died on
+```
+
+```ts
+await ctx.workflows.redrive(run.id)  // the same, from a handler; addressed by run id
+```
+
+`redrive` re-drives the run from its durable journal: every **completed** step replays from the journal (it does **not** re-run), and only the **failed** step(s) re-execute. It is the after-the-fact counterpart to `suspendOnFailure` + `resume` — same "continue from the failure point" outcome, but for a run that already went terminal without being marked suspend-on-failure. Fix the downstream cause first, then redrive.
+
+The three recovery tools, and when each applies:
+
+| Tool | Use when | Journal |
+|---|---|---|
+| `retry` | The input was wrong, or the job is short + idempotent | Fresh execution, empty journal — every step runs again |
+| `resume` | The run is `suspended` (you set `suspendOnFailure: true`, or it awaits a signal) | Continues from the failure/suspend point — completed steps replay |
+| `redrive` | The run is `failed` (dead-letter) and re-running earlier steps is expensive/unsafe | Continues from the failure point — completed steps replay, failed steps re-run |
+
+`redrive` refuses a run that isn't a not-yet-discarded failure (use `resume` for a suspended run, `retry` for a fresh execution), and it needs a durable journal — on the memory store there is nothing to re-drive, so it declines cleanly (`redriven: false` with a reason) rather than pretending. It works under `voltro serve` as well as `voltro dev`, because dead-letter recovery happens in production. A re-drive records a `run-redriven` event on the run's timeline.
+
 ## Compensation
 
 For saga-style workflows, model compensation explicitly with `Effect.catchAll` around the step that can fail after an earlier side effect:
@@ -664,7 +743,7 @@ The dashboard and `voltro workflows show <runId>` read these same tables through
 
 - **Catching errors and returning success.** Operators lose the failed run.
 - **Retrying non-idempotent side effects.** Double charges and duplicate emails are workflow bugs, not retry bugs.
-- **Putting retry metadata on a step without `Effect.retry` or `stepModule.retry`.** Metadata only explains intent; it does not execute a policy.
+- **Declaring `retry:` on a step you ALSO wrap in `Effect.retry` / `stepModule.retry`.** `retry:` is enforced now — the step would retry twice. Keep one.
 - **Expecting a DLQ table.** The current triage surface is failed runs plus retry controls.
 
 
@@ -1181,12 +1260,22 @@ Voltro records workflow runs, step attempts, and lifecycle events into framework
 | `_voltro_workflow_start_contexts` | One row per started execution id: starter subject, trace id, source, parent execution id, parent-close policy, and creation time. Used for cross-runner context handoff. |
 | `_voltro_workflow_runs` | One row per run: `id`, `tag`, `executionId`, `status`, `payload`, `workflowVersion`, `workflowPatches`, `output`, error fields, subject, start source, timing, trace id, parent execution id, parent-close policy. |
 | `_voltro_workflow_run_steps` | One row per step attempt: step name, attempt number, recorded input, retry metadata, output or error, duration. |
-| `_voltro_workflow_run_events` | Lifecycle events: `run-started`, `run-succeeded`, `run-failed`, `run-suspended`, `run-resumed`, `run-cancelled`, `timer-set`, `timer-fired`, `signal-awaited`, `signal-sent`, `signal-received`, `update-requested`, `update-received`, `update-completed`, `update-failed`. |
+| `_voltro_workflow_run_events` | Lifecycle events: `run-started`, `run-succeeded`, `run-failed`, `run-suspended`, `run-resumed`, `run-redriven`, `run-cancelled`, `timer-set`, `timer-fired`, `signal-awaited`, `signal-sent`, `signal-received`, `update-requested`, `update-received`, `update-completed`, `update-failed`. |
 | `_voltro_workflow_events` | Domain events emitted through `ctx.events.publish(...)`: event id, name, payload, source, subject, trace id, occurred time. |
 | `_voltro_workflow_event_deliveries` | One row per workflow trigger delivery: event id, trigger id, workflow name, execution id, idempotency key, status, error. |
 
 Run status is `running`, `succeeded`, `failed`, `cancelled`, or `suspended`.
 
+## Dead-letter: triaging failed runs
+
+The framework does not retry a workflow on its own (see [Retries](/docs/workflows/retries) — you compose retries inside `execute:` with `Effect.retry`). So a run that reaches `failed` is **terminal**: it is the dead-letter. `voltro workflows list --dead-letter` (or the Prometheus series `voltro_workflow_runs_total{status="failed"}` and the stale `voltro_workflow_last_success_timestamp_seconds` gauge — see [Prometheus](/docs/plugins/prometheus)) is your queue of unhandled failures.
+
+Triage a dead-letter run one of three ways:
+
+- **Retry** it — `voltro workflows retry <id>` starts a fresh execution against the original (or an overridden) payload once you've fixed the cause. Every step runs again from scratch.
+- **Re-drive** it — `voltro workflows redrive <id>` re-drives the run from its durable journal: completed steps replay, only the failed step(s) re-execute. Use this instead of `retry` for a long pipeline where redoing steps 1…N‑1 is expensive or unsafe. It is the after-the-fact counterpart to [`suspendOnFailure` + `resume`](/docs/workflows/retries) and works under `voltro serve` too. Refuses a non-failed / already-discarded run; declines cleanly when there is no durable journal (the memory store). Records a `run-redriven` event.
+- **Discard** it — `voltro workflows discard <id>` acknowledges the failure so it drops off the `--dead-letter` view. It is an **ack, not a re-classification**: the run stays `status: 'failed'` (the outcome + audit trail survive) and gains a `discardedAt` timestamp. `--status failed` still lists it, marked `discarded`; only `--dead-letter` hides it. Discarding a non-failed run is refused, and discarding is idempotent.
+
 ## Dashboard
 
 When `voltro dev` is running, the Workflows panel lists recent runs, their status, start source, timing, payload, output/error, step attempts, and events. The run detail view is the fastest way to answer:
@@ -1199,7 +1288,7 @@ When `voltro dev` is running, the Workflows panel lists recent runs, their statu
 - What output or typed error did it produce?
 - Did a timer or signal fire?
 
-The panel also exposes run controls for users with the right capability: cancel, retry, suspend, resume, send signal, and send a tracked update.
+The panel also exposes run controls for users with the right capability: cancel, retry, suspend, resume, redrive (re-drive a failed run from its journal), discard (acknowledge a failed run), send signal, and send a tracked update.
 
 Run filters can be saved as named views. The selected view and ad-hoc
 filters are mirrored into the URL query string, so a teammate can open the
@@ -1213,12 +1302,15 @@ queued/running/waiting work by workflow lane and start source.
 ```sh
 voltro workflows list --status running --tail 50
 voltro workflows list --tag notes.summarise --format json
+voltro workflows list --dead-letter                  # failed runs not yet discarded
 voltro workflows start notes.summarise --payload '{"noteId":"note_123"}'
 voltro workflows show wfrun_01H...
 voltro workflows retry wfrun_01H...
 voltro workflows cancel wfrun_01H...
 voltro workflows suspend wfrun_01H...
 voltro workflows resume wfrun_01H...
+voltro workflows redrive wfrun_01H...                # re-drive a failed run from where it died
+voltro workflows discard wfrun_01H...                # acknowledge a failed run
 voltro workflows signal wfrun_01H... --name approval --payload '{"approved":true}'
 voltro workflows update wfrun_01H... --name approve --payload '{"decision":true}'
 voltro workflows children exec_01H...
@@ -1241,6 +1333,8 @@ POST /_voltro/inspect/workflows/runs/:id/cancel
 POST /_voltro/inspect/workflows/runs/:id/retry
 POST /_voltro/inspect/workflows/runs/:id/suspend
 POST /_voltro/inspect/workflows/runs/:id/resume
+POST /_voltro/inspect/workflows/runs/:id/redrive
+POST /_voltro/inspect/workflows/runs/:id/discard
 POST /_voltro/inspect/workflows/runs/:id/signal
 POST /_voltro/inspect/workflows/runs/:id/update
 ```

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.25.0",
-    "@voltro/cli": "0.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
+    "@voltro/ai": "0.27.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "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.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/plugin-auth": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
-    "@voltro/sql-postgres": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/plugin-auth": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
+    "@voltro/sql-postgres": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "vitest": "^4.1.10"
   }

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

@@ -13,16 +13,16 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/plugin-multitenancy": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/plugin-multitenancy": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "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.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/plugin-deactivation": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/plugin-deactivation": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "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.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/plugin-mail": "0.25.0",
-    "@voltro/plugin-multitenancy": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/plugin-mail": "0.27.0",
+    "@voltro/plugin-multitenancy": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
     "effect": "^3.22.0",
     "react": "^19.0.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "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.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/plugin-multitenancy": "0.25.0",
-    "@voltro/plugin-storage": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
-    "@voltro/sql-mysql": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/plugin-multitenancy": "0.27.0",
+    "@voltro/plugin-storage": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
+    "@voltro/sql-mysql": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "vitest": "^4.1.10"
   }

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

@@ -11,17 +11,17 @@
     "test": "voltro test"
   },
   "dependencies": {
-    "@voltro/cli": "0.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/plugin-multitenancy": "0.25.0",
-    "@voltro/plugin-storage": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/plugin-multitenancy": "0.27.0",
+    "@voltro/plugin-storage": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "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.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/plugin-governance": "0.25.0",
-    "@voltro/plugin-multitenancy": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/plugin-governance": "0.27.0",
+    "@voltro/plugin-multitenancy": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "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.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/plugin-multitenancy": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
-    "@voltro/workflow": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/plugin-multitenancy": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
+    "@voltro/workflow": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "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.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/plugin-flags": "0.25.0",
-    "@voltro/plugin-multitenancy": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
-    "@voltro/sql-postgres": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/plugin-flags": "0.27.0",
+    "@voltro/plugin-multitenancy": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
+    "@voltro/sql-postgres": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "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.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/plugin-audit": "0.25.0",
-    "@voltro/plugin-governance": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/plugin-audit": "0.27.0",
+    "@voltro/plugin-governance": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "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.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/kv": "0.25.0",
-    "@voltro/plugin-multitenancy": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/kv": "0.27.0",
+    "@voltro/plugin-multitenancy": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "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.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/env": "0.25.0",
-    "@voltro/plugin-moderation": "0.25.0",
-    "@voltro/plugin-multitenancy": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/env": "0.27.0",
+    "@voltro/plugin-moderation": "0.27.0",
+    "@voltro/plugin-multitenancy": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "vitest": "^4.1.10"
   }

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

@@ -13,17 +13,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.25.0",
-    "@voltro/database": "0.25.0",
-    "@voltro/plugin-multitenancy": "0.25.0",
-    "@voltro/plugin-prometheus": "0.25.0",
-    "@voltro/plugin-sentry": "0.25.0",
-    "@voltro/protocol": "0.25.0",
-    "@voltro/runtime": "0.25.0",
+    "@voltro/cli": "0.27.0",
+    "@voltro/database": "0.27.0",
+    "@voltro/plugin-multitenancy": "0.27.0",
+    "@voltro/plugin-prometheus": "0.27.0",
+    "@voltro/plugin-sentry": "0.27.0",
+    "@voltro/protocol": "0.27.0",
+    "@voltro/runtime": "0.27.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.25.0",
+    "@voltro/testing": "0.27.0",
     "typescript": "^6.0.3",
     "vitest": "^4.1.10"
   }

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

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