npm - @voltro/cli - Versions diffs - 0.6.0 → 0.8.0 - Mend

@voltro/cli 0.6.0 → 0.8.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 (63) hide show

package/CHANGELOG.md +41 -0
package/bin/voltro.mjs +15 -6
package/dist/apiBuild-CmtI6Ygh.js +2 -0
package/dist/{apiBuild-BxY44VGj.js → apiBuild-OrDkXGFX.js} +21 -20
package/dist/bin.js +2 -2
package/dist/{commands-My_YlUJV.js → commands-DT4PipBz.js} +2489 -2972
package/dist/dev-Ca1jdwnt.js +2 -0
package/dist/dev-Ga65K4jc.js +6492 -0
package/dist/index.js +1 -1
package/dist/inspectMetrics-EK0CcHyu.js +3929 -0
package/dist/{serveCommand-C-XQ89NJ.js → serveCommand-CR5xnYZt.js} +209 -208
package/dist/serveEntry.js +3 -2
package/dist/start-DuyBQxW3.js +977 -0
package/dist/startEntry.d.ts +5 -0
package/dist/startEntry.js +3 -0
package/package.json +17 -17
package/templates/AGENTS.core.md +15 -4
package/templates/AGENTS.md +15 -4
package/templates/agent-docs/authentication.md +111 -13
package/templates/agent-docs/cli.md +94 -6
package/templates/agent-docs/data.md +99 -31
package/templates/agent-docs/database/schema.md +1 -1
package/templates/agent-docs/reference.md +20 -0
package/templates/agent-docs/routing.md +158 -24
package/templates/agent-docs/testing.md +82 -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-Bk4JBt-i.js +0 -2
package/dist/dev-Bjq-nIvH.js +0 -10186
package/dist/dev-D6b74iXI.js +0 -2

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

@@ -630,6 +630,26 @@ Available in:
 Returns `null` on pages without a `loader`. The generic narrows the type.
+Precisely, it returns `LoaderData<T>`. For every ordinary loader that IS `T`. For
+a loader that returned `defer()`, `LoaderData<T>` flattens the two buckets into
+one object — eager fields as values, deferred fields as `Promise<T>` — so the
+compiler tells you which fields have to be rendered through
+[`<Await>`](/docs/routing/loaders-and-meta#deferring-slow-data-defer--await):
+```tsx
+export const loader = async ({ query }) => defer(
+  { user: await query('users.me') },
+  { report: query('reports.quarterly') },
+)
+// user: User            report: Promise<Report>
+const { user, report } = useLoaderData<Awaited<ReturnType<typeof loader>>>()
+```
+If you wrap this hook in your own generic helper, propagate the mapped type
+(`<D,>(): LoaderData<D> => useLoaderData<D>()`) — `LoaderData<D>` is not
+assignable to a bare type parameter `D`.
 See [Loaders & meta](/docs/routing/loaders-and-meta) for the server-side counterpart.
 ## Compositions

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)
@@ -660,7 +670,7 @@ That last case is how dynamic `static` routes work in dev / when `getStaticPaths
 ## 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 +740,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!<Report>('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

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

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