@voltro/cli 0.6.0 → 0.7.0

package/dist/startEntry.d.ts

@@ -0,0 +1,5 @@
+export declare const loadDotEnv: (argv: ReadonlyArray<string>) => void;
+
+export declare const runStartCommand: (args: ReadonlyArray<string>) => Promise<number>;
+
+export { }

package/dist/startEntry.js

@@ -0,0 +1,3 @@
+import { k as e } from "./inspectMetrics-BLUBAWLb.js";
+import { t } from "./start-CWZW_4Et.js";
+export { e as loadDotEnv, t as runStartCommand };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/cli",
-  "version": "0.6.0",
+  "version": "0.7.0",
   "description": "The `voltro` CLI — dev server, codegen, migrations, project scaffolding, agent-docs seeding, and production serve.",
   "keywords": [
     "voltro",
@@ -57,22 +57,22 @@
     "@effect/platform-node": "^0.107.0",
     "@effect/sql": "^0.51.1",
     "@effect/workflow": "^0.18.2",
-    "@voltro/ai": "0.6.0",
-    "@voltro/cache": "0.6.0",
-    "@voltro/data-transfer": "0.6.0",
-    "@voltro/database": "0.6.0",
-    "@voltro/env": "0.6.0",
-    "@voltro/kv": "0.6.0",
-    "@voltro/logger": "0.6.0",
-    "@voltro/plugin-auth": "0.6.0",
-    "@voltro/plugin-broadcast": "0.6.0",
-    "@voltro/plugin-mail": "0.6.0",
-    "@voltro/plugin-storage": "0.6.0",
-    "@voltro/plugin-webhooks": "0.6.0",
-    "@voltro/protocol": "0.6.0",
-    "@voltro/runtime": "0.6.0",
-    "@voltro/serverless": "0.6.0",
-    "@voltro/workflow": "0.6.0",
+    "@voltro/ai": "0.7.0",
+    "@voltro/cache": "0.7.0",
+    "@voltro/data-transfer": "0.7.0",
+    "@voltro/database": "0.7.0",
+    "@voltro/env": "0.7.0",
+    "@voltro/kv": "0.7.0",
+    "@voltro/logger": "0.7.0",
+    "@voltro/plugin-auth": "0.7.0",
+    "@voltro/plugin-broadcast": "0.7.0",
+    "@voltro/plugin-mail": "0.7.0",
+    "@voltro/plugin-storage": "0.7.0",
+    "@voltro/plugin-webhooks": "0.7.0",
+    "@voltro/protocol": "0.7.0",
+    "@voltro/runtime": "0.7.0",
+    "@voltro/serverless": "0.7.0",
+    "@voltro/workflow": "0.7.0",
     "chokidar": "^5.0.0",
     "ioredis": "^5.11.1",
     "ts-morph": "^28.0.0"

package/templates/agent-docs/authentication.md

@@ -351,6 +351,29 @@ if (ctx.subject.type === 'anonymous') {
 }
 ```
 
+## App metadata — `subjectFromUser(user, { metadata })`
+
+`metadata` is the free-form slot the framework itself never reads. It is where a provider credential captured at login belongs — a plugin's `credentialsResolver` reads it back per request (`@voltro/plugin-atlassian` looks for `subject.metadata.jiraToken`, say), so nothing has to be re-fetched or stored server-side per call.
+
+Pass it when you build the Subject:
+
+```ts
+import { subjectFromUser } from '@voltro/plugin-auth'
+
+const subject = subjectFromUser(user, {
+  memberships,                              // → metadata.memberships
+  metadata: { jiraToken: atlassianPat },    // → metadata.jiraToken
+})
+```
+
+The two merge — neither clobbers the other. **When a `memberships` key appears in both,** the dedicated `memberships` option wins: it is the typed input, and it is the one projected into the `{ tenantId, role }` shape `subjectMemberships()` and the tenant switcher read. Without the option, a `memberships` key inside `metadata` passes through unchanged. A Subject built with neither option has no `metadata` key at all.
+
+Keys set this way survive the login paths: the sign-in / sign-up / magic-link / passkey handlers merge `sessionId` onto the existing slot, and the password strategy merges `provider` — they add, they don't replace. The one exception is naming a key `sessionId` or `provider` yourself; those two are overwritten by design.
+
+**It survives a tenant switch too.** A switch rebuilds the Subject from the user record, so the built-in `/switch-tenant` route passes the caller's current `subject.metadata` through to `handleSwitchTenant` — a credential parked here keeps working after the user changes tenant. Calling `handleSwitchTenant` yourself? Pass `metadata` or the credential is dropped, and the symptom is unpleasant to diagnose: the user stays signed in while every call to the provider starts failing. `memberships` is deliberately *not* carried — it is re-derived for the target tenant, and a carried copy would report a role the user does not hold there.
+
+Two things not to put here. **Anything the caller could benefit from changing** — the slot rides the signed session cookie, so it is tamper-evident, but it is also stale by design: it reflects the moment of sign-in, not the current database. And **anything large** — it is re-serialised into every session cookie.
+
 ## Resolution
 
 `AuthMiddleware` resolves a `Subject` on every request by running the [strategy chain](/docs/authentication/strategies) — `composeAuthStrategies` evaluates each strategy in order, first `matched` wins, first `failed` short-circuits to anonymous. A typical chain resolves, in order:
@@ -1975,16 +1998,88 @@ await ctx.store.query(tickets.descriptor)   // filtered
 await ctx.store.select('tickets').all()     // filtered
 ```
 
-## A failing `load` denies
+## When `load` fails
+
+`load` reads your store — for relational visibility it *must* — which makes it
+exactly the kind of call that blips. Two separate questions follow from a
+failure, and the answers are deliberately different.
+
+### First: is the failure even real? (`retry`)
+
+A transient failure must never reach the decision below, because once it gets
+there it is indistinguishable from an authorization answer. So `load` runs under
+a bounded retry before anything is concluded from it:
+
+```ts no-check
+import { Schedule } from 'effect'
+
+setRowFilter({
+  load,
+  predicate,
+  retry: Schedule.recurs(5),   // your own schedule
+  // retry: false,             // exactly one attempt
+})
+```
+
+The default is `DEFAULT_ROW_FILTER_RETRY` (exported from `@voltro/runtime`):
+**three attempts, backing off exponentially from 20ms** — about 60ms of added
+latency in the worst case. It is sized for a blip (a connection reaped from the
+pool, a failover flap), not for an outage. A `load` still failing after that is
+not having a bad moment, and stretching the schedule only turns a fast honest
+error into a slow one while holding the request open.
+
+### Then: what does a real failure mean? (`onLoadError`)
+
+Not "you may see nothing". **We cannot tell what you may see.** Those are
+different facts and only one of them is a fact — so the default raises a typed
+error:
+
+```ts no-check
+setRowFilter({
+  load,
+  predicate,
+  onLoadError: 'fail',   // default — raises RowFilterUnavailable
+  // onLoadError: 'deny', // degrade to zero rows instead
+})
+```
+
+- **`'fail'` (default)** — the request fails with the typed
+  `RowFilterUnavailable`. Handle it in your UI as an error state, the same as any
+  other failed request.
+- **`'deny'`** — refusal is expressed as a predicate matching nothing, so the
+  read returns an empty result. Choose this only if you have looked at the screen
+  and are content for it to render empty during an outage. Your `onError`
+  reporter still fires, so the failure stays findable in logs even though the
+  response is a 200.
+
+The default changed *to* `'fail'`, and the reasoning is worth stating plainly
+because the old default looked defensible: an empty result for an infrastructure
+failure is byte-identical to legitimate emptiness. The user reads "you have no
+tickets". The operator reads a healthy 200. The outage is invisible to both —
+the most misleading outcome on offer. Every constrained page **is** broken when
+this happens, and saying so is the only outcome either party can act on.
+
+### There is no fail-open option
+
+A frequent request, and a deliberate refusal: there is no policy that serves
+**unfiltered** rows when the filter is unavailable, falling back to whatever
+check the handler carries.
+
+Failing open on an authorization filter leaks data precisely when the system is
+under stress and nobody is reading dashboards. And it is only safe if every
+handler still carries its own row-level check — which is the entire thing a row
+filter exists to remove. A codebase where fail-open is safe is a codebase that
+did not need `setRowFilter`.
+
+Both policies above are fail-**closed**: neither can ever produce an unfiltered
+read.
 
-If `load` fails, every constrained read is **refused** rather than silently
-running unfiltered. A row filter that degrades to "no filter" under load failure
-is worse than no filter at all, because the system keeps serving and nothing
-looks wrong.
+### Subscriptions
 
-The refusal is expressed as a predicate that matches nothing, not as an error —
-so a failure surfaces as an **empty result** rather than a 500 on every page. The
-underlying cause is reported separately, so it cannot pass unnoticed.
+A resolution failure mid-stream **revokes** the subscription and emits a typed
+error frame, rather than delivering an empty snapshot — an empty snapshot on a
+live subscription reads to a client as "every row you could see was just
+deleted". Make sure your subscription error handling surfaces it.
 
 ## What does *not* bypass it
 
@@ -2022,7 +2117,7 @@ They answer different questions, and a complete policy usually wants both:
 | | Question | Failure |
 |---|---|---|
 | [`guards:`](/docs/authentication/authorization#enforce-it-declaratively-guards) | May you call this procedure? | typed `ScopeError`, before the executor runs |
-| `setRowFilter` | Which rows may you see? | the rows are simply absent |
+| `setRowFilter` | Which rows may you see? | the rows are simply absent — unless the filter itself could not load, which is a typed `RowFilterUnavailable` |
 
 A guard is the right tool for "may this caller edit *this* ticket". A row filter
 is the right tool for "which tickets appear in the list at all" — a question a

package/templates/agent-docs/cli.md

@@ -1822,7 +1822,7 @@ _voltro update — bump the framework to the latest version and run the codemods
 `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).
+2. **Install** with your project's package manager — see [Which package manager](#which-package-manager) below.
 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
@@ -1831,12 +1831,47 @@ 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)
+voltro update --help          # every flag — always answered, even on a dirty tree
 
 # Recover the codemods after a MANUAL version bump (no bump, no install):
 voltro update --codemods-only --from 0.3.0            # re-run codemods 0.3.0 → installed
 voltro update --codemods-only --from 0.3.0 --to 0.4.0 # explicit delta
 ```
 
+## In a workspace, the whole workspace moves
+
+Run `voltro update` anywhere inside a workspace — a `pnpm-workspace.yaml`, or a
+`workspaces` field in an ancestor `package.json` — and **every member
+`package.json` that declares `@voltro/*` is bumped to the same version**, with
+the install running **once at the workspace root**.
+
+This is not a convenience. Your api and your web app share generated types (the
+rpcGroup) and a session cookie shape; if the api moves to 0.6.0 while
+`apps/web` and `packages/ui-*` stay on 0.5.0, the mismatch shows up as a runtime
+decode error in the browser, not as a build failure. Half-upgraded is the worst
+state to be in, so `voltro update` never leaves you there.
+
+The plan output — and `--dry-run` — lists every file it will touch:
+
+```text
+voltro update: 0.5.0 → 0.6.0
+  workspace: /repo (4 package.json with @voltro/* deps)
+  package.json
+    @voltro/cli: ^0.5.0 → ^0.6.0
+  apps/api/package.json
+    @voltro/cli: ^0.5.0 → ^0.6.0
+    @voltro/database: ^0.5.0 → ^0.6.0
+  apps/web/package.json
+    @voltro/client: ^0.5.0 → ^0.6.0
+  packages/ui-admin/package.json
+    @voltro/web: ~0.5.0 → ~0.6.0
+  package manager: pnpm
+  install runs in: /repo
+```
+
+A standalone (non-workspace) project is unaffected: its own `package.json`, its
+own install, in place.
+
 ## Already bumped by hand? Recover the codemods
 
 If you bump `@voltro/*` versions in `package.json` yourself and install first, a
@@ -1859,9 +1894,31 @@ source version.
 
 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).
 
+`--help` / `-h` is answered *before* the guard, so `voltro update --help` prints the flag list even on a dirty tree. The same holds for `voltro doctor --help`.
+
+## If the install fails
+
+The bump is written before the install runs, so a failed install leaves your `package.json` on the target version — and **no codemods applied**. `voltro update` says so explicitly, because the codemods for a jump ship *inside* the target version: a failed install never put them on disk, so there is nothing that could have run them. Fix the install, run it, then apply the codemods you are missing with the command the failure message prints for you:
+
+```bash
+voltro update --codemods-only --from 0.5.0 --to 0.6.0
+```
+
 ## 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.
+Every `@voltro/*` entry in `dependencies` and `devDependencies` — in every workspace member, see above — 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.
+
+## Which package manager
+
+`voltro update` never assumes npm. It resolves your project's package manager in this order, starting in the app directory and walking **up to the repo root**:
+
+1. The **`packageManager` field** in a `package.json` (the corepack standard) — authoritative, wins over any lockfile.
+2. A **lockfile** at that level — `pnpm-lock.yaml`, `yarn.lock`, `bun.lock` / `bun.lockb`, `package-lock.json`.
+3. **npm**, only when nothing declares one.
+
+Walking up matters in a workspace: a scaffolded Voltro project keeps its lockfile at the monorepo root, so running `voltro update` from `apps/api` still finds `pnpm` rather than falling back to npm and running `npm install` against a pnpm workspace.
+
+The same resolved manager is used for the **registry lookup** of the latest version (`pnpm view`, `yarn npm info`, `bun pm view`), so a private or scoped registry configured in your `.npmrc` / `.yarnrc.yml` is honored. `npm view` is only a last-resort fallback.
 
 ## Codemods
 

package/templates/agent-docs/data.md

@@ -379,6 +379,50 @@ A `.nullable()` column wraps its mapped type, so a null timestamp round-trips as
 `null` rather than becoming epoch 0 (which would render as a plausible
 `1970-01-01` instead of "never").
 
+### Computed outputs — `timestampMs`
+
+`rowSchema(table)` only helps a handler that returns a **raw, full table row**.
+Most handlers don't: they return a struct assembled by hand from several tables
+— `{ id, name, slug, addedAt, jiraProjectKey }` — where there is no single table
+to derive from. That is exactly where the hand-written `Date → epoch` converters
+pile up.
+
+For those, use the field-level exports directly in your own `Schema.Struct`:
+
+```ts
+// apps/api/queries/projects.list.query.ts
+import { defineQuery } from '@voltro/protocol'
+import { timestampMs, timestampMsOrNull } from '@voltro/database'
+import { Schema } from 'effect'
+
+export const listProjects = defineQuery({
+  name:   'projects.list',
+  source: 'projects',
+  input:  Schema.Struct({}),
+  output: Schema.Array(
+    Schema.Struct({
+      id:             Schema.String,
+      name:           Schema.String,
+      jiraProjectKey: Schema.String,
+      addedAt:        timestampMs,        // Date in the handler, epoch ms on the wire
+      archivedAt:     timestampMsOrNull,  // for a nullable timestamp column
+      seenAt:         Schema.optional(timestampMs),
+    }),
+  ),
+})
+```
+
+Same semantics as a `timestamp()` column inside `rowSchema` — literally the same
+schema, which `columnSchema` reads from, so the two can never drift into
+different wire representations.
+
+- `timestampMs` — `Date` in the handler, `number` (epoch ms) on the wire.
+- `timestampMsOrNull` — for a `.nullable()` timestamp. Use this rather than
+  converting a null by hand: `new Date(null)` is `1970-01-01`, so "never
+  archived" renders as a plausible date instead of as nothing.
+- An **optional** field is `Schema.optional(timestampMs)` — there is no third
+  export for it.
+
 ### Keeping a column off the wire — `omit`
 
 ```ts

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

@@ -423,7 +423,7 @@ the framework ships richer types for specific use cases:
 - **`timestamp` without `tz`.** Use `timestamp()` which is `timestamptz`.
 - **Storing JSON blobs as `text`.** Use `json<T>()` for type-safety + JSONB performance.
 - **`references('table')`.** The constructor is `reference(() => table)` — singular, thunk-arg.
-- **Declaring a `timestamp()` column as `Schema.Number` in a descriptor's `output`.** That describes the *wire* type, not the domain type, so the schema has nothing left to convert and the handler ends up doing it by hand. Derive the row schema instead — [`rowSchema(table)`](/docs/data/queries#output-is-the-serializer-rowschema-table).
+- **Declaring a `timestamp()` column as `Schema.Number` in a descriptor's `output`.** That describes the *wire* type, not the domain type, so the schema has nothing left to convert and the handler ends up doing it by hand. Derive the row schema instead — [`rowSchema(table)`](/docs/data/queries#output-is-the-serializer-rowschema-table) for a whole row, or [`timestampMs` / `timestampMsOrNull`](/docs/data/queries#computed-outputs-timestampms) for one field of a hand-written struct.
 
 
 

package/templates/agent-docs/testing.md

@@ -116,6 +116,8 @@ test('searchDocs returns matching rows', async () => {
 | `ai` | — | Injected AI mock (a `mockAi({...})` value). |
 | `llmResponses` | `[]` | Queued responses for the bundled `ctx.llm` (`MockLLM`). |
 | `env` | ambient `process.env` | Env values sealed into the boot snapshot so handler code reading `getSecret('X')` / `serverEnv.X` resolves under test. Merged over `process.env` (these win). |
+| `relations` | — | `relations()` specs to register for this context — the boot sweep's stand-in. See [Eager loads under test](#eager-loads-under-test). |
+| `rowFilter` | the registered filter | A row filter for this context only, instead of the process-global `setRowFilter(...)`. See [Row-level security under test](#row-level-security-under-test). |
 
 The returned `TestContext` carries `{ clock, email, llm, ai?, request, cache, store, withSubject, withTenant }` — read the acting subject at `ctx.request.subject` and the in-memory cache at `ctx.cache`.
 
@@ -137,6 +139,31 @@ const note = await invoke(createNote, createNoteHandler, { title: 'hi' }, ctx)
 await expect(invoke(createNote, createNoteHandler, { title: 42 }, ctx)).rejects.toThrow()
 ```
 
+### Effect-mode handlers run too
+
+A handler may be written `async` **or** as an `Effect` — the framework's contract is "your choice, per handler", and the dispatcher runs both. `invoke` makes the same test, so an `Effect`-returning executor is *executed*, and `invoke` resolves to its success value (typed as that value, not as the `Effect`):
+
+```ts
+export const publishNote = (input: { id: string }, ctx: AppContext) =>
+  Effect.gen(function* () {
+    const store = yield* EffectStore
+    yield* store.update('notes', input.id, { published: true })
+    return 'published'
+  })
+
+const out = await invoke(publish, publishNote, { id: 'n1' }, ctx)
+expect(out).toBe('published')     // the value — not an un-run Effect
+```
+
+A failure on the typed error channel rejects with **that error**, exactly as an async handler's `throw` does — so the same assertion works for either mode:
+
+```ts
+await expect(invoke(publish, publishNote, { id: 'gone' }, ctx))
+  .rejects.toMatchObject({ _tag: 'NoteNotFound' })
+```
+
+`EffectStore` and `SubjectService` are provided over the context the handler is actually given — inside a mutation that is the *transactional* one, so an Effect handler's writes roll back with everything else. Guards, the input decode, the transaction, the deadlock replay, `afterCommit` and the plugin interceptors all wrap the Effect form identically. An app's own `layers:` and the aggregate registry are **not** provided: those are boot injections the harness has no access to.
+
 ### Guards are enforced
 
 An unauthorized caller is refused with the typed `ScopeError` — the same error a client would receive — before the handler runs:
@@ -325,6 +352,37 @@ const raw = await ctx.store.select('notes').unscoped().withDeleted().all()
 expect(raw[0]?.deletedAt).not.toBeNull()            // …but still there, tombstoned
 ```
 
+## Eager loads under test
+
+`relations()` is **pure** — it returns a spec, it does not register one. In production `voltro dev` discovers every `*.relations.ts` and registers what it exports; a unit test runs no boot, so importing the module registers nothing and the first `.with({ … })` fails with *"no relations registered"*. Hand the specs to the context instead:
+
+```ts
+import { teamRelations } from '../db/teams.relations'
+
+const ctx = makeTestContext({
+  relations: [teamRelations],
+  store: mockStore({ teams: [{ id: 't1' }], members: [{ id: 'm1', teamId: 't1' }] }),
+})
+
+const rows = await ctx.store.select('teams').with({ members: true }).all()
+expect(rows[0].members).toHaveLength(1)
+```
+
+The relations registry is **process-global**, so the option *replaces* it with exactly the specs you pass rather than adding to it. That is what keeps two `makeTestContext({ relations: [...] })` calls in one file independent — additive registration would throw `duplicate relation` on a re-registered spec and would carry the first test's relations into the second. Omitting the option leaves the registry untouched.
+
+## Row-level security under test
+
+`ctx.store` applies the app's [row filter](/docs/authentication/row-level-security) for the context's subject: registered with `setRowFilter(...)`, resolved once per context, AND-merged into every read. Both read paths are covered (the fluent builders and `store.query(descriptor)`), `.unscoped()` does **not** bypass it — that opts out of tenant isolation, not of authorization — and a `system` subject bypasses it, exactly as at runtime.
+
+```ts
+const ctx = makeTestContext({ subject: alice, store: mockStore({ tickets: seed }), rowFilter: ownTickets })
+
+const rows = await ctx.store.select('tickets').all()
+expect(rows.map((r) => r.id)).not.toContain('bobs-ticket')  // the rule, asserted
+```
+
+Pass `rowFilter:` — as above — to scope a filter to **this context only**. `setRowFilter` is process-global: registered in one test it silently constrains every later test in the same worker, and a forgotten `afterEach` surfaces as a failure in an unrelated file. Either way the resolution is the runtime's own, so the retry schedule, the system bypass and the `onLoadError` policy behave identically: a filter whose `load` fails refuses the read (with `RowFilterUnavailable`, or zero rows under `onLoadError: 'deny'`) rather than quietly returning everything.
+
 ## The deterministic mocks
 
 ### `ctx.clock` — `MockClock`

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.6.0",
-    "@voltro/cli": "0.6.0",
-    "@voltro/database": "0.6.0",
-    "@voltro/env": "0.6.0",
-    "@voltro/protocol": "0.6.0",
-    "@voltro/runtime": "0.6.0",
+    "@voltro/ai": "0.7.0",
+    "@voltro/cli": "0.7.0",
+    "@voltro/database": "0.7.0",
+    "@voltro/env": "0.7.0",
+    "@voltro/protocol": "0.7.0",
+    "@voltro/runtime": "0.7.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.6.0",
+    "@voltro/testing": "0.7.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.6.0",
-    "@voltro/database": "0.6.0",
-    "@voltro/env": "0.6.0",
-    "@voltro/plugin-auth": "0.6.0",
-    "@voltro/protocol": "0.6.0",
-    "@voltro/runtime": "0.6.0",
-    "@voltro/sql-postgres": "0.6.0",
+    "@voltro/cli": "0.7.0",
+    "@voltro/database": "0.7.0",
+    "@voltro/env": "0.7.0",
+    "@voltro/plugin-auth": "0.7.0",
+    "@voltro/protocol": "0.7.0",
+    "@voltro/runtime": "0.7.0",
+    "@voltro/sql-postgres": "0.7.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.6.0",
+    "@voltro/testing": "0.7.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.6.0",
-    "@voltro/database": "0.6.0",
-    "@voltro/env": "0.6.0",
-    "@voltro/plugin-multitenancy": "0.6.0",
-    "@voltro/protocol": "0.6.0",
-    "@voltro/runtime": "0.6.0",
+    "@voltro/cli": "0.7.0",
+    "@voltro/database": "0.7.0",
+    "@voltro/env": "0.7.0",
+    "@voltro/plugin-multitenancy": "0.7.0",
+    "@voltro/protocol": "0.7.0",
+    "@voltro/runtime": "0.7.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.6.0",
+    "@voltro/testing": "0.7.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.6.0",
-    "@voltro/database": "0.6.0",
-    "@voltro/env": "0.6.0",
-    "@voltro/plugin-deactivation": "0.6.0",
-    "@voltro/protocol": "0.6.0",
-    "@voltro/runtime": "0.6.0",
+    "@voltro/cli": "0.7.0",
+    "@voltro/database": "0.7.0",
+    "@voltro/env": "0.7.0",
+    "@voltro/plugin-deactivation": "0.7.0",
+    "@voltro/protocol": "0.7.0",
+    "@voltro/runtime": "0.7.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.6.0",
+    "@voltro/testing": "0.7.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.6.0",
-    "@voltro/database": "0.6.0",
-    "@voltro/env": "0.6.0",
-    "@voltro/plugin-mail": "0.6.0",
-    "@voltro/plugin-multitenancy": "0.6.0",
-    "@voltro/protocol": "0.6.0",
-    "@voltro/runtime": "0.6.0",
+    "@voltro/cli": "0.7.0",
+    "@voltro/database": "0.7.0",
+    "@voltro/env": "0.7.0",
+    "@voltro/plugin-mail": "0.7.0",
+    "@voltro/plugin-multitenancy": "0.7.0",
+    "@voltro/protocol": "0.7.0",
+    "@voltro/runtime": "0.7.0",
     "effect": "^3.21.2",
     "react": "^19.0.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.6.0",
+    "@voltro/testing": "0.7.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.6.0",
-    "@voltro/database": "0.6.0",
-    "@voltro/env": "0.6.0",
-    "@voltro/plugin-multitenancy": "0.6.0",
-    "@voltro/plugin-storage": "0.6.0",
-    "@voltro/protocol": "0.6.0",
-    "@voltro/runtime": "0.6.0",
-    "@voltro/sql-mysql": "0.6.0",
+    "@voltro/cli": "0.7.0",
+    "@voltro/database": "0.7.0",
+    "@voltro/env": "0.7.0",
+    "@voltro/plugin-multitenancy": "0.7.0",
+    "@voltro/plugin-storage": "0.7.0",
+    "@voltro/protocol": "0.7.0",
+    "@voltro/runtime": "0.7.0",
+    "@voltro/sql-mysql": "0.7.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.6.0",
+    "@voltro/testing": "0.7.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.6.0",
-    "@voltro/database": "0.6.0",
-    "@voltro/env": "0.6.0",
-    "@voltro/plugin-multitenancy": "0.6.0",
-    "@voltro/plugin-storage": "0.6.0",
-    "@voltro/protocol": "0.6.0",
-    "@voltro/runtime": "0.6.0",
+    "@voltro/cli": "0.7.0",
+    "@voltro/database": "0.7.0",
+    "@voltro/env": "0.7.0",
+    "@voltro/plugin-multitenancy": "0.7.0",
+    "@voltro/plugin-storage": "0.7.0",
+    "@voltro/protocol": "0.7.0",
+    "@voltro/runtime": "0.7.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.6.0",
+    "@voltro/testing": "0.7.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.6.0",
-    "@voltro/database": "0.6.0",
-    "@voltro/env": "0.6.0",
-    "@voltro/plugin-governance": "0.6.0",
-    "@voltro/plugin-multitenancy": "0.6.0",
-    "@voltro/protocol": "0.6.0",
-    "@voltro/runtime": "0.6.0",
+    "@voltro/cli": "0.7.0",
+    "@voltro/database": "0.7.0",
+    "@voltro/env": "0.7.0",
+    "@voltro/plugin-governance": "0.7.0",
+    "@voltro/plugin-multitenancy": "0.7.0",
+    "@voltro/protocol": "0.7.0",
+    "@voltro/runtime": "0.7.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.6.0",
+    "@voltro/testing": "0.7.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }