@voltro/cli 0.34.0 → 0.36.0

package/templates/agent-docs/workflows.md

@@ -493,6 +493,38 @@ Parent-close policies:
 
 The dashboard shows child runs, their parent execution id, and the selected policy. `ctx.workflows.wait(child)` accepts the run handle directly when the parent needs the child's success/failure snapshot.
 
+## Running on a cron — `workflow({ schedule })`
+
+A workflow whose only trigger is a clock can declare the cron on itself, instead of a separate `*.cron.tsx` file with a `workflow:` target:
+
+```tsx
+export default workflow({
+  name: 'reports.nightly',
+  payload: Schema.Struct({ day: Schema.String }),
+  idempotencyKey: (p) => `nightly:${p.day}`,
+  schedule: {
+    cron: '0 3 * * *',
+    timezone: 'Europe/Berlin',
+    payload: ({ scheduledAt }) => ({ day: scheduledAt.toISOString().slice(0, 10) }),
+    onOverlap: 'skip',
+  },
+})
+```
+
+This is sugar, not a second scheduler: at boot it lowers into a real schedule named `workflow:<name>` on the same coordinated cron engine every `defineSchedule` uses — same exactly-once claims, same run rows, same Schedules panel, same `voltro schedule run` / `backfill` verbs.
+
+What the declaration adds is overlap vocabulary **about the workflow run** (Temporal Schedules' names):
+
+- `onOverlap: 'skip'` *(default)* — a firing stands down while the previous firing's **run** is still going.
+- `'buffer'` — firings serialize behind the running one; none is lost.
+- `'cancelOther'` — the new firing cancels the still-running previous run (only runs this schedule started — a manually-started run of the same workflow is never touched), then starts fresh.
+
+The synthesized firing **awaits the run to completion** — that is what makes `skip`/`buffer` bind on the run's duration rather than on the milliseconds it takes to enqueue one, and it is why the firing watchdog (`schedule.maxRuntime`) defaults to **24 hours** here instead of a plain schedule's 30 minutes. Set it above your slowest expected run. A failed run fails the firing, so a nightly job that dies every night is red in the schedule ledger, not a wall of green.
+
+`payload` is a value or a function of the firing — a function receives `{ scheduledAt }`, so a backfilled firing computes against **its** slot, not "now". `backfill:` and everything else about missed firings work exactly as on a plain schedule — see [Overlap & backfill](/docs/scheduling/overlap-and-backfill).
+
+If the workflow also declares a deferring control (debounce, concurrency, …), a scheduled start passes the same admission gate as any other start — a deferred firing has nothing to await and hands the run to the admission queue.
+
 ## Tenant and subject
 
 Workflow starts persist the starter's trace id, source, parent execution id, parent-close policy — and their **identity**, never their authority — in `_voltro_workflow_start_contexts`. Whichever runner first executes the workflow loads that context before building the executor `AppContext`.
@@ -898,6 +930,24 @@ if (!decision.approved) {
 
 Signals are matched by name inside one workflow run. The payload is decoded with the supplied schema.
 
+### Long waits: `awaitSignalSuspending`
+
+`awaitSignal` **polls from inside a live activity** — the run keeps its worker fiber for the whole wait. Right for an approval that lands in seconds; wrong for a wait measured in hours or days, where a thousand parked runs pin a thousand fibers. For those, use the drop-in suspending variant:
+
+```tsx
+import { awaitSignalSuspending } from '@voltro/workflow'
+
+const decision = yield* awaitSignalSuspending(ctx, {
+  name: 'approval',
+  schema: Schema.Struct({ approved: Schema.Boolean }),
+  timeoutMs: 3 * 24 * 60 * 60_000,   // three days — a real human-in-the-loop wait
+})
+```
+
+Same call shape, same senders (`ctx.workflows.signal`, the dashboard button, the HTTP endpoint resume **both** variants), but the run returns `Suspended` while parked — the worker slot is freed and the wake lives in the engine's durable store, exactly like a long `sleep`. The timeout is durable too.
+
+**Rule of thumb: seconds → `awaitSignal`; anything a human might sleep on → `awaitSignalSuspending`.** The framework nudges you: an `awaitSignal` declaring a timeout above five minutes logs a one-time hint (once per workflow, never per poll) naming the suspending variant. Tune or effectively silence the threshold with `workflows: { suspendSignalHintMs }` in `app.config.ts`, or `VOLTRO_WORKFLOW_SUSPEND_HINT_MS` at runtime. It is a hint only — the framework never swaps the variant under a run, because the two journal differently and a silent swap mid-history is a replay trap dressed as a favour.
+
 ## Sending signals
 
 From the dashboard, open a running workflow and use "Send signal".
@@ -1398,6 +1448,8 @@ priority: (p) => (p.urgent ? 100 : 0)
 
 Higher runs first out of the pending queue. Ties break by arrival, so an all-default deployment is FIFO rather than dialect-dependent.
 
+> **Scope — read before porting BullMQ priority lanes.** `priority` orders **the admission queue only**: the pending rows a deferring control (debounce, batch, throttle, concurrency), a pause, or a delayed `{ at }` start has parked. A start that is admitted immediately never competes with anything — it goes straight to the engine, whatever any other start's priority says. There are no cross-workflow priority lanes, no preemption of running work, and no ordering between two starts that both found a free slot. If urgent starts must overtake normal ones, put both classes behind the same `concurrency` limit (or a shared `pool`), so every start passes through the queue that `priority` orders.
+
 ## timeouts
 
 ```ts
@@ -1519,6 +1571,28 @@ The result is per-run, not a count: `succeeded`, `failed` (with the reason for e
 
 Eligibility is fixed by the verb: a cancel acts on `running` and `suspended` runs; `replay --mode redrive` on `failed` only (redrive resumes from the step that died, which only exists for a failure); `replay --mode retry` on `failed` and `cancelled`. `--mode` has no default because the two cost very different amounts.
 
+## Delayed one-off starts — `start(..., { at })`
+
+Run this once, later — without a schedule and without a `sleep` at the top of the body:
+
+```ts
+await ctx.workflows.start('orders.remind', { orderId }, {
+  at: new Date(Date.now() + 24 * 60 * 60_000),   // tomorrow, this time
+})
+```
+
+The start is parked as a **durable row** in the same pending queue the controls above use (`mode: 'delayed'`), and the coordinated drainer fires it when `at` arrives — it survives restarts and fires on whichever replica drains, never from an in-process timer. The handle comes back `status: 'queued'` with `deferral: { mode: 'delayed', dueAt }`.
+
+Semantics worth knowing:
+
+- **`at` is an absolute instant, deliberately** — not a `delay` duration. A delay is measured "from when?" (enqueue? admission? retry?) and every queueing system answers differently; an instant has no such ambiguity and composes with the schedule/backfill surfaces, which are also instant-based. A relative delay is one line: `at: new Date(Date.now() + ms)`.
+- **At `at`, the start becomes an ordinary ARRIVAL.** Declared controls judge it as of that moment — a debounce collapses it into whatever window is open then, a rate cap can drop it (recorded, as always). `{ at }` delays the arrival; it never outranks a control.
+- An `at` in the past starts immediately — "no earlier than" is already satisfied.
+- `{ at, wait: true }` is refused: there is no result to block on for a start that exists only as a future row.
+- Each `{ at }` start is its own row. Two delayed starts never collapse into one — unlike debounce, nothing about `{ at }` says the second supersedes the first. Want collapsing? That is `debounce`, and they compose.
+
+Prefer this over `sleep` as the first step of the body when the wait precedes the work: a parked row costs one row, a sleeping run costs a durable execution the whole time.
+
 ## What a deferred start returns
 
 `start()` no longer always returns a running handle:
@@ -1575,6 +1649,18 @@ A workflow that declares one pays only for that one: an undeclared control costs
 
 The drainer runs on **one replica per tick** through the same claim arbiter the cron scheduler uses. N replicas draining at once would each see a free slot and each take it.
 
+### Measured admission throughput
+
+Measured, not estimated — `node packages/cli/scripts/admission-throughput.mjs` in the framework repo drives the real gate, facade and drainer against the in-memory reference store (slope across N=500/1000/2000 starts, median of 3 sequential repeats; Apple-silicon dev machine, 2026-08):
+
+- **no controls (passthrough): ~1 µs/start (~800,000 starts/s)** — the do-nothing path really does nothing.
+- **through a concurrency gate: ~110 µs/start (~9,000 starts/s)** — dominated by the reference store's *unindexed* admission-state scan, which grows with the ledger; a real dialect serves that read from an index, but also adds its round-trips. Read this as the machinery's worst-case CPU floor, not a database benchmark.
+- **durable park → drain → start: ~4 µs/row (~240,000 rows/s)** of pure machinery per queued row.
+
+The deployed ceiling is `min(these numbers, what your database serves for the admission reads/writes)` — on any SQL dialect the database is the bound long before the gate is. That is also why there is no key-group batching in the admission path: at ~9k gated starts/s worst-case CPU, batching would add a flush boundary to a path whose bound is elsewhere.
+
+Per **step**, the recorder adds exactly **2 fire-and-forget store writes** (insert at step start, update at settle), off the step's critical path — plus the cluster engine's own journal write, which is the durability you asked for. Hot high-step workflows can turn the introspection copy off: `workflows: { recording: 'coarse' }` — see [Debugging](/docs/workflows/debugging).
+
 
 
 ---
@@ -1695,6 +1781,21 @@ Voltro records workflow runs, step attempts, and lifecycle events into framework
 
 Run status is `running`, `succeeded`, `failed`, `cancelled`, or `suspended`.
 
+### Turning the step rows off — `workflows.recording: 'coarse'`
+
+Every `step()` costs two fire-and-forget writes to `_voltro_workflow_run_steps` (insert at start, update at settle) — measured, and off the step's critical path, but on a hot workflow with many steps they dominate the table's growth. `'coarse'` skips **both**:
+
+```ts
+// app.config.ts
+export default {
+  workflows: { recording: 'coarse' },   // default: 'full'
+}
+```
+
+Runtime override without a rebuild: `VOLTRO_WORKFLOW_RECORDING=coarse` (env wins over config; anything unrecognised falls back to `'full'`).
+
+What `'coarse'` does **not** touch, deliberately: run rows, run events (signals, timers, cancels, stall reports — everything the dead-letter view and the sweeps read), and the cluster engine's own durable journal — replay and redrive are unaffected. The cost is exactly the dashboard's step timeline: empty for runs recorded under `'coarse'`. Flip it back when you need to see inside a run.
+
 ## 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.

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