npm - @voltro/cli - Versions diffs - 0.7.0 → 0.9.0 - Mend

@voltro/cli 0.7.0 → 0.9.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (61) hide show

package/CHANGELOG.md +40 -0
package/THIRD-PARTY-NOTICES.md +2 -2
package/dist/apiBuild-Ba4njm9m.js +2 -0
package/dist/{apiBuild-deIjJKJm.js → apiBuild-eInHm_bJ.js} +2 -2
package/dist/bin.js +2 -2
package/dist/{commands-BHdc71DG.js → commands-Cxs97AFp.js} +1897 -1664
package/dist/{dev-Bqyq62Ak.js → dev-63Ehpw2p.js} +475 -475
package/dist/dev-CXsR8Zgo.js +2 -0
package/dist/index.js +1 -1
package/dist/{inspectMetrics-BLUBAWLb.js → inspectMetrics-DVCKKSPk.js} +819 -510
package/dist/{serveCommand-Dn6--0Bv.js → serveCommand-Cq7BhtpB.js} +3 -3
package/dist/serveEntry.js +3 -3
package/dist/{start-CWZW_4Et.js → start-CYe-7ueh.js} +371 -306
package/dist/startEntry.js +2 -2
package/package.json +18 -17
package/templates/AGENTS.core.md +15 -4
package/templates/AGENTS.md +15 -4
package/templates/agent-docs/authentication.md +7 -4
package/templates/agent-docs/cli.md +84 -5
package/templates/agent-docs/data.md +94 -70
package/templates/agent-docs/database/schema.md +1 -1
package/templates/agent-docs/reference.md +20 -0
package/templates/agent-docs/routing.md +183 -25
package/templates/agent-docs/testing.md +24 -0
package/templates/apps/api-ai/package.json +7 -7
package/templates/apps/api-auth/package.json +8 -8
package/templates/apps/api-backend/package.json +7 -7
package/templates/apps/api-backend-deactivation/package.json +7 -7
package/templates/apps/api-backend-mail/package.json +8 -8
package/templates/apps/api-backend-mariadb/package.json +9 -9
package/templates/apps/api-backend-storage/package.json +8 -8
package/templates/apps/api-data-advanced/package.json +8 -8
package/templates/apps/api-durable/package.json +8 -8
package/templates/apps/api-feature-flags/package.json +9 -9
package/templates/apps/api-governance/package.json +8 -8
package/templates/apps/api-kv/package.json +8 -8
package/templates/apps/api-moderation/package.json +8 -8
package/templates/apps/api-observability/package.json +8 -8
package/templates/apps/api-ratelimit/package.json +8 -8
package/templates/apps/api-rbac/package.json +8 -8
package/templates/apps/api-rest/package.json +7 -7
package/templates/apps/api-saas/package.json +11 -11
package/templates/apps/api-search/package.json +8 -8
package/templates/apps/api-versioning/package.json +8 -8
package/templates/apps/api-webhooks/package.json +8 -8
package/templates/apps/changelog/package.json +6 -6
package/templates/apps/edge-functions/package.json +2 -2
package/templates/apps/frontend-admin/package.json +8 -8
package/templates/apps/frontend-app/package.json +8 -8
package/templates/apps/frontend-blank/package.json +7 -7
package/templates/apps/frontend-contact/package.json +7 -7
package/templates/apps/frontend-dashboard/package.json +7 -7
package/templates/apps/frontend-docs/package.json +7 -7
package/templates/apps/frontend-i18n/package.json +6 -6
package/templates/apps/frontend-landing/package.json +7 -7
package/templates/apps/frontend-spa/package.json +7 -7
package/templates/apps/frontend-ssr/package.json +7 -7
package/templates/apps/frontend-ssr-api/package.json +8 -8
package/templates/apps/frontend-static-blog/package.json +6 -6
package/dist/apiBuild-CSM74oEZ.js +0 -2
package/dist/dev-BYfrYwrT.js +0 -2

package/templates/agent-docs/routing.md CHANGED Viewed

@@ -537,29 +537,39 @@ Cost: every request triggers a fresh render. For very high-traffic pages, prefer
 ### Streaming SSR
-By default an `ssr` page renders with `renderToString` — the whole document is built in memory, then sent. The server-side SSR helpers in `@voltro/web/ssr` also expose a **streaming** path, `renderPageToStream`, built on React's `renderToPipeableStream`. It flushes the shell (and each `<Suspense>` boundary as it resolves) instead of buffering the whole page, so the browser gets the first bytes sooner:
-```ts
-import { renderPageToStream } from '@voltro/web/ssr'
-const { stream, meta } = renderPageToStream({
-  descriptor,
-  params,
-  pathname,
-  loaderData,
-  bootstrapModules: ['/assets/client.js'],
-  onShellReady: () => {
-    // meta is resolved synchronously — write <head> before piping the body.
-    res.setHeader('content-type', 'text/html')
-    res.write(`<!doctype html><html><head>${renderMetaToHtml(meta)}</head><body><div id="root">`)
-    stream.pipe(res)
-  },
-  onAllReady: () => res.end('</div></body></html>'),
-  onShellError: (err) => { res.statusCode = 500; res.end('Internal error') },
-})
-```
-`renderPageToStream` takes the same options as `renderPageToHtml` plus the stream callbacks (`onShellReady` / `onAllReady` / `onShellError`) and `bootstrapModules`. Both paths compose the same providers and resolve `meta` synchronously, so the sync string render and the streaming render produce the same tree — the difference is time-to-first-byte and native Suspense streaming. Most apps never call these directly; the `voltro start` pipeline uses them under the hood.
+An `ssr` page is **streamed**, on both boot paths (`voltro dev` and `voltro
+start`). The server sends the `<head>` and the page shell as soon as they are
+rendered, then flushes each `<Suspense>` boundary as its data settles, inside
+the same response.
+For a page with no deferred data this is a time-to-first-byte win and nothing
+else — React's render loop still runs to completion in one pass, so a slow
+render is still a slow render. The lever that matters is `defer()`: it puts a
+real `<Suspense>` boundary in the tree, which is what lets the server return to
+the event loop while a slow value is still pending. See
+[Deferring slow data](/docs/routing/loaders-and-meta#deferring-slow-data-defer--await).
+Measured against a real server rendering a page with one 400ms deferred field:
+first body byte at 7ms, the deferred chunk at 408ms — and a probe firing every
+10ms for the duration of that request was served 30 times with a 3ms median and
+a 7ms maximum. The request does not occupy the event loop while it waits.
+Two consequences worth knowing:
+- **The entry script is emitted as a bootstrap module.** A plain
+  `<script type="module">` is deferred until the document finishes parsing,
+  which on a streamed response is *after the last deferred boundary* — the
+  framework hands the URL to React instead, so it goes out `async` at the end
+  of the shell and hydration starts immediately.
+- **`isr` and `static` are still buffered**, because both produce a stored
+  artefact rather than a response. That is also why `defer()` is an error on
+  those modes.
+Apps do not call the renderer directly. If you are building your own server on
+top of `@voltro/web/ssr`, `renderPageToStream` is the entry point — it takes the
+same options as `renderPageToHtml` plus `bootstrapModules` and the stream
+callbacks, resolves `meta` synchronously so the `<head>` can go out first, and
+returns a Node pipeable stream.
 ## isr (incremental static regeneration)
@@ -615,6 +625,20 @@ The framework reads Postgres logical replication; writes to `posts` or `comments
 Requires `SSR_CACHE=postgres` and a `wal_level=logical` Postgres.
+## spa (client-only, with an optional SSR layout shell)
+```tsx
+export const renderMode = 'spa' as const
+```
+A `spa` page renders entirely in the browser — the page itself is never server-rendered. Reach for it when a page genuinely needs a fresh client render every load (most reactive dashboards) and doesn't need its own first-paint HTML or SEO.
+**If the page's route has a layout, that layout is still server-rendered.** The server renders the layout chain — running its layout loaders — around an empty page slot (`<div data-voltro-page-slot>`), inlines the layout data, and marks the page client-only. The browser hydrates that shell and mounts the page into the slot after hydration. So the shell (nav, sidebar, auth gate) gets an instant first paint while the page stays client-only. The page's own `loader` still runs in the browser.
+Because a layout now runs on the server for spa routes too, a layout used **only** by spa pages must be SSR-safe — no unguarded `window` / `document` in its render or its `loader`. Layouts shared with any `static` / `ssr` / `isr` page already render server-side (and `static` is the default), so they are unaffected. A spa page with **no** layout is a pure client mount, unchanged.
+> **Deferred (follow-ups, not yet shipped):** `voltro build` does not prerender the spa layout shell to a file — `voltro start` renders it on demand. `defer()` / streaming inside a spa-shell layout is unsupported (the shell is buffered). Fast Refresh of the shell path is not yet specialised.
 ## Picking between them
 | You have… | Use |
@@ -653,14 +677,15 @@ A request to `/foo`:
 1. **Pre-rendered HTML exists at `dist/foo/index.html`?** Serve it. (static + isr-already-cached.)
 2. **No pre-render, page is `ssr`?** Render fresh, serve.
 3. **No pre-render, page is `isr`?** Cache lookup → MISS → render → store → serve.
-4. **No pre-render, page is `static`?** Serve the SPA shell — the client router takes over.
+4. **No pre-render, page is `spa` with a layout?** Render the SSR layout shell (layouts + an empty page slot) on demand; the client mounts the page into the slot.
+5. **No pre-render, page is `spa` with no layout, or `static`?** Serve the SPA shell — the client router takes over.
 That last case is how dynamic `static` routes work in dev / when `getStaticPaths` didn't include the URL.
 ## What doesn't work
 - **Switching `renderMode` per request.** It's a static module export — one value per build.
-- **`renderMode: 'ssr'` without `voltro start`.** SSR requires the production server. Dev mode runs everything client-side regardless.
+- **Assuming `ssr` is client-only in dev.** It is not: `voltro dev` runs the same SSR path `voltro start` does, streaming included, so cookie-driven gates and `useServerRequest()` behave the same in both. What dev does NOT do is pre-render `static` pages — those fall through to the SPA shell.
 - **`isr` with `cacheInvalidatesOn` against memory cache.** Memory cache is per-process; CDC events fire across processes. Use `SSR_CACHE=postgres`.
 ## Where to read next
@@ -730,6 +755,130 @@ export default function NotePage(): ReactNode {
 For `static` pages with `getStaticPaths`, the loader runs once per enumerated path.
+### Server-rendered data reaches the first client render
+For `static`, `ssr` and `isr` pages the framework inlines the loader's result
+into the HTML document (a `<script type="application/json"
+id="__voltro_state__">` tag) and the browser adopts it before React hydrates.
+Two consequences worth designing around:
+- **`useLoaderData()` returns real data on the very first client render.** It is
+  not `undefined` until an effect has run, so a page can dereference its loader
+  data directly (`data.title`) without a guard, and a layout renders its
+  loader's value identically on the server and on the client — no hydration
+  mismatch, no flash of fallback content.
+- **The loader does NOT re-run on that initial hydration.** It already ran on
+  the server; running it again in the browser would just re-fetch what the page
+  is already showing. If you need work to happen after mount (refreshing data,
+  a side effect), put it in an effect or use `useSubscription` — do not rely on
+  the loader firing a second time.
+Client-side navigation is unchanged: moving to another route runs that route's
+loaders in the browser as usual. A `spa` page has no server render, so its
+loader runs on the client on first mount.
+Layout loaders are inlined the same way, keyed per layout, so each layout reads
+its OWN data on the first render. The one exception is `voltro build`'s static
+prerender, which runs page loaders but not layout loaders — a `static` page's
+layouts resolve their data on the client after mount. The PAGE keeps its own
+inlined data for the whole of that window, however slow those layout loaders
+are, so the no-guard promise above holds on a prerendered page too: only the
+layout shows its no-data fallback until its loader settles.
+## Deferring slow data: `defer()` + `<Await>`
+A loader blocks the whole response. One slow field therefore costs every byte
+of the page — the user stares at nothing while a report query runs. `defer()`
+splits the loader's result into data that blocks the shell and data that
+**streams in after it**, behind a `<Suspense>` boundary the server flushes as
+soon as the promise settles.
+```tsx
+// src/pages/dashboard.tsx
+import { Await, defer, useLoaderData } from '@voltro/web'
+export const renderMode = 'ssr' as const   // required — see below
+export const loader = async ({ query }: { query?: <T>(tag: string, input?: Record<string, unknown>) => Promise<T> }) => defer(
+  // EAGER — awaited before the shell renders. Keep this fast.
+  { user: await query?.<User>('users.me') },
+  // DEFERRED — NOT awaited. Each becomes a promise on useLoaderData().
+  { report: query!<QuarterlyReport>('reports.quarterly') },
+)
+export default function Dashboard() {
+  const { user, report } = useLoaderData<Awaited<ReturnType<typeof loader>>>()
+  return (
+    <main>
+      <h1>Hello {user?.name}</h1>
+      <Await value={report} fallback={<ReportSkeleton />}>
+        {(report) => <ReportTable rows={report.rows} />}
+      </Await>
+    </main>
+  )
+}
+```
+What the browser sees: the full page with `<ReportSkeleton />` in place,
+immediately — then the real table, injected in a later chunk of the same
+response. No second request, no client-side fetch, no loading spinner driven by
+`useEffect`.
+**Two explicit buckets, not one object.** `defer(eager, deferred)` takes them
+separately rather than treating any promise-valued field as deferred. Deferral
+is then something you wrote down, not something inferred from a value's runtime
+shape — and `useLoaderData()` can type it: eager fields come back as values,
+deferred fields as `Promise<T>`, so the compiler tells you which ones need an
+`<Await>`.
+### `<Await>`
+| Prop | Meaning |
+|---|---|
+| `value` | A deferred field off `useLoaderData()`. |
+| `fallback` | Rendered until the value arrives. **This is what ships in the streamed shell** — keep it cheap and layout-stable. |
+| `children` | `(value) => ReactNode` — rendered with the resolved value. |
+| `errorFallback` | Rendered if the deferred promise rejects. Without it, a rejection renders nothing in that subtree. |
+`<Await>` owns the `<Suspense>` boundary and the hydration handoff for the
+streamed value. Do not hand-roll it with `<Suspense>` + `use()` — the server
+and the client would then have to agree on a wire format that the framework
+otherwise guarantees by construction.
+A rejected deferred value never takes the page down: it renders
+`errorFallback` in place, on the server and on the client alike.
+### `defer()` requires `renderMode: 'ssr'` and full interactivity
+Every other combination is a **hard error at boot or build**, naming the page —
+because each one fails silently otherwise:
+| Combination | Why it is rejected |
+|---|---|
+| `renderMode: 'static'` | The static prerender uses `renderToString`, which does not support Suspense. It emits an errored boundary and a "switched to client rendering" template with no warning — the artefact would ship a permanent fallback. |
+| `renderMode: 'isr'` | ISR caches a completed HTML string. Filling it in would make `defer()` a silent no-op that still reads like it streams. |
+| `interactive: 'none'` | Revealing a streamed boundary needs React's inline reveal scripts, and this mode ships no JS. The fallback would be permanent. |
+| `interactive: 'islands'` | The page's React root never hydrates, so nothing consumes the streamed value. |
+In all four cases the fix is the same: put the value in the eager bucket (or
+return it directly) and let the page render as it did before.
+### Layout loaders can defer too
+A `layout.tsx` loader may return `defer()` under the same rules. Its deferred
+fields are keyed per layout, so a layout reads its own promises via
+`useLoaderData()` exactly as a page does.
+### Client-side navigation
+On a client-side navigation there is no server render, so the loader runs in the
+browser and its deferred fields are ordinary promises. `<Await>` renders the
+fallback and swaps in the content when they settle — the same code, driven by
+React alone.
 ## Loader arguments
 ```ts
@@ -797,6 +946,15 @@ Two rules that fall out of this:
 Under the hood, `ctx.query` is a one-shot `POST /rpc` call (see [Wire protocol](/docs/data/wire-protocol#http-one-shot-rpc-post-rpc)).
+### Authentication in loaders
+Auth is resolved by the **api**, never the web app. Two rules follow:
+- **Strategies live on the `type:'api'` app.** A `type:'web'` app has no auth middleware, so `auth.strategies` in a web `app.config.ts` does nothing. Configure your IdP (`supabaseStrategy`, `workosStrategy`, the built-in password strategy, …) on the api's `app.config.ts`.
+- **`ctx.query` forwards the request's cookie automatically.** A server-side loader's `ctx.query` sends the browser's `Cookie` header on the one-shot `POST /rpc`, so the api resolves the SAME Subject + tenant it would over the WebSocket. You never thread a token through by hand — a logged-in user's cookie-mode session (e.g. `@supabase/ssr`'s `sb-<ref>-auth-token`) is verified by the api's strategies, and tenant-scoped queries return that user's rows during SSR.
+So a cookie-mode Supabase app configures `supabaseStrategy({ cookieName: 'sb-<ref>-auth-token' })` on the **api**; the web loader's `ctx.query` then authenticates for free. See [Supabase Auth](/docs/plugins/auth-supabase).
 ## Errors from loaders
 If the loader throws, the framework:

package/templates/agent-docs/testing.md CHANGED Viewed

@@ -383,6 +383,30 @@ expect(rows.map((r) => r.id)).not.toContain('bobs-ticket')  // the rule, asserte
 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.
+### Filters over SHARED resources
+A filter over rows the user *owns* needs no database — the subject carries the id. A filter over rows *shared with* the user must read a membership table, and `load` is `Effect<Ctx, unknown>` with `R = never`, so it cannot `yield*` a store service. Its only route is [`runAsSystem`](/docs/multi-tenancy/edge-cases), and `makeTestContext` wires its seeded store into that, so this resolves under test exactly as it does at runtime:
+```ts
+const sharedLists: RowFilter<{ listIds: ReadonlyArray<string> }> = {
+  load: (subject) =>
+    Effect.promise(() =>
+      runAsSystem(async (sys) => {
+        const rows = await sys.store.select('listMembers').where('userId', String(subject.id)).all()
+        return { listIds: rows.map((r) => String(r.listId)) }
+      }),
+    ),
+  predicate: (ctx, table) => (table === 'lists' ? inSet('id', ctx.listIds) : undefined),
+}
+const bob = makeTestContext({ subject: bobSubject, store: mockStore(seed), rowFilter: sharedLists })
+expect((await bob.store.select('lists').all()).map((r) => r.id)).not.toContain('alices-list')
+```
+`makeTestContext` registers the **raw** data store + schema registry, so nothing is double-wrapped (`runAsSystem` applies the system-subject mixin wrap itself), and it is the outer store rather than a transactional view — matching production, where a `runAsSystem` block inside a mutation reads outside that mutation's transaction.
+The handle is a process global, and the harness handles that in two layers. Registration is last-wins, so a bare `await runAsSystem(...)` written directly in a test also resolves. On top of that, each context re-points the handle at **its own** store for the span of its `load` and restores the previous value — necessary because two `makeTestContext` calls allocate two separate in-memory stores even from one seed object, so filter resolution must not depend on build order. Nothing leaks across test files (vitest gives each file a fresh module registry). Only the harness registers: an app that registers no handle still gets `runAsSystem: no data store available`, unchanged. If a test in the same file needs that refusal back, call `clearSystemStoreHandle()` from `@voltro/runtime`.
 ## The deterministic mocks
 ### `ctx.clock` — `MockClock`

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

@@ -11,16 +11,16 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@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",
+    "@voltro/ai": "0.9.0",
+    "@voltro/cli": "0.9.0",
+    "@voltro/database": "0.9.0",
+    "@voltro/env": "0.9.0",
+    "@voltro/protocol": "0.9.0",
+    "@voltro/runtime": "0.9.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.7.0",
+    "@voltro/testing": "0.9.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -12,17 +12,17 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@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",
+    "@voltro/cli": "0.9.0",
+    "@voltro/database": "0.9.0",
+    "@voltro/env": "0.9.0",
+    "@voltro/plugin-auth": "0.9.0",
+    "@voltro/protocol": "0.9.0",
+    "@voltro/runtime": "0.9.0",
+    "@voltro/sql-postgres": "0.9.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.7.0",
+    "@voltro/testing": "0.9.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -12,16 +12,16 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@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",
+    "@voltro/cli": "0.9.0",
+    "@voltro/database": "0.9.0",
+    "@voltro/env": "0.9.0",
+    "@voltro/plugin-multitenancy": "0.9.0",
+    "@voltro/protocol": "0.9.0",
+    "@voltro/runtime": "0.9.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.7.0",
+    "@voltro/testing": "0.9.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -12,16 +12,16 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@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",
+    "@voltro/cli": "0.9.0",
+    "@voltro/database": "0.9.0",
+    "@voltro/env": "0.9.0",
+    "@voltro/plugin-deactivation": "0.9.0",
+    "@voltro/protocol": "0.9.0",
+    "@voltro/runtime": "0.9.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.7.0",
+    "@voltro/testing": "0.9.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -12,18 +12,18 @@
   "dependencies": {
     "@react-email/components": "^1.0.12",
     "@react-email/render": "^1.4.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",
+    "@voltro/cli": "0.9.0",
+    "@voltro/database": "0.9.0",
+    "@voltro/env": "0.9.0",
+    "@voltro/plugin-mail": "0.9.0",
+    "@voltro/plugin-multitenancy": "0.9.0",
+    "@voltro/protocol": "0.9.0",
+    "@voltro/runtime": "0.9.0",
     "effect": "^3.21.2",
     "react": "^19.0.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.7.0",
+    "@voltro/testing": "0.9.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -12,18 +12,18 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@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",
+    "@voltro/cli": "0.9.0",
+    "@voltro/database": "0.9.0",
+    "@voltro/env": "0.9.0",
+    "@voltro/plugin-multitenancy": "0.9.0",
+    "@voltro/plugin-storage": "0.9.0",
+    "@voltro/protocol": "0.9.0",
+    "@voltro/runtime": "0.9.0",
+    "@voltro/sql-mysql": "0.9.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.7.0",
+    "@voltro/testing": "0.9.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -10,17 +10,17 @@
     "test": "voltro test"
   },
   "dependencies": {
-    "@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/cli": "0.9.0",
+    "@voltro/database": "0.9.0",
+    "@voltro/env": "0.9.0",
+    "@voltro/plugin-multitenancy": "0.9.0",
+    "@voltro/plugin-storage": "0.9.0",
+    "@voltro/protocol": "0.9.0",
+    "@voltro/runtime": "0.9.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.7.0",
+    "@voltro/testing": "0.9.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -11,17 +11,17 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@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",
+    "@voltro/cli": "0.9.0",
+    "@voltro/database": "0.9.0",
+    "@voltro/env": "0.9.0",
+    "@voltro/plugin-governance": "0.9.0",
+    "@voltro/plugin-multitenancy": "0.9.0",
+    "@voltro/protocol": "0.9.0",
+    "@voltro/runtime": "0.9.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.7.0",
+    "@voltro/testing": "0.9.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

@@ -11,17 +11,17 @@
   "dependencies": {
     "@effect/platform": "^0.96.1",
     "@effect/rpc": "^0.75.1",
-    "@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",
-    "@voltro/workflow": "0.7.0",
+    "@voltro/cli": "0.9.0",
+    "@voltro/database": "0.9.0",
+    "@voltro/env": "0.9.0",
+    "@voltro/plugin-multitenancy": "0.9.0",
+    "@voltro/protocol": "0.9.0",
+    "@voltro/runtime": "0.9.0",
+    "@voltro/workflow": "0.9.0",
     "effect": "^3.21.2"
   },
   "devDependencies": {
-    "@voltro/testing": "0.7.0",
+    "@voltro/testing": "0.9.0",
     "typescript": "^5.7.0",
     "vitest": "^3.0.0"
   }

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

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

package/templates/apps/api-governance/package.json CHANGED Viewed

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

package/templates/apps/api-kv/package.json CHANGED Viewed

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

package/templates/apps/api-moderation/package.json CHANGED Viewed

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