@voltro/cli 0.38.0 → 0.39.1

package/templates/agent-docs/whats-new.md

@@ -1,4 +1,4 @@
-# What's new in 0.38.0
+# What's new in 0.39.1
 
 Read this FIRST when a task touches an area you have not worked in recently.
 It is the cheapest way to notice that the framework grew the thing you were
@@ -7,90 +7,50 @@ workaround for something that shipped two versions ago.
 
 BREAKING entries name a codemod; run `voltro update` to apply it.
 
-### ⚠ BREAKING
-
-- **@voltro/plugin-audit, @voltro/protocol, @voltro/plugin-auth** — An audit row now says when an action was taken through an IMPERSONATED session, on the default settings, and no redactor can take that away.
-
-  `AuditEvent` gained `impersonation`, and the datastore sink a nullable json column of the same name. The mark is lifted out of `subject.metadata` BEFORE the redaction chain runs, so `redactSubject` — including a custom function that erases the subject wholesale — never gets a say.
-
-  **The defect it closes.** `@voltro/plugin-auth` mints the mark into `subject.metadata`, and `auditPlugin`'s default `redactSubject: 'metadata'` replaces that whole bag. That default is right: the bag is where a per-user provider credential lands, and an audit table is the last place a live PAT should be. The consequence was that on defaults an impersonated action was recorded indistinguishably from the user's own — the one distinction an audit trail exists to make. The documented mitigation (`redactSubject: impersonationAuditRedactor()`) worked and was opt-in, and an audit property that depends on somebody wiring it is not a property.
-
-  The alternative fix — a keep-these-keys option on `redactSubject` — was rejected for the same reason: it leaves the default wrong, and "who really did this" is not the app's metadata to configure away. It is a property of the event, so it is now a field of the event.
-
-  **BREAKING: `IMPERSONATION_METADATA_KEY` moved from `@voltro/plugin-auth` to `@voltro/protocol`.** It names the one reserved key in `Subject.metadata`, and `Subject` is protocol's type. Two packages need it — plugin-auth writes the mark, plugin-audit reads it — and a plugin must not depend on another plugin, so spelling the string in both would have made it a second definition no guard is watching. Everything else stays: plugin-auth still exports `impersonationOf`, `isImpersonated`, `ImpersonationMark` and `impersonationAuditRedactor`. The codemod repoints the import, preserving an alias and the type-only form.
-
-  The redactor keeps working and is no longer load-bearing. Set `redactSubject: 'none'` or a custom function for your own reasons; the impersonation mark is recorded either way.
-
-  No migration is needed for the new column — a `_voltro_*` change rides the declarative differ on `voltro db apply` and on a `voltro dev` boot, on every dialect.
-- **@voltro/cli** — A `*.startup.ts` that fails now refuses the boot. It used to warn and let the server come up.
-
-  Measured, on a real `voltro dev` against postgres, while building the row-filter integration test in this same release. A startup reached for `ctx.store.select(...)` — a builder that lives on the request-scoped `MutationStore`, not on the `DataStore` a startup receives — and threw on its first line. The boot printed:
-
-  ```
-  warn   startup: function rejected
-  info   startup: registered      <- next line, same file
-  ```
-
-  and then served every request with no row filter registered. Two lines contradicting each other, the second asserting exactly the thing that had just failed, and an app that looked healthy while its access control was absent.
+### Fixed
 
-  **The rule this overturns was right when it was written.** The header of `startupRunner.ts` read "Errors are logged but never fatal — a failing startup MUST NOT block the rest of the app", and for the startups it was written for — an SSE bridge, a sync loop, a metric aggregator — that is the correct call. It stopped being right when a startup became the documented seam for REGISTRATION: `setRowFilter` is installed from one.
+- **@voltro/runtime, @voltro/cli** — An app-registered tuple source is no longer replaced by the framework default.
 
-  The runner cannot tell a registration from a background loop, and the two failures are not symmetric. "The app refuses to boot" is fixed in seconds and is visible to everyone; "the app serves without its access control" is visible to nobody. So the default is the recoverable one, and an app that genuinely wants best-effort writes the `try`/`catch` inside its own startup — one line, at the site where somebody decided the failure was acceptable, where a reviewer can see it. Deliberately not a flag: a flag moves that decision away from the startup it applies to and makes it one setting for all of them.
+  Both boot paths carried this comment, verbatim:
 
-  **Two sibling silences went with it**, because fixing only the rejection would have left two more ways to reach the identical state — the per-seam shape this repo keeps paying for. A startup file that cannot be imported, and one with no default-exported function, used to warn and skip. Both refuse now. The second matters more than it sounds: the convention is a DEFAULT-exported function, a named export is discovered and never runs, and that is indistinguishable from a startup that ran and did nothing.
+  > An app whose relationships live in its own tables overrides with > `setTupleSource`.
 
-  **And the 2-second race is gone, which is the half that made the rest reliable.** The old code did not wait for a startup to settle — it raced it against 2000 ms and let the boot win. A startup slower than that was reported as fine, so a rejection arriving afterwards had nothing left to refuse. The runner now waits for the startup to SETTLE, so every failure is catchable however slow it is.
+  and then called `setTupleSource(default)` **unconditionally**. That call runs AFTER the app's startups — `runBootLifecycle` at `dev.ts:3910` and `serveCommand.ts:869`, against the registration at `dev.ts:4065` and `serveApi.ts:937` — and `setTupleSource` is last-write-wins. So the framework won every time: an app registering its own source in a `*.startup.tsx`, which is what the docs tell it to do, had it silently replaced.
 
-  That race existed to protect one shape: a startup that never returns because it holds a fiber until shutdown. Counted before changing it, that shape appears in ZERO of the four startups this framework ships — `warm.startup.tsx` (twice), `searchBackfill.startup.tsx` and the memory fixture's all return. So the race protected the shape we discourage and penalised the shape we teach, and the penalised one includes `searchBackfill`, our own example, which awaits a full-table query plus an index backfill and is the likeliest thing in the box to exceed two seconds. Slow AND failing put a consumer back in exactly the silent state this release removes.
+  The consequence is not subtle. Every relationship guard would then be answered from `_voltro_rebac_tuples` — empty, for exactly the app that keeps its relations in its own tables — so every guard DENIES, fail-closed, with a `no tuple source` warning that never fires because a source *is* registered: the wrong one.
 
-  **So a startup that never returns now refuses the boot too**, after `VOLTRO_STARTUP_TIMEOUT_MS` (60s default), with a message naming the file and showing the `onShutdown` shape to use instead. That makes a previously-documented capability illegal — "a fiber that resolves only on shutdown" — and it is the deliberate half of this change rather than a side effect. A startup that is merely SLOW is unaffected: it is waited for and registers when it finishes.
+  The comment was not wrong about the design; it described the design while the code removed it. Same shape as the `DORMANCY_WAKEUP_TENANT` scar — equal by value at both call sites, so nothing could fail, and the comment was the only place the intent survived.
 
-  `startup: registered` is written only when the function actually returned. The old code printed it for a failed startup and for one still running.
+  `registerDefaultTupleSource` fills the gap only when nobody else did, and returns whether it acted so the boot can say which source is live instead of leaving an operator to guess. `setTupleSource` itself is unchanged: an app calling it twice still gets the second one, because narrowing that would trade one silent surprise for another.
 
-  Verified against a real process in every direction, not only in units: the reintroduced defect exits 1 and never listens; a never-returning startup exits 1 and never listens; a slow-but-successful one still registers; and the healthy fixture boots and serves all eight row-filter assertions. `startupRunner.test.ts` is new — there were no tests on this runner at all, which is part of why the contradiction survived.
+  Found while re-checking a consumer's claim that a different item was still open. It was not — but it sits beside this, and this is the one that would have bitten them. Pinned in both directions: a unit test for the registrar, and a source guard asserting neither boot path installs `loadResourceTuples` through `setTupleSource` again. Red-verified by restoring the original line.
+- **@voltro/cli** — `voltro doctor` no longer reports "scope vocabulary: none found" when it could not read the config at all.
 
-  **`voltro update` carries you across this** — codemod `0.38.0/02_startup-failure-refuses-boot`.
+  A consumer HAD configured `doctor.scopeVocabulary` and still read `none found`. The cause was not their vocabulary: `app.config.ts` could not be imported outside their pod — an auth strategy demands its secret while the config is evaluated — so the vocabulary was never read. Inside the pod the message disappears and the rule runs.
 
-### Fixed
+  "You have no vocabulary" and "I could not look" are different states, and only the first is a statement about their app. This section already made exactly that distinction one member earlier — its own comment reads **DORMANT AND CLEAN MUST NOT PRINT THE SAME** — and then collapsed the third.
 
-- **@voltro/cli** — A table declared through `databaseHandle({ … })` but not exported as a top-level table is now DISCOVERED — so its mixins apply.
+  The signal existed and was not connected. `offlineManifest` deliberately survives an unimportable config (a doctor run must not die on one), so the empty vocabulary arrived looking like a real absence, while the same failure was reported a hundred lines earlier under plugin tables. The consumer read the section about scopes and searched at the wrong end — which is the correct way to read a report.
 
-  Discovery kept whatever `isTable()` accepted out of a schema module's `Object.values`, which only ever sees tables the file exports DIRECTLY. A schema that builds its tables programmatically exports the builder's result:
+  The rule now probes importability before claiming an absence, and says so:
 
-  ```ts
-  export const blogEntities = contentTypeToEntities(blogPost)   // { draft, published }
-  export const database = databaseHandle({ …, blogPostDrafts: blogEntities.draft })
   ```
-
-  `isTable({ draft, published })` is false, so those tables never entered the schema registry — while `databaseHandle` had registered them for by-name lookup perfectly well.
-
-  **Two registries with different populations, read by different things.** `getTable()` found the table, so insert validation knew `tenantId` was NOT NULL. The schema registry is what drives the mixins, so nothing stamped it. Measured against a real `voltro dev` boot of the scaffolded `api-cms` template, over real RPC:
-
+  •  scope vocabulary: NOT EVALUATED — `app.config.ts` could not be imported.
+     This is not a statement about your scopes: the rule never got to read them.
+     … The same import failure is reported above for plugin tables; both sections
+     have this one cause.
   ```
-  TableValidationFailed: { "table": "blogPost_drafts", "summary":
-    "missing required column 'tenantId' — NOT NULL with no default and not auto-stamped" }
-  ```
-
-  Every `content.saveDraft` in that template, since it shipped. Its own unit test could not see it, because the test builds its schema registry by hand — the one step the running app does not perform.
-
-  **The write failing was the lucky half.** Reads do not announce themselves: `makeQueryFinalizer` AND-merges `tenantId` from this same registry, so a table missing from it is a table nobody scopes. The visible symptom was a broken mutation; the invisible one was tenant isolation quietly not applied to those tables.
-
-  The fix takes the by-name registry's DELTA across each schema module's import, so a handle-declared table is attributed to the file that declared it — rather than reading the whole global registry, which by then also holds framework tables that this set deliberately excludes. It lives in `loadDiscovered`, which `voltro dev` and `voltro serve` both call, so the two cannot disagree about it.
-
-  No app change is needed; the idiomatic `databaseHandle` declaration now works as its documentation always said.
-- **@voltro/database, @voltro/cli** — A migration that fails because `DB_SCHEMA` names a schema that does not exist now says so.
 
-  Postgres answers `3F000 no schema has been selected to create in`, and the only thing that puts a non-default schema on the connection's `search_path` here is `DB_SCHEMA`. The error mentions neither the variable nor the schema, so the FIRST `CREATE TABLE` of the boot fails with a message about SQL and the reader goes looking at the DDL — for a typo in an environment variable.
+  The dormant case keeps its own wording, so a quiet run on an app that genuinely publishes no vocabulary is not relabelled as a broken config.
 
-  Found while building the row-filter integration test below: the boot aborted, the log named `_voltro_migrations` and a postgres routine, and nothing in it pointed at the one line of configuration that caused it. Same shape as a 403 that says nothing about `VOLTRO_INSPECT_TOKEN`, fixed in the same release.
+### Internal (no consumer-facing effect)
 
-  The remedy also states what the framework will NOT do: Voltro creates tables, never the schema itself. That is a namespace decision, and inventing one from a typo puts a migration somewhere nobody is looking.
+- **@voltro/cache, @voltro/kv** — The RESP TTL tests in `@voltro/cache` and `@voltro/kv` stopped measuring the machine. Test-only; no product code changed.
 
-  `remedyFor` is deliberately a one-entry map and the test asserts the empty case as well as the full one. A remedy is worth printing only where the mapping from driver code to cause is exact; a list of maybes is how a reader learns to skip the section.
+  Both wrote a key with `ttlMs: 150`, asserted it was still there, then slept 300 ms and asserted it was gone. The second half is fine — waiting LONGER only strengthens "it expired". The first half was a race: the write and the read are two round-trips, so on a loaded runner the key legitimately expired before the liveness assertion, and the test reported a defect that was not there. It failed exactly that way on a release gate, in the keydb engine, while passing locally with 24/24 green.
 
-  **Alongside it: the row filter is now driven under `voltro dev` against a real postgres.** Both defects that reached consumers lived between layers that were each individually covered — a module-local `let` that split per instance, then a query producer that built its context from an unscoped request — and three consumer documents carried "we have not run this against a real database" as an honest caveat. `rowFilterDevPostgres.integration.test.ts` boots the fixture twice: handlers with no predicate of their own, a filter registered from a `*.startup.tsx`, and a NEGATIVE CONTROL run with the registration skipped that asserts the same queries return BOTH owners. Without the control, "the caller saw one owner" is equally consistent with a database that only ever held one.
-- **@voltro/cli** — A shard that cannot be released no longer spins a fiber at full speed. Upstream `@effect/cluster` releases shards through `Effect.eventually` — retry until success, zero delay, logged at DEBUG — so a shard whose storage was unreachable retried as fast as the event loop allowed, in the one place nobody watches.
+  Now: a 2 s window, so liveness has real headroom rather than 150 ms of it, and the expiry is awaited as a CONDITION (`awaitGone` polls) rather than as a duration. Idle machines finish in about the TTL; loaded ones take as long as they need; a key that never expires still fails, because the ceiling is a failure mode and not a timing assumption.
 
-  Our patch replaces it with `Effect.retry(Schedule.exponential(100) ∪ Schedule.spaced(5000))`. `union` takes the MINIMUM of the two delays, so the 5s spacing caps the backoff instead of compounding with it, and both schedules recur forever — attempts stay unbounded, which is what the original intended. The persistence was always correct; only the missing delay was the defect.
+  Fixed in BOTH packages in one change. The two files carried the identical construction, and this repo's standing lesson is that a fix landing in one copy of a duplicated shape leaves the other one broken — `@voltro/kv` had not failed yet, which is a statement about luck rather than about the test.
 
-  This entry exists because the change would otherwise have shipped undocumented. The patch lives in `packages/cli/templates/patches/`, and the changelog gate requires an entry for `packages/*/src` — so nothing would have demanded one, even though the file is installed into every user project that runs cluster. A rule that cannot see a path is not the same as a path with nothing on it.
+  `@voltro/kv`'s header also pointed at `../cache/test/docker-compose.yml` for bringing the engines up. That path does not exist; there is one compose file, at the repo root.

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

@@ -12,16 +12,16 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/ai": "0.38.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
+    "@voltro/ai": "0.39.1",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -13,17 +13,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/plugin-auth": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
-    "@voltro/sql-postgres": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/plugin-auth": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
+    "@voltro/sql-postgres": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -16,16 +16,16 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/plugin-multitenancy": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/plugin-multitenancy": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -13,16 +13,16 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/plugin-deactivation": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/plugin-deactivation": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -13,18 +13,18 @@
   "dependencies": {
     "@react-email/components": "^1.0.12",
     "@react-email/render": "^1.4.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/plugin-mail": "0.38.0",
-    "@voltro/plugin-multitenancy": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/plugin-mail": "0.39.1",
+    "@voltro/plugin-multitenancy": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
     "effect": "^3.22.0",
     "react": "^19.0.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -13,18 +13,18 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/plugin-multitenancy": "0.38.0",
-    "@voltro/plugin-storage": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
-    "@voltro/sql-mysql": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/plugin-multitenancy": "0.39.1",
+    "@voltro/plugin-storage": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
+    "@voltro/sql-mysql": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -13,17 +13,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/plugin-multitenancy": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
-    "@voltro/sql-sqlite": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/plugin-multitenancy": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
+    "@voltro/sql-sqlite": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -11,17 +11,17 @@
     "test": "voltro test"
   },
   "dependencies": {
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/plugin-multitenancy": "0.38.0",
-    "@voltro/plugin-storage": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/plugin-multitenancy": "0.39.1",
+    "@voltro/plugin-storage": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -13,19 +13,19 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/cms": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/plugin-auth": "0.38.0",
-    "@voltro/plugin-multitenancy": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
-    "@voltro/sql-postgres": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/cms": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/plugin-auth": "0.39.1",
+    "@voltro/plugin-multitenancy": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
+    "@voltro/sql-postgres": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -13,17 +13,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/local-first": "0.38.0",
-    "@voltro/plugin-multitenancy": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/local-first": "0.39.1",
+    "@voltro/plugin-multitenancy": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -12,17 +12,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/plugin-governance": "0.38.0",
-    "@voltro/plugin-multitenancy": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/plugin-governance": "0.39.1",
+    "@voltro/plugin-multitenancy": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -12,17 +12,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/plugin-multitenancy": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
-    "@voltro/workflow": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/plugin-multitenancy": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
+    "@voltro/workflow": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

package/templates/apps/api-durable/startup/warm.startup.tsx

@@ -6,8 +6,22 @@
 // websocket, start a background interval, register a process singleton —
 // and register a teardown via `onShutdown`.
 //
-// A throw here does NOT block boot (it's logged; the rpc surface stays
-// up). Distinct from `*.seed.ts` (runs once and RETURNS) and `*.cron.tsx`
+// A throw here REFUSES the boot, naming this file and the cause. A startup
+// is where an app arms things the request path depends on, and "served
+// without them" is the failure nobody sees — so the default is the
+// recoverable one. If a failure is genuinely acceptable here (a cache warm
+// is the usual case), catch it INSIDE this function, so the decision sits
+// where somebody made it:
+//
+//     try { await warm(store) }
+//     catch (err) { log.warn('cache warm failed; serving cold', {}, err) }
+//
+// The function must also RETURN. Start the work, hand back teardown via
+// `onShutdown`, return — one that never returns refuses the boot after
+// `VOLTRO_STARTUP_TIMEOUT_MS` (default 60s). A slow but successful startup
+// is simply awaited.
+//
+// Distinct from `*.seed.ts` (runs once and RETURNS) and `*.cron.tsx`
 // (periodic) — a startup HOLDS a resource for the process lifetime.
 //
 // NOTE: `StartupContext` lives on the `@voltro/cli/startup` subpath (the

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

@@ -13,18 +13,18 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/plugin-flags": "0.38.0",
-    "@voltro/plugin-multitenancy": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
-    "@voltro/sql-postgres": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/plugin-flags": "0.39.1",
+    "@voltro/plugin-multitenancy": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
+    "@voltro/sql-postgres": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -13,17 +13,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/plugin-audit": "0.38.0",
-    "@voltro/plugin-governance": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/plugin-audit": "0.39.1",
+    "@voltro/plugin-governance": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

@@ -12,17 +12,17 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/cli": "0.38.0",
-    "@voltro/database": "0.38.0",
-    "@voltro/env": "0.38.0",
-    "@voltro/kv": "0.38.0",
-    "@voltro/plugin-multitenancy": "0.38.0",
-    "@voltro/protocol": "0.38.0",
-    "@voltro/runtime": "0.38.0",
+    "@voltro/cli": "0.39.1",
+    "@voltro/database": "0.39.1",
+    "@voltro/env": "0.39.1",
+    "@voltro/kv": "0.39.1",
+    "@voltro/plugin-multitenancy": "0.39.1",
+    "@voltro/protocol": "0.39.1",
+    "@voltro/runtime": "0.39.1",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.38.0",
+    "@voltro/testing": "0.39.1",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"