@voltro/cli 0.59.0 → 0.60.0

package/dist/startEntry.js

@@ -1,3 +1,3 @@
 import { t as e } from "./loadEnv-D9nEOClM.js";
-import { t } from "./start-DNtIlBcn.js";
+import { t } from "./start-CcdPRG8L.js";
 export { e as loadDotEnv, t as runStartCommand };

package/dist/{updateCommand-Bw3mCUDT.js → updateCommand-D9avpQFT.js}

@@ -1,4 +1,4 @@
-import { n as e, r as t, t as n } from "./codemodRunner-kNnh1I7_.js";
+import { n as e, r as t, t as n } from "./codemodRunner-ClUqkhvR.js";
 import { basename as r, dirname as i, join as a, relative as o, resolve as s } from "node:path";
 import { existsSync as c, readFileSync as l, readdirSync as u, statSync as d, writeFileSync as f } from "node:fs";
 import { totalmem as p } from "node:os";

package/dist/updateCommand-QMOirvXC.js

@@ -0,0 +1,2 @@
+import { m as e, p as t } from "./updateCommand-D9avpQFT.js";
+export { t as runApplyCodemods, e as runUpdateCommand };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/cli",
-  "version": "0.59.0",
+  "version": "0.60.0",
   "description": "The `voltro` CLI — dev server, codegen, migrations, project scaffolding, agent-docs seeding, and production serve.",
   "keywords": [
     "voltro",
@@ -892,6 +892,12 @@
         "title": "UiStrings gained a required `connectAccount` section",
         "kind": "manual"
       },
+      {
+        "version": "0.60.0",
+        "id": "0.60.0/01_declared_failures_are_not_incidents",
+        "title": "Sentry no longer reports declared failures by default",
+        "kind": "manual"
+      },
       {
         "version": "0.7.0",
         "id": "0.7.0/01_row-filter-load-failure",
@@ -938,24 +944,24 @@
     "@effect/platform-node": "^0.108.0",
     "@effect/sql": "^0.52.0",
     "@effect/workflow": "^0.19.0",
-    "@voltro/ai": "0.59.0",
-    "@voltro/cache": "0.59.0",
-    "@voltro/client": "0.59.0",
-    "@voltro/content": "0.59.0",
-    "@voltro/data-transfer": "0.59.0",
-    "@voltro/database": "0.59.0",
-    "@voltro/env": "0.59.0",
-    "@voltro/kv": "0.59.0",
-    "@voltro/logger": "0.59.0",
-    "@voltro/plugin-auth": "0.59.0",
-    "@voltro/plugin-broadcast": "0.59.0",
-    "@voltro/plugin-mail": "0.59.0",
-    "@voltro/plugin-storage": "0.59.0",
-    "@voltro/plugin-webhooks": "0.59.0",
-    "@voltro/protocol": "0.59.0",
-    "@voltro/runtime": "0.59.0",
-    "@voltro/serverless": "0.59.0",
-    "@voltro/workflow": "0.59.0",
+    "@voltro/ai": "0.60.0",
+    "@voltro/cache": "0.60.0",
+    "@voltro/client": "0.60.0",
+    "@voltro/content": "0.60.0",
+    "@voltro/data-transfer": "0.60.0",
+    "@voltro/database": "0.60.0",
+    "@voltro/env": "0.60.0",
+    "@voltro/kv": "0.60.0",
+    "@voltro/logger": "0.60.0",
+    "@voltro/plugin-auth": "0.60.0",
+    "@voltro/plugin-broadcast": "0.60.0",
+    "@voltro/plugin-mail": "0.60.0",
+    "@voltro/plugin-storage": "0.60.0",
+    "@voltro/plugin-webhooks": "0.60.0",
+    "@voltro/protocol": "0.60.0",
+    "@voltro/runtime": "0.60.0",
+    "@voltro/serverless": "0.60.0",
+    "@voltro/workflow": "0.60.0",
     "chokidar": "^5.0.0",
     "ioredis": "^5.11.1",
     "tinyglobby": "^0.2.17",

package/templates/AGENTS.md

@@ -749,7 +749,7 @@ each plugin's own README.
 
 | Topic | Open | Summary |
 |---|---|---|
-| **What's new in 0.59.0** | `node_modules/@voltro/cli/templates/agent-docs/whats-new.md` | Everything that changed in this version. Read it before hand-rolling something the framework may now ship. |
+| **What's new in 0.60.0** | `node_modules/@voltro/cli/templates/agent-docs/whats-new.md` | Everything that changed in this version. Read it before hand-rolling something the framework may now ship. |
 | AI | `node_modules/@voltro/cli/templates/agent-docs/ai.md` | How Voltro treats AI — agents, tools, streaming, RAG — all primitives over the same WebSocket as the rest of the framework. |
 | Authentication | `node_modules/@voltro/cli/templates/agent-docs/authentication.md` | How @voltro/plugin-auth wires password + session-cookie auth across api + web, plus the pluggable identity-strategy protocol. |
 | Caching | `node_modules/@voltro/cli/templates/agent-docs/caching.md` | Voltro's caching layer (@voltro/cache) — an always-on memory default, swappable Redis-compatible backends, a low-level wrap primitive, and automatic query-result invalidation. |

package/templates/agent-docs/_index.md

@@ -9,7 +9,7 @@ each plugin's own README.
 
 | Topic | Open | Summary |
 |---|---|---|
-| **What's new in 0.59.0** | `node_modules/@voltro/cli/templates/agent-docs/whats-new.md` | Everything that changed in this version. Read it before hand-rolling something the framework may now ship. |
+| **What's new in 0.60.0** | `node_modules/@voltro/cli/templates/agent-docs/whats-new.md` | Everything that changed in this version. Read it before hand-rolling something the framework may now ship. |
 | AI | `node_modules/@voltro/cli/templates/agent-docs/ai.md` | How Voltro treats AI — agents, tools, streaming, RAG — all primitives over the same WebSocket as the rest of the framework. |
 | Authentication | `node_modules/@voltro/cli/templates/agent-docs/authentication.md` | How @voltro/plugin-auth wires password + session-cookie auth across api + web, plus the pluggable identity-strategy protocol. |
 | Caching | `node_modules/@voltro/cli/templates/agent-docs/caching.md` | Voltro's caching layer (@voltro/cache) — an always-on memory default, swappable Redis-compatible backends, a low-level wrap primitive, and automatic query-result invalidation. |

package/templates/agent-docs/plugins/sentry.md

@@ -243,11 +243,97 @@ Two details worth knowing before the first upload:
   store, and it fails with `SSL peer certificate … unable to get local issuer
   certificate`. Add `ca-certificates` to the build stage.
 
-**What we have not measured:** how a given Sentry project resolves the uploaded
-artifacts end to end. `sentry-cli sourcemaps upload` matches on debug IDs it
-injects into the emitted JS, and the URL prefix is the older release-artifact
-fallback — which is why the prefix is set correctly per directory rather than
-left to one default, and why this paragraph is here instead of a claim.
+**Debug ids are what make a server frame resolve, and they need their own
+step.** `sentry-cli sourcemaps upload` does **not** write them — `inject` is a
+separate subcommand, and `upload` only uses ids that are already there, falling
+back to matching on the artifact NAME when they are not.
+
+That fallback cannot work for a server bundle: the artifact is named from
+`--url-prefix` (`~/chunk-ABC.js`) while the frame carries the absolute path the
+node process loaded (`/workspace/…/serveBundle/chunk-ABC.js`), and nothing
+rewrites either side. Measured downstream before this was fixed: 4300 artifacts
+uploaded, the release finalised, every frame still minified — nothing red, which
+is the failure this page's own warning describes.
+
+`voltro build` runs `inject` first now, so the ids are in both the shipped JS and
+the map before anything is uploaded. The URL prefix stays as the fallback for the
+browser bundle, whose frames really are URLs under `~/assets`.
+
+## The web server is a SECOND process — and it needs the DSN too
+
+A framework app runs two server processes. `voltro serve` is the api, where
+`sentryPlugin()` initialises the SDK through the plugin lifecycle. `voltro start`
+is the **web server** — SSR, loaders, ISR, the revalidation legs — and it has no
+plugin lifecycle at all.
+
+It now initialises Sentry itself when `SENTRY_DSN` is set:
+
+```sh
+SENTRY_DSN=… SENTRY_ENVIRONMENT=production SENTRY_RELEASE=1.4.2 voltro start
+```
+
+```
+{"level":"info","msg":"sentry active","environment":"production","release":"1.4.2","traces":false,"profiling":false,"process":"web"}
+```
+
+Same line and same field names as the api half, from the same function — one
+vocabulary across both pods, plus `process` so a collector can tell them apart.
+
+**Why this was a hole rather than a missing log line.** An SSR shell throw is
+caught, logged, and answered with a 500. No browser ever renders it, so the
+client-side ErrorBoundary bridge below cannot see it either: the error existed
+only in the pod's stdout. Both ends of the integration worked and the middle was
+dark.
+
+Three things to know:
+
+- **`@voltro/plugin-sentry` must be installed in the WEB app**, not only the api
+  — the web server resolves the shared init from it. With a DSN set and the
+  package missing, the boot says so and names the command; it does not fail.
+- **`traces` is `false` here, deliberately.** The api half contributes a span
+  processor to the framework's tracer. The web server has no tracer, so
+  initialising with tracing on would put `traces: true` in a boot line while
+  nothing produces a span.
+- **No DSN is silent.** On the api side `sentryPlugin()` in your config is a
+  declaration, so an inert one is worth a warning. Here there is no declaration
+  to contradict, and a line about an integration you did not ask for is noise.
+
+**Re-run `voltro build` after upgrading.** Production `voltro start` loads the
+app's precompiled start bundle, so the web half picks this up when that bundle
+is rebuilt — not from the framework version alone.
+
+## What reaches Sentry — a declared failure does not
+
+A procedure's `error:` union is a **contract**. Somebody wrote the outcome down,
+the client gets it typed and branches on it, and it describes a state of the
+world: `AccessDeniedError` on a team you are not a member of is the system
+working. A **defect** is the opposite — nobody foresaw it. Sentry is built for
+the second.
+
+So a cause that carries only declared failures is **not** reported:
+
+```ts
+sentryPlugin()                              // captureFailures: false — the default
+sentryPlugin({ captureFailures: true })     // report them again
+sentryPlugin({ captureFailures: (e) => (e as { _tag?: string })._tag === 'PaymentDeclined' })
+```
+
+- **Defects are always reported**, including a defect that arrived beside a
+  failure — the rule is failures-*only*, so one cannot hide the other.
+- **Both halves take the option.** A rejected call is an rpc error on the client
+  too, so `initSentryBrowser({ captureFailures })` applies the same rule to
+  `rpc.*` events that carry a `_tag`. Set them together, or the api goes quiet
+  while the browser keeps filing the same rejection.
+- **Route render failures and `reportClientError` are never filtered.** Nobody
+  declared those, which is the whole distinction.
+- **The boot line names it** — `sentry active … captureFailures=false` — because
+  a default the framework picks for you is one nobody finds again.
+
+Why the default is off: an issue list that fills with the expected is one nobody
+reads. Every invalid form value, every click on a resource without access and
+every call on a deleted row was a `level: error` issue. If Sentry is where you
+see errors at all, `captureFailures: true` is the one-line answer and it is a
+reasonable choice.
 
 ## Catching errors — what's automatic, what's manual
 
@@ -257,7 +343,8 @@ Once the two halves are wired, most errors are captured **with no per-call code*
 |---|---|---|
 | rpc handler throw (mutation/query/action) | ✅ auto | server interceptor → Sentry, trace-correlated + breadcrumbs |
 | Unhandled browser error / promise rejection | ✅ auto | `@sentry/react` global handlers (after `initSentryBrowser`) |
-| **React render error** (any page, incl. catch-all `[...slug]`, `error.tsx` boundary) | ✅ auto | the framework's route ErrorBoundary publishes to a client-error bus → the Sentry web bridge captures it. React swallows boundary-caught errors before `window.onerror`, so this bridge is what makes them reach Sentry — tagged with the route + component stack. |
+| **React render error, in the BROWSER** (any page, incl. catch-all `[...slug]`, `error.tsx` boundary) | ✅ auto | the framework's route ErrorBoundary publishes to a client-error bus → the Sentry web bridge captures it. React swallows boundary-caught errors before `window.onerror`, so this bridge is what makes them reach Sentry — tagged with the route + component stack. |
+| **React render error, during SSR** (shell throw, loader throw, PPR/SWR refresh) | ✅ auto, from the WEB server | a different process and a different path: the render never reaches a browser, so the row above cannot cover it. Captured by the web server's own Sentry (see the section above), tagged `voltro.process=web` and `voltro.stage`. Needs `SENTRY_DSN` on the **web** deployment. |
 | **Loader failure** (page/layout `loader` reject) | ✅ auto | same route bus path |
 | Manual try/catch (event handler, async effect, anywhere) | ✋ one call | `reportClientError(error, context?)` |
 | **Every other server primitive** — REST route (`defineRestRoute`), aggregate, subscriber, schedule, workflow, webhook, startup | ✅ auto | each primitive's error path publishes to the framework's server-error bus → the plugin captures it, tagged `voltro.errorSource` + `voltro.name` (+ traceId for workflows) |

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

@@ -1,4 +1,4 @@
-# What's new in 0.59.0
+# What's new in 0.60.0
 
 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
@@ -9,51 +9,54 @@ BREAKING entries name a codemod; run `voltro update` to apply it.
 
 ### ⚠ BREAKING
 
-- **@voltro/cli** — **`web.sourcemaps` moved to the top level of `app.config.ts`, and now covers every bundle the build minifies.**
+- **@voltro/plugin-sentry** — **A declared failure no longer reaches Sentry by default, and the source-map upload now injects debug ids.** Two separate defects, both found by the same deployment on its first day of real server-side events.
 
-  It reached exactly one of them before: the vite CLIENT build. `voltro build` minifies four — the browser bundle, the SSR bundle, the `voltro start` bundle, and for an api app the precompiled entry plus the serve bundle that `voltro serve` actually runs — and none of the other three had a `sourcemap` option or a config path that could ask for one. `keepNames` rescues the identifiers that are read as strings and nothing else, so a frame out of the artefact production runs read `at Qo (serveEntry.js:236:76405)`.
+  **1. The contract was being reported as an incident.** The rpc interceptor skipped only clean interrupts; everything else went to `captureException`. So a failure declared in a procedure's `error:` union — the thing the client gets typed and branches on — arrived as `level: error`, `handled: yes`. The first server-side issue a deployment ever received was a person clicking a team they are not a member of.
 
-  The docs closed that hole with a sentence instead of a field: *server stack traces are un-minified already*. The built file says otherwise, and the server half is where it costs most — a schedule, a workflow step, a subscriber or a REST route has no browser caller whose frame could stand in for it.
+  Effect separates a failure from a defect, this framework leans on that split deliberately (a store refusal was made typed so an app could branch on it; an unlookupable conflict key was deliberately left a defect, because it is a broken call rather than a condition in the data), and a descriptor carries it in `error:`. Reporting both as an incident discarded that one layer up.
 
-  A second field (`api.sourcemaps`) would have made the same mistake twice. "Do I want resolvable frames from this app" has one answer; how many bundles the build happens to emit is not the caller's business.
+  `shouldCapture` now skips a cause that is failures-ONLY. A defect is reported as before, including a defect that travelled beside a failure — the rule is failures-only rather than "any failure present" precisely so one cannot hide the other. `captureFailures: true` restores the old behaviour; a predicate keeps the ones that are signal.
 
-  Three details that come with it:
+  **The browser half moved with it**, or the option would have been half-wired: a rejected call is an rpc error on the client too, published to the client error bus and captured by the browser bridge. `initSentryBrowser` takes the same option and applies it to `rpc.*` events carrying a `_tag`. Route render failures and `reportClientError` calls are never filtered — nobody declared those.
 
-  - **The old spelling is REFUSED, not ignored.** A moved option that is silently dropped goes green, stops emitting maps, and is found by someone reading an unresolvable frame months later. - **Each output directory uploads under the prefix that matches how its files are named** — `~/assets` for the browser bundle, `~/` for the bundles a node process loaded. One prefix across both is wrong for one of them. - **The upload and sweep run at every exit of the build**, not after the client bundle. Sweeping there would have deleted the client maps before the server ones existed, leaving those neither uploaded nor deleted.
+  **2. `sentry-cli sourcemaps upload` does NOT write debug ids.** `inject` is a separate subcommand; `upload` only uses ids that are already present, and falls back to matching on the artifact NAME when they are not. That fallback cannot work for a server bundle: the artifact is named from `--url-prefix` (`~/chunk- ABC.js`) while the frame carries the absolute path the node process loaded, and nothing rewrites either side.
 
-  `minifiedBundlesCarryMaps.test.ts` asserts the property over the SET: every bundler options object in the CLI that turns minification on must also decide `sourcemap`. That is what was missing — not one option, three, because nothing was watching the class.
+  Measured downstream: 4300 artifacts uploaded, release finalised, every frame still minified. Nothing was red — the exact shape this code's own header warns about, an upload that matched nothing looking like one that worked. The comment above the uploader asserted the injection happened, which made it a description standing where a check belonged.
 
-  **`voltro update` carries you across this** — codemod `0.59.0/01_sourcemaps_moved_to_the_top_level`. If you pin versions by hand and never run it, print the notes without changing anything: `voltro update --codemods-only --from <your current version> --dry-run` (this one ships in 0.59.0).
-- **@voltro/ai** — **Speech has a cost path, and a built-in provider name can be taken over.**
+  `inject` now runs first, over the same directories, and `sourcemapDebugIds.test.ts` drives the real binary to assert an id lands in both the JS and the map. `--url-prefix` stays as the fallback for the browser bundle, whose frames really are URLs.
 
-  Three changes, one thread: the speech seam existed and nothing could reach it.
+  The boot line names the new setting (`sentry active … captureFailures=false`), because a default the framework picks for you is one nobody finds again.
 
-  **`registerSpeechProvider(name, provider, { replaceBuiltin: true })`.** Refusing `mock` / `openai` / `gateway` / `anthropic` outright was wrong, and the case that shows it is one the refusal could not see: a provider name is not always an alias the app chooses. `openai` is the segment the gateway puts in its model ids, so it is what a stored catalog's rows carry and what a picker submits — an app told to pick another name cannot, without rewriting persisted rows and live sessions. It keeps its own dispatch instead, for every provider rather than the colliding one. What the refusal protected is kept by putting the intent in the call.
+  **`voltro update` carries you across this** — codemod `0.60.0/01_declared_failures_are_not_incidents`. If you pin versions by hand and never run it, print the notes without changing anything: `voltro update --codemods-only --from <your current version> --dry-run` (this one ships in 0.60.0).
 
-  **Registered providers resolve BEFORE built-ins.** The dispatch decided from a hard-coded list of built-in names, so without this the flag would let you register `openai` and never route to it — declared, documented, wired at zero call sites.
+### Added
 
-  **`MeteredUsage` — a tally in characters or seconds.** Every speech vendor meters one of those; none meters tokens. A ledger that only knew tokens could not hold a speech call at all, so speech spend was not un-priced, it was *absent*. The token shape is untouched (it is what the AI SDK returns); the new shape is separate rather than a unit tacked onto `AiUsage`, because writing a character count into a field called `inputTokens` puts a lie in a row someone reads later.
+- **@voltro/cli, @voltro/plugin-sentry** — **The web server process now initialises Sentry and reports its own errors.**
 
-  `_voltro_ai_usage` gains a `unit` column, and `costSource` gains `'unpriced'`: a non-token unit with no supplied price is written with the real count and a zero cost rather than a fabricated one, since a per-1M-token rate applied to a character count produces a number indistinguishable from a real one. Sum the count columns grouped by `unit`, never across it.
+  A framework app runs two server processes. `voltro serve` is the api, where `sentryPlugin()` initialises the SDK through the plugin lifecycle. `voltro start` is the web server — SSR, loaders, ISR, the revalidation legs — and it has no plugin lifecycle, so it had none.
 
-  BREAKING for a caller that had narrowed `CostBreakdown['costSource']` to two values or reads `estimateCostUsd`'s return positionally. No call site changes SHAPE — the token path takes the same arguments and returns the same numbers — but a narrowing is user-authored code, so this carries a `manual` codemod rather than `none`: nothing here can be transformed (whether the third member belongs in your union is your decision), and the reader who needs it is exactly the one a "touches no user-authored code" line would have sent away. It also names the query that does not fail but answers wrongly: summing `_voltro_ai_usage` counts ACROSS units now adds characters to tokens.
+  That was not a cosmetic difference in boot output. A web pod legitimately logs less than an api pod, because it has no store, no rpc, no scheduler, no workflows and no plugins. What it also had was **no error reporting**: an SSR shell throw is caught, logged and answered with a 500, so no browser ever renders it and the client-side ErrorBoundary bridge cannot see it either. Both ends of the integration worked and the middle was dark — while the docs' "React render error ✅ auto" row, true of the client path, read as covering all of them.
 
-  **`voltro update` carries you across this** — codemod `0.59.0/02_costsource_gained_unpriced`. If you pin versions by hand and never run it, print the notes without changing anything: `voltro update --codemods-only --from <your current version> --dry-run` (this one ships in 0.59.0).
+  Set `SENTRY_DSN` on the web deployment and the boot says `sentry active` with the same message and the same field names as the api half, from the same function — `initSentryServer` in `@voltro/plugin-sentry/server`, which the api plugin now calls too. One init, because a copy of `skipOpenTelemetrySetup`, the traces default, the overrides-first spread and the degrade-on-missing-SDK path would have drifted the moment either half gained a case.
 
-### Added
+  Three deliberate asymmetries, each because the two processes are not the same thing:
+
+  - **`traces: false` on the web side.** The api contributes a span processor to the framework's tracer; the web server has no tracer at all, so tracing on would put `traces: true` in a boot line while nothing produces a span. - **No DSN is SILENT here.** On the api side `sentryPlugin()` is a declaration and an inert one contradicts it. There is no declaration here. - **`@voltro/plugin-sentry` must be installed in the WEB app.** With a DSN set and the package missing, the boot names the command rather than failing — monitoring must never be what stops a deploy.
 
-- **@voltro/ai** — **`GatewayModelInfo.raw`** — the `/v1/models` entry exactly as it came over the wire, beside the normalised fields.
+  Measured against a real production `voltro start`, both branches. Note that production `voltro start` loads the app's precompiled start bundle, so a web deployment picks this up when that bundle is rebuilt — the framework version alone is not enough.
 
-  Normalising is the right default: the union of `tags`, `supported_parameters` and `modalities` is framework knowledge, and every app on the gateway was writing those forty lines differently. But normalising is lossy by construction, and the fields it drops are not decoration — a picker built on the vendor's own capability tags, a pricing display that shows a structure we have not normalised, `zdr` and `no_training` kept apart instead of folded into `dataPolicy`.
+### Fixed
 
-  Without `raw`, such an app fetches the endpoint a second time and maintains a second parser of the same response. One field rather than three more normalised ones, because the alternative asks the same question again at every field the gateway adds.
+- **@voltro/workflow, @voltro/runtime, @voltro/database, @voltro/cli, @voltro/plugin-sentry** — **Six raw writes removed from production log streams — and the guard that was supposed to catch them rewritten, because it was green for two independent reasons.**
 
-  Absent on the injected-provider path, for the same reason `capabilities` is: that seam never saw a response, and an empty object would turn "no wire data" into the claim that the wire carried nothing.
+  A pod tail showed `[voltro:workflow] shard-lock coordination: row-based (dialect=mariadb, mode=row)` sitting between JSON records. `@voltro/logger` is what makes a line JSON in a pod and pretty on a TTY; a `process.stderr.write` bypasses that decision at exactly the place nobody looks, because a dev terminal renders both the same.
 
-### Fixed
+  Fixed at the source: the workflow cluster layer (2), `rpcServer`'s computed-cache warning, the subscription outbox's and the RYW store's `warn`/`onError` defaults — those two are not fallbacks, the callers pass nothing, so the default IS the production path — and the migration file discovery's skip notice, which lands in the migrate job's stream.
+
+  **The guard is the part worth reading.** `prodLogDiscipline.test.ts` existed for this exact class and reported clean, for two reasons that had to be fixed separately:
 
-- **@voltro/cli** — **`@sentry/cli` 3.x loads.** The loader read one export spelling — `module.exports = SentryCli`, which is 2.x. 3.x ships `exports.SentryCli = SentryCli`, so `mod.default` is a namespace object rather than the class, and a build with a source-map upload configured stopped with *could not be loaded*.
+  - Its file set was a hand-written list of five. A guard that opts files IN says nothing about any file added after it was written. - Its matcher was LINE-LOCAL, so `process.stderr.write(` on one line and the `` `[tag] `` on the next never matched — 4 of the 9 call sites in the repo are written that way, including one in a file that WAS on the list. The guard had been pointed straight at an offender and called it clean.
 
-  The framework cannot pin its way out of this: `@sentry/cli` is FSL-1.1-MIT, so it is not ours to depend on and the app installs it — which means `pnpm add -D @sentry/cli`, the command we ourselves print, resolves the latest. Reading one spelling turned our own documented instruction into a failing build.
+  It is opt-OUT now: every server-side package's source is scanned, exceptions carry a reason, and a second test fails if an exception's call site disappears — an allowlist entry for code that is gone reads as a rule with a hole in it.
 
-  All four positions are accepted now (both spellings, each of which `import()` presents twice), and the two failures are told apart: a package that resolved but had no readable constructor no longer says *install it*. That reading is what cost a pipeline — locally `require()` resolves and the binary is there, so nothing about the install looks wrong.
+  Verified against a real `voltro serve` under `NODE_ENV=production`: 35 records, zero framework lines that are not JSON.

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

@@ -12,12 +12,12 @@
   "dependencies": {
     "@effect/platform": "^0.97.0",
     "@effect/rpc": "^0.76.0",
-    "@voltro/ai": "0.59.0",
-    "@voltro/cli": "0.59.0",
-    "@voltro/database": "0.59.0",
-    "@voltro/env": "0.59.0",
-    "@voltro/protocol": "0.59.0",
-    "@voltro/runtime": "0.59.0",
+    "@voltro/ai": "0.60.0",
+    "@voltro/cli": "0.60.0",
+    "@voltro/database": "0.60.0",
+    "@voltro/env": "0.60.0",
+    "@voltro/protocol": "0.60.0",
+    "@voltro/runtime": "0.60.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {

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.59.0",
-    "@voltro/database": "0.59.0",
-    "@voltro/env": "0.59.0",
-    "@voltro/plugin-auth": "0.59.0",
-    "@voltro/protocol": "0.59.0",
-    "@voltro/runtime": "0.59.0",
-    "@voltro/sql-postgres": "0.59.0",
+    "@voltro/cli": "0.60.0",
+    "@voltro/database": "0.60.0",
+    "@voltro/env": "0.60.0",
+    "@voltro/plugin-auth": "0.60.0",
+    "@voltro/protocol": "0.60.0",
+    "@voltro/runtime": "0.60.0",
+    "@voltro/sql-postgres": "0.60.0",
     "effect": "^3.22.0"
   },
   "devDependencies": {
-    "@voltro/testing": "0.59.0",
+    "@voltro/testing": "0.60.0",
     "typescript": "^6.0.3",
     "@vitest/coverage-v8": "^4.1.10",
     "vitest": "^4.1.10"

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

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

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

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

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

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

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

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

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

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

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

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

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

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