@voltro/cli 0.56.0 → 0.58.0

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

@@ -1,4 +1,4 @@
-# What's new in 0.56.0
+# What's new in 0.58.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,493 +9,197 @@ BREAKING entries name a codemod; run `voltro update` to apply it.
 
 ### ⚠ BREAKING
 
-- **@voltro/plugin-broadcast, @voltro/cli** — **Three ways the cross-replica bus mishandled a broker that was not there.**
+- **@voltro/ai, @voltro/client** — The gateway catalog names eight modalities, `ModelModality` has listed all eight since the union was widened, and the runtime could execute five. Four of the six gaps are closed.
 
-  **Boot no longer dies when the broker is unreachable.** `attachBroadcastBus` awaited its subscribe, and a rejected subscribe threw out of it, out of `wireBroadcastBus`, and out of boot — so a broker that happened to be restarting turned every replica into a crash loop. That contradicted the package's own first paragraph, which promises that a broker outage "degrades cross-replica fan-out only": true for an outage after boot, false for one during it, and the false half is the worse one, because a broker restart is precisely when every pod is dialling at once. It now warns, keeps local reactivity working, retries in the background, and reports the time it spent unsubscribed as a gap — because that is what it is: the fleet went on writing while this replica was not listening, and pub/sub keeps no log to replay.
+  **The catalog gives out what the response carries.** `getAvailableModels` asked `@ai-sdk/gateway`'s provider, whose entry type has six fields where the HTTP response has twenty-one — so nothing was discarded, the fifteen never arrived. `readGatewayCatalog()` reads the endpoint and adds `capabilities`, `modalities`, `contextWindow`, `maxOutputTokens`, `releasedAt`, `knowledgeCutoff` and `dataPolicy`.
 
-  **A peer that restarts under a stable name no longer switches its own gap detection off.** Gap detection compares a peer's serial against a watermark, and the serial restarts at 1 with the process while the NAME survives it — a StatefulSet pod keeps `POD_NAME`, and `VOLTRO_REPLICA_ID` is stable by definition. A receiver holding a watermark of 500 read the new process's 1, 2, 3… as "not newer", never advanced, and reported nothing for the next five hundred changes. The envelope carries an `epoch` now: a different epoch under a known name means a new process, so the watermark follows the process. A restart is not reported as a gap — it is not evidence that anything was missed.
+  `capabilities` is unioned from `tags`, `supported_parameters` and `modalities`, which overlap and regularly disagree: a model tagged `reasoning` does not always carry the parameter. Taking either alone produces a false negative, and a false "cannot" removes a model from a picker with no way to find out why — so the union is framework knowledge rather than forty lines every app writes differently. `capabilities` and `modalities` stay OPTIONAL: absent means the entry came from the injected test provider, and defaulting to all-false would turn "not known" into "this model has no vision".
 
-  **A transport that re-dials on its own now says so.** ioredis re-subscribes its channels after a reconnect and nats reconnects underneath the subscription; neither mentions that everything published while they were away is gone. Serial accounting finds that only if a peer publishes again, and on a quiet table "nobody wrote" and "we are stale forever" look identical. Providers report their connection lifecycle through a new optional `BroadcastProvider.onTransportEvent`, and a reconnect is treated as the hole it is.
+  **The runtime says what it can run.** `executableModalities()` / `canExecute()` replace the hand-kept list an app needs to stop a picker offering a model nothing can execute. It is tied to the exports that justify each entry, so shipping a primitive without adding it turns a test red — which it did, twice, during this change.
 
-  Two driver defaults changed with it: the nats connection is now `maxReconnectAttempts: -1` and `waitOnFirstConnect: true`. nats.js defaults to giving up after ten attempts, which for a broker down about twenty seconds meant the connection closed for good, every subscription iterator ended, and the replica was deaf until it restarted — silently. And neither provider memoises a rejected connection promise any more: a broker briefly unreachable at construction was unreachable forever, because every later attempt awaited the same settled rejection and never dialled again.
+  **`transcribe` exists.** Nine transcription models were unaddressable without pulling the raw SDK past the framework (and resolving gateway credentials twice in one process). `source` takes `{ storageRef }`, `{ url }` or `{ bytes }`, because audio is large and usually already stored — the storage read is INJECTED (`resolveRef`), so `@voltro/ai` never learns about buckets. `segments` is absent rather than `[]` when the provider returned none.
 
-  **Breaking:** `attachBroadcastBus`'s `onGap` now receives one `BroadcastGap` object instead of `(origin, missed)`. `origin` and `missed` are still exact when they exist, and optional because a hole with no peer to blame is now reachable. See the codemod note.
-- **@voltro/runtime, @voltro/cli** — **`defineReaction`'s `dedupeKey` was enforced by a per-process set, so the same change acted once per replica.**
+  **`rerank` reaches the gateway.** It was the one primitive that did not take a `ProviderConfig`: it wanted the vendors' own keys and could not express the gateway at all, so five reranking models in the catalog were unreachable.
 
-  `dedupeKey` is the one guard `defineReaction` refuses to boot without, and its documented promise is that the same logical change acts exactly once. It was backed by an in-memory `Set` shared across reactions in one process, consulted as `has(key)` then written as `add(key)` after the act returned. Two independent defects in one mechanism:
+  **A speech provider the gateway does not carry can be registered.** The gateway serves nine speech models; a real voice catalog runs to hundreds behind vendors it does not carry, so an app with its own adapter called its own synthesizer and skipped the primitive — losing the shared error type and cost path. `registerSpeechProvider` gives that adapter a socket. No adapters ship: the framework is not in the business of tracking somebody else's REST API, and the app already has them.
 
-  - **Per-process.** N replicas each held their own set, so a reaction whose act starts a workflow started N workflows, and one with `costBudgetUsd` spent N times. Every test and every single-instance run confirmed the gate worked, which is why it survived — it was real in exactly the configuration that cannot observe it. - **Read-then-write.** Even in one process, two concurrent changes with the same key both passed `has` before either reached `add`, because the act between them is awaited.
+  Not built: `realtime`. Not for want of a model surface — the gateway exposes one — but because every streaming kind in Voltro is server→client, so relaying a duplex session over the existing authenticated connection needs a transport capability that does not exist. `canExecute` answers `false` for it, which keeps it out of a picker until it does.
 
-  The gate is now a single atomic claim against `_voltro_change_claims` (`insertIgnore` on a `UNIQUE`, the arbiter the cron scheduler uses), taken BEFORE the act. Both boot paths wire it; the per-process set remains only as the fallback for a harness that wires none, and says so loudly at attach time.
+  Migration: `rerank`'s `provider` widened from `'mock' | 'cohere' | 'voyage'` to include `ProviderConfig`. Passing a string is unchanged; reading the field off a typed options object is now a union. See the codemod note.
 
-  Taking the claim first is what makes it a gate rather than a report, and the cost is stated rather than hidden: **an act that throws has already consumed its key and is not re-run by a later duplicate.** Durability belongs to the workflow the act starts, not to the trigger.
+  **And the ergonomy over them, because a primitive nobody can reach is half a feature.** `transcribeStep` puts transcription on the durable-step path with `offload: true` — the modality that runs longest was the one without it, and a ninety-minute recording held a worker for the whole call. The queue row carries the source, never the bytes. `retrieveReranked` is the second retrieval stage declared once instead of the twenty lines every app writes (fetch N, reorder, keep K — with its own N, its own K, and half of them forgetting the cost). `useTranscription` makes upload and transcription ONE state: `progress` is scoped to the phase, because a single number across both reaches 1 when the upload finishes and sits there for the whole transcription, and a bar that says finished is worse than no bar.
 
-  **Breaking:** `ReactionRunDeps.dedupe` is `{ claim: (key) => boolean | Promise<boolean> }` instead of `{ has, add }`. Nothing to do unless you call `runReaction` yourself — `voltro dev` and `voltro serve` build the deps and pass the durable claimer. See the codemod note for why this is not a rename.
-- **@voltro/plugin-billing, @voltro/protocol, @voltro/database, @voltro/plugin-cdc-out, @voltro/cli** — **A CDC meter accrued a usage unit on every replica, so a tenant on two pods was billed twice.**
+  **`voltro update` carries you across this** — codemod `0.58.0/07_rerank_takes_a_provider_config`. 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.58.0).
+- **@voltro/protocol, @voltro/plugin-auth-supabase, @voltro/cli, @voltro/voltro** — An auth strategy's shared secret may be a function, so `voltro build` no longer needs the app's production credentials.
 
-  `plugin-billing`'s `metering: { … from: 'cdc' }` accrues one unit per matched row change, through the plugin `onChangeEvent` tap. That tap is delivered to every replica — that is what makes a `changeScope: 'fleet'` store (postgres LISTEN/NOTIFY, mysql binlog) cross-instance in the first place. For a reader that is correct. This is not a reader: `reportUsage` increments a shared counter and the flush reports the delta to the billing provider. So the invoice was multiplied by the replica count, by the plugin whose entire job is counting, with nothing in any log.
+  `voltro build` imports `app.config.ts`, so anything the config constructs runs at build time. `supabaseStrategy({ jwtSecret: process.env.SUPABASE_JWT_SECRET })` therefore made an image build need a production secret for a bundle that will not contain one. A placeholder is not available — this framework ships no secret values anywhere, and an `ARG SUPABASE_JWT_SECRET` in a Dockerfile is exactly that — so a deployment stayed on the slower tsx path instead.
 
-  The tap now claims each change before accruing, through the same INSERT-wins arbiter behind `defineSubscriber({ once })` and a reaction's `dedupeKey`. An ungated tap (single process, memory store) still accrues and says so once — loudly, because an ungated meter is a factor-of-N on an invoice and is indistinguishable from a correct one by looking at the number.
+  `jwtSecret` now accepts `string | (() => string | undefined)`, on `jwtBearerStrategy` and on the Supabase strategy that specialises it.
 
-  **Naming a change needed a shared answer, and one already existed in the wrong place.** A fleet change carries no LSN, no commit id and no `traceId` — that last one deliberately, so a local trace is never mis-attributed to a remote write — so two replicas have no field they can both name it by. `@voltro/plugin-cdc-out` manufactured the missing identity from content plus its position among content-identical repeats, and it was the only consumer until this defect turned up the second one. `changeDigest`, `composeChangeKey`, `parseChangeKey` and `OccurrenceCounter` now live in **`@voltro/database`**, beside `ChangeEvent` itself.
+  **The deferral is paired, and that pairing is the design.** A thunk alone would trade an image-build inconvenience for a runtime surprise: the failure of a MISSING secret would move from boot to the first request that happens to carry a token, and an auth strategy that cannot verify one accepts nobody — a process that started cleanly, serving a login that can never succeed. "Fail at boot" is what the env gate, the plugin env contracts and the migration guard all promise, and this is not the place to sell it.
 
-  Keying on the row id instead would have been worse than the defect for an `op: 'update'` meter: two genuine edits to one row share an id, so the meter would count the first and drop every one after it — a bill that stops growing while the work continues.
+  So `AuthStrategy` gained an optional `verifyConfig()`, and the pass over the strategies that `voltro dev` and `voltro serve` already share calls it. A build never reaches that builder. Three moments, three answers: construction is silent, boot decides, verification uses the settled value — resolved once, because a credential re-read per request is a `process.env` hit on the hot path and a value that could change under a running process.
 
-  **Breaking:** `PluginBindContext` gains a REQUIRED `claimChange(scope, key)`. Every plugin's `bindDataStore` receives it; a plugin that constructs a `PluginBindContext` itself (a unit-test harness) must supply one. Required rather than optional because an absent gate reads exactly like a gate that passed. `@voltro/plugin-cdc-out` no longer re-exports the change-identity helpers — import them from `@voltro/database`.
+  A thunk counts as PRESENT at construction: whether it resolves is a boot question, and calling it early to find out would undo the whole point. Passing no credential at all still refuses at construction, unchanged.
 
-  **`voltro update` carries you across this** — codemod `0.56.0/05_plugin_bind_context_claims_a_change`. 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.56.0).
-- **@voltro/cli, @voltro/devtools-ui** — **Every `/_voltro/inspect/*` answer is now an `Observation` — it says what it is about, who answered, and how complete it is.**
+  Migration: passing a value is unchanged; what can stop compiling is READING `jwtSecret` off a typed config, which is now the union. That is the mirror of "more precise is still breaking" — less precise breaks readers — and the population is small, because the interface is one users construct and a literal's own inferred type never widened. `@voltro/voltro` is listed because it re-exports the type.
 
-  ```json
-  {
-    "data":  { "…": "what the route returned before" },
-    "scope": { "kind": "process" },
-    "origin": { "replicaId": "api-7d9f-x2k", "instanceId": "api-7d9f-x2k@1787…", "version": "0.56.0" },
-    "completeness": { "complete": false, "fleetSize": 3, "reason": "process-scoped: this is 1 of 3 replicas" },
-    "capturedAt": 1787892497073
-  }
-  ```
-
-  **Why the payload alone was not enough.** `/subscriptions` answers with the subscriptions of the ONE process that received the request. `/schedules` answers with the whole fleet's, read from the shared store. Both were plain JSON with nothing to tell them apart, so on a multi-replica deployment the first is an unlabelled sample and reads exactly like the second. On ONE replica the difference is invisible — which is every development environment, every e2e and every template, so the environment in which they are indistinguishable is the one the framework is built and tested in.
-
-  Four scopes, and the fourth is the one an outside report would not have asked for: `process`, `shared-store`, `fleet`, and `declaration` — `/routes`, `/manifest`, `/env` describe the SOURCE TREE, identical on every replica of one version and different across a rolling deploy.
+  **`voltro update` carries you across this** — codemod `0.58.0/06_jwt_secret_may_be_a_function`. 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.58.0).
+- **@voltro/runtime, @voltro/cli** — A fleet view no longer counts rows left behind by processes that are gone, and the rows of live replicas actually refresh on MariaDB.
 
-  **`fleetSize` is the cheap half, and it needs no aggregation at all.** A process-scoped answer states how many replicas exist, so a bare `curl` now says it is a fraction and of what. When membership cannot say, the field is ABSENT rather than `1`: "I am alone" and "I cannot know" must not render identically.
+  Three symptoms, one root cause and two that outlived it.
 
-  **Default-DENY, because a default is a decision nobody made.** A path with no entry in `ROUTE_SCOPES` is refused with the fix in the message, so a new endpoint cannot ship unlabelled — it fails on its first request, in its author's own dev loop. Mutating routes are enumerated as `write` rather than inferred from the HTTP method: `?scope=fleet` on `/agent/call` would run a user's handler once per replica.
+  **The rows were frozen.** `writeReplicaObservation` upserts on `UNIQUE (replicaId, kind)` — a conflict key that is not the primary key, with a fresh `id` on every write — which is exactly the shape the MySQL/MariaDB upsert guard was rejecting. Every republish after the first was rolled back, so a publisher writing every 30s produced a row whose age grew second for second.
 
-  **Three dispatchers, not one.** Wrapping `handleInspectRequest` looked complete from inside itself while `handleInspectAsyncRequest` and `handleSharedInspectRoute` went on answering bare — `/cluster`, `/schedules` and every workflow read. Nothing in the route table showed it; it was found by asking a running process for every route. `inspectDoors.test.ts` pins all three on every commit and `scripts/observation-e2e.mjs` re-asks a real bundled serve. The same sweep caught a wrapper defect no unit fixture could: a route that builds its response by hand rather than through `json()` was wrapped into an envelope with `data: undefined`, which serialises away — every field around the answer correct, and the answer gone.
+  **The failure said nothing.** It was logged at `debug`, on the reasoning that a failed write leaves the previous row and the reader reports it as stale, so the failure is visible in the answer. It is not: a stale row is what a slow, busy or departed replica looks like, and the answer never says a write was REFUSED. It was also invisible where it mattered — `voltro dev` prints debug and `voltro serve` does not, so the unattended deployment got no line at all. The first failure per kind now warns.
 
-  **The dashboards say it on screen.** `ScopeNotice` renders inside the SHARED `devtools-ui` pages, not in each host dashboard, for the reason every omission in this codebase has been invisible: a label each consumer must remember is a label one consumer will not have, and the page that forgot is indistinguishable from a page with nothing to warn about. It renders nothing when the answer is complete — a banner over a complete answer trains people to ignore banners.
+  **Nothing ever removed a row.** The table is keyed `(replicaId, kind)`, so a restart overwrites its own row and a replica that never returns leaves one forever — counted as a responder, counted in the version tally, and old enough to hold `complete` at false for the life of the deployment. Membership is the roster of who is alive, so a row whose replica it no longer lists is now reported as `departed`: separately from `stale`, because a stale row belongs to a process that is running and has stopped refreshing (a fault) and a departed one belongs to a process that is gone (a scale-down). It is reported rather than dropped — a reader who cannot see them cannot tell a fleet that scaled down from a table being written by something nobody is tracking. The publisher also forgets its own rows on shutdown, so the ordinary case leaves nothing to classify.
 
-  **Breaking:** a caller reading `/_voltro/inspect/*` JSON reads `.data` now. Both dashboards unwrap in their single fetch helper and keep the envelope on `_observation` for the notice. A response without the envelope passes through unchanged, so an app on an older framework version is not a broken app.
+  The sharpest consequence of the old behaviour was not the incompleteness: `versions` counted the framework version of a process that had been dead for hours and reported a version SPLIT across a fleet that had none — a line an operator acts on.
 
-  **`voltro update` carries you across this** — codemod `0.56.0/01_inspect_answers_are_observations`. 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.56.0).
-- **@voltro/cli** — **`voltro serve` on a WEB app now refuses. It used to delete the deployment artefact.**
+  Migration: `FleetMergeResult.departed` is required, so code that CONSTRUCTS one — a test double for `fleetObservations` — needs the field. Reading one is unaffected. See the codemod note.
 
-  `voltro start` (production) and `voltro dev` (development) are unchanged, and an API app is unchanged. What is removed is the web branch of `serve`, which was advertised in the CLI's own help as *"Production server: web app (vite preview) OR API, auto-detected"*. Both halves of that were measured before it was removed:
+  **`voltro update` carries you across this** — codemod `0.58.0/03_fleet_view_reports_departed_replicas`. 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.58.0).
+- **@voltro/client, @voltro/web** — An rpc call that fails in the client now reaches the app's error REPORTERS, not only its rpc listeners.
 
-  **In production it never ran.** The launcher's serve fast path requires `.framework/dist-api/serveBundle/serveEntry.js` — an artefact a web build does not produce. A web app got:
+  There were two buses. `clientErrorBus` is the module-global seam a reporter subscribes to — the route ErrorBoundary publishes render and loader failures there, `reportClientError` publishes manual captures, and the Sentry browser integration listens. `RpcErrorBus` is a per-runtime bus with a different subscriber set, for cross-cutting POLICY: redirect on `Unauthenticated`, toast on a network failure. Nothing connected them, so a call that failed in the client reached policy and never reached reporting.
 
-  ```
-  [voltro] FATAL: production `voltro serve` requires a precompiled serve bundle at
-    …/.framework/dist-api/serveBundle/serveEntry.js
-  Run `voltro build` before serving
-  ```
+  The subscription case is the one that costs. A rejected subscription leaves `data: undefined`, `loading: false` and an empty list — which is also what "nothing matched" looks like — so there is nothing in the UI to notice and nothing in any reporter to find.
 
-  directly after a `voltro build` that had just succeeded.
+  The bridge is in `RpcErrorBus.emit`, not at the six call sites that emit rpc errors, so a seventh is covered by existing. `ClientErrorEvent.source` gained `rpc.mutation` / `rpc.action` / `rpc.subscription` as three separate labels rather than one `rpc`: a failed mutation is a write the user watched fail, and a failed subscription is a screen that silently never filled. The rpc tag and the `traceId` — the same id the server logged — travel in `context`.
 
-  **Below production it destroyed the build.** The web branch ran a SECOND vite build with `plugins: [react()]` only — no `@tailwindcss/vite`, no image pipeline, no per-page islands entries — and then `vite preview`, which Vite documents as not for production use. Measured on a fixture:
+  Everything is published. A reporter that must not be flooded by a reconnect storm applies its own ceiling: the bus's job is to make the failure observable, and which failures are worth an event is a policy it cannot hold for every subscriber.
 
-  - with Tailwind, the build ABORTS: `[postcss] ENOENT: no such file or directory, open 'tailwindcss'`, surfaced as `unhandled cli error` with a raw stack; - without Tailwind it SUCCEEDS — and because both builds write `.framework/dist`, which Vite empties (it sits under its root), it deleted `dist/server`, `island-shells/` and every pre-rendered route directory. Immediately afterwards, `voltro start` refused to boot: *"requires precompiled artefacts: …/dist/server/ssrEntry.js"*.
+  Migration: only an EXHAUSTIVE switch over `event.source` stops compiling. If you bridged the two buses by hand, delete that bridge or you will report twice — and keep whatever throttling you put around it.
 
-  So `voltro build` → `voltro serve` → `voltro start` left the deployment unable to start, and the middle command was the one the help recommended.
+  `@voltro/web` is listed because it re-exports the type: the union widens in its golden too, and a consumer importing `ClientErrorEvent` from there is affected identically.
 
-  The codemod is `manual` with `reach: 'beyond-source'`: the command being replaced lives in Dockerfiles, compose files, CI jobs and runbooks, not in `.ts`. It searches every text file git tracks and says plainly that a step defined in a CI runner's own UI is beyond what any repository scan can see.
+  **`voltro update` carries you across this** — codemod `0.58.0/04_rpc_errors_reach_reporters`. 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.58.0).
+- **@voltro/plugin-sentry, @voltro/cli** — Sentry performance traces are on by default, and the web entry no longer needs a config block to initialise them.
 
-  The shipped Dockerfiles were already updated in the same change set and now run the precompiled bundle directly — `node .framework/dist-web/startBundle/startEntry.js` for web, `node .framework/dist-api/serveBundle/serveEntry.js` for an api.
-- **@voltro/runtime, @voltro/cli** — **Every outbox effect was delivered once per replica.** `drainOutbox`'s summary line has always said "claim due rows". It did not: it read every `pending` row and ran its handler, and every replica runs the drain. Not on a crash, not on a retry — on the happy path, every time. Measured with two stores over one postgres: one enqueued row, one drain pass each, handler called twice.
+  `sentryPlugin({ traces })` defaulted to `false` while the browser half defaulted `tracesSampleRate: 1.0` with `browserTracing` on. That pairing is the worst of the three available defaults: every page load, navigation and rpc call became a browser span that was emitted, paid for, and belonged to a trace with no server half — a browser hop hanging off nothing. Both-off would at least be coherent; both-on is what the two halves were built for, and the docs already said to pass `traces: true` to get it, which made that sentence a workaround note rather than a configuration option.
 
-  The docs told handler authors to be idempotent and justified it with the crash case ("a process that dies between the remote accepting it and us recording that"). That reads as rare. "Your webhook fires once per replica, always" is a different operational fact, and nobody was told it.
+  The rate stays 1.0 rather than being quietly lowered — a number the framework picks on your behalf is one nobody can find again — and the boot line names it: `sentry active traces=true tracesSampleRate=1`. Lower it with `tracesSampleRate`, or `traces: false` for errors and breadcrumbs only.
 
-  `OutboxStatus` has always carried a `'delivering'` member that nothing set. That is the gate now, taken atomically: reclaim claims that have outlived their lease, read the due window, CAS `pending → delivering` stamping the claiming PROCESS, then handle only what came back. A racing replica loses the row because the predicate names the state it is leaving. `plugin-cdc-out` has done exactly this since it shipped, with the same `updateMany` CAS and the same state — two outboxes in one repo, one of them right.
+  The browser half is reached the same way. The generated entry called `initSentryBrowser` only when `app.config.ts` carried a `sentry:` block, which made that block load-bearing for something it does not decide: the api half needs no config object (`sentryPlugin()` reads `SENTRY_DSN`) and the browser half reads `VOLTRO_PUBLIC_SENTRY_DSN`, so an app that had set its variables still had to add an empty `sentry: {}`. The entry now initialises whenever `@voltro/plugin-sentry` is a dependency of the web app — the dependency is the intent — and the block is for overrides. Without a DSN from either source the init returns immediately, so this changes nothing for an app that set none.
 
-  Delivery is still AT-LEAST-ONCE and handlers must still be idempotent: a process can die between the remote accepting and the row being marked, and no claim closes that. What is gone is the routine N-fold duplicate, which was never a guarantee gap — it was the word "claim" not having been implemented.
+  Migration: decide once whether you want the transactions. See the codemod note.
 
-  `_voltro_outbox` gains `claimedBy` / `claimedAt` (nullable), applied by the declarative differ on `voltro db apply` and on a `voltro dev` boot, every dialect.
-
-  **Breaking:** `DrainDeps.claimedBy` is REQUIRED. It was optional for one draft, which meant a caller who omitted it silently got the old every-replica behaviour — an exactly-once gate that switches off when you leave a field out is not a gate. `voltro dev` / `voltro serve` pass it for you; only a caller driving `drainOutbox` directly is affected. `claimLeaseMs` (default 5 min) is new and optional.
-
-  **`voltro update` carries you across this** — codemod `0.56.0/03_outbox_drain_needs_an_identity`. 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.56.0).
-
-### Added
+  **`voltro update` carries you across this** — codemod `0.58.0/05_sentry_traces_on_by_default`. 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.58.0).
+- **@voltro/runtime, @voltro/cli** — `SYSTEM_SUBJECT` — what a schedule, a subscriber, a resumed workflow and the webhook trigger context run as — is now a `system` subject. It was `{ type: 'anonymous', id: null }`, and every exemption for "the framework acting as itself" is keyed on `type === 'system'`: the row-filter bypass in `resolveRowFilterScopeFor`, the unfiltered-read refusal in `wrapStoreWithMixinBehaviour`, and `isSystemSubject`. It matched none of them.
 
-- **@voltro/database, @voltro/runtime, @voltro/cli, @voltro/data-transfer** — **`/_voltro/inspect/subscriptions?scope=fleet` — the fleet answer, assembled by READING rather than by asking.**
+  An app that calls `setRowFilter` therefore had every schedule fire refused at context-build time, before its handler ran — on both boot paths, from the cron timer and from `voltro schedule run` alike. The quieter half is the one that produced no error: a path that RESOLVED a scope for this subject asked the app's own filter what an anonymous caller may see, and applied that answer to a cross-tenant sweep.
 
-  Each replica publishes its counters into `_voltro_replica_observations` on a timer, so any replica can answer a fleet question from the shared store. That is the same mechanism `coordinationState.recentReplicaIds` already used by reading `_voltro_schedule_runs`; this generalises the one case.
+  `ctx.storeForTenant(id)` is fixed alongside it, and needed saying separately. It narrows to a `serviceAccount` subject by design, so a subject whose null tenant means "every tenant" cannot widen back out of the tenant it was just confined to — which also means the exemption stops at the derivation. The row-filter bypass now travels across that narrowing; the tenant confinement does not.
 
-  **Why not a fan-out over the broadcast bus.** The bus can `publish` and `subscribe`. A read-time fan-out would have to build request/response on top: a correlation id, a reply channel, a deadline to guess, a partial-result protocol. And it puts the DIAGNOSTIC on the failure path, so it degrades — by timing out — exactly when it is needed. Writing inverts that: the transport is the database, the one thing that must be up for anything to work, and a dead replica goes STALE rather than silent. Staleness is a number, and a number can be reported; paired with the membership roster, "old" becomes "missing".
+  Migration: `actingUserId` answers `null` for a system subject, so a `runAsSystem` write stamps no `createdBy` / `updatedBy` instead of `'system'`. `createdBy` is a reference into the app's own `actors` table and the framework seeds no row there, so an id it stamps is one nothing points at — an outright insert failure where that reference is declared. Schedules, subscribers and workflows already stamped nothing and are unchanged. See the codemod note.
 
-  **Three things make the merge honest, and each is the case a naive `rows.map()` gets wrong:**
+  **`voltro update` carries you across this** — codemod `0.58.0/01_system_writes_stamp_no_actor`. 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.58.0).
+- **@voltro/runtime, @voltro/cli** — A workflow step now reads through its caller's row filter, resolved at execution time — and until now a workflow started by a user could not read at all.
 
-  - A replica membership knows about that has written nothing is **`missing`**, not absent. Dropping it makes a partial answer look complete — the same unlabelled sample this whole feature exists to end, one level up and more expensive, because now the reader believes they asked everybody. - A **stale** row is reported WITH its age rather than filtered out. Removing it hides that the answer is partial; keeping it unmarked presents fiction as current. Neither is available. - **Mixed versions are named.** A rolling deploy spans two shapes, and averaging them silently is wrong in a way nothing downstream can detect.
+  The store refuses a context that carries neither a resolved row-filter scope nor a system subject. A BOOTSTRAP run has the system subject and passed; a run started by a user has neither, so in any app that calls `setRowFilter` every workflow step threw before its executor ran. The gap was invisible from the framework's own suites because the arm that works and the arm that does not differ only in who started the run.
 
-  Only the newest GENERATION per replica is counted. A dead process's counters added to its successor's look exactly like a busy replica.
+  Visibility is resolved in the same seam as authority, at the same moment, for the same reason: `resolveAuthority` re-reads what a three-day-old run may DO, and the scope resolved beside it re-reads what that run may SEE. Restoring either from the start-context row would be a fact frozen at start time and made durable. A failure to resolve fails the attempt rather than downgrading it — a run that silently reads fewer rows than it should is indistinguishable from one whose data is not there. An app that registered no filter pays nothing; the resolution short-circuits without touching a store.
 
-  **With no shared store the request is refused with `501` and a reason** — never answered with this replica's own numbers. Handing a sample to someone who asked for the fleet in writing would be this feature committing the defect it exists to prevent.
+  `BuildAppContext`'s request parameter now declares `rowFilter`. It was read by the implementation and absent from the type, so the request arms were correct by the accident of passing a value the signature did not mention, while a non-request caller had no way to see there was anything to supply.
 
-  `_voltro_replica_observations` holds ONE upserted row per `(replicaId, kind)`, so it is bounded by fleet size × kinds rather than by time. There is no history and must not be: a history needs a retention policy, and this is a cache of the present. It is classified **environment-local** for data transfer — a foreign row would invent a replica that does not exist here, and then report it as present or, once it ages, as one that has stopped answering.
+  `ResolvedWorkflowCallerContext.rowFilter` is required, so code that CONSTRUCTS one — in practice a test double for a context builder — needs the field. Implementing `buildContext` is unaffected: it receives one more property it may ignore. Required rather than optional is deliberate: optional is what it effectively was, and it left a boot path able to omit the one value without which a user's workflow cannot run.
 
-  The publisher runs on BOTH boot paths, pinned by `bootPathParity.test.ts`: a replica that never publishes is a hole in every other replica's answer, and it reads as "has written nothing", which is indistinguishable from broken.
+  **`voltro update` carries you across this** — codemod `0.58.0/02_workflow_caller_context_carries_a_scope`. 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.58.0).
 
-  **Measured with two real replicas against one database** (`scripts/fleet-observation-e2e.mjs`): both publish, EITHER answers for BOTH (`responded: 2, expected: 2`), and a killed replica's row keeps being readable with a growing age rather than vanishing — which is the whole design in one assertion, since a dead process going silent is indistinguishable from "nothing happened" and a row that gets old is not.
-
-  That test found two defects the single-process one could not:
+### Added
 
-  - **An unreadable table read as an empty fleet.** Against a database whose schema predated `_voltro_replica_observations`, the merge reported `responded: 0, missing: [every replica]` — a healthy fleet described as gone. The read now raises and the route answers `503` naming the cause and the fix, because "nobody has written yet" and "I could not read the table" produce the same empty list and mean opposite things. - **A check of ours that examined nothing.** The single-process e2e asserted `typeof responded === 'number'`, which `0` satisfies — so it passed for the entire time the write was failing. It asserts `> 0` now.
-- **@voltro/web, @voltro/client, @voltro/cli** — **`web.api.connect: 'lazy'` — a page that reads no data no longer opens a WebSocket.**
+- **@voltro/cli** — `voltro doctor`'s `nullable-column-a-mutation-cannot-clear` rule now resolves FRAMEWORK and first-party PLUGIN tables.
 
-  The default is unchanged (`'eager'`: every declared api connects at mount), so nothing moves unless an app asks for this.
+  The rule asks "is this column nullable?" by finding the `table('<name>', { … })` declaration among the sources it was handed — the app's. That is right for the app's own tables and cannot work for ours: `_voltro_webhook_targets` is declared inside `@voltro/plugin-webhooks`, so a mutation writing to it resolved to "I could not look". The rule keeps that answer distinct from "this table has no nullable columns", because the two lead to opposite conclusions — but for our tables it was a permanent unknown, leaving anyone auditing their mutations to carry them as a standing exception and count them by hand.
 
-  Why it exists, measured in a real browser against a `voltro start`:
+  Doctor is a static analyser: it parses files and boots nothing, so it cannot import a plugin to ask a table about itself. The nullability of our own tables is therefore generated from our declarations — with the same extraction rule the doctor applies, so a manifest entry cannot mean something different from what the rule would have concluded — and shipped as data. `scripts/gen-framework-table-nullability.mjs --check` runs in CI, because a stale entry would answer with a value that is no longer declared, which is worse than the honest unknown it replaces.
 
-  | page | `interactive` | WebSocket attempts | |---|---|---:| | `/pricing` | `'none'` | 0 | | `/info` | `'islands'` | 0 | | `/docs/intro/getting-started` (subscribes to nothing) | default = `'full'` | **6** | | `/` (Todos, subscribes) | `'full'` | 5 |
+  An app's own declaration still wins where both have one: it is the more specific authority and the one a developer can actually edit.
+- **@voltro/plugin-sentry, @voltro/cli** — The browser half of the Sentry integration can now resolve its own configuration — from the public env, and from a module that runs at boot.
 
-  So the two opt-in render modes were already free, and the DEFAULT one connected regardless of whether the page used data. The six are reconnect backoff, not six live sockets — a socket that opens and is held was verified separately (a raw `ws://…/ws` against a running `voltro serve` opens and stays open with no auth, no subscription and no traffic).
+  **It reads `VOLTRO_PUBLIC_SENTRY_DSN` / `_ENVIRONMENT` / `_RELEASE`.** The api half already resolved `SENTRY_DSN`, `SENTRY_ENVIRONMENT` and `SENTRY_RELEASE` from the environment and declared all three, so `sentryPlugin()` takes no arguments. `initSentryBrowser` resolved nothing: without an explicit `dsn` it returned, and the only way to supply one was `sentry:` in `app.config.ts`. An explicit option still wins — `app.config.ts` is the more specific authority.
 
-  What a held socket costs is not just a connection: `isIdleNow` returns false while `connectedClients() > 0` (`idleDetector.ts:46` → `singleNodeOrchestrator.ts:147` → `wakeRouter.ts:44`), so **one browser tab on a pricing page prevents scale-to-zero indefinitely** — the feature the framework's own documentation describes two paragraphs above the condition that defeats it.
+  **`sentry.optionsFrom` names a module the generated entry calls.** Everything else in that block is a literal frozen into the bundle, which is right for a DSN and wrong for `environment` the moment one image serves more than one environment — an ordinary pipeline with one build job and several environment-bound deploy jobs. A baked `environment` is then true for at most one of them, and a wrong environment tag is worse than an absent one because Sentry defaults a missing one to `production` and a wrong tag gets acted on.
 
-  Under `'lazy'` the connection is deferred to the first hook that asks for that api. Demand is expressed in `useFrameworkApi`, the single accessor all 27 data hooks read through — a per-hook signal would be 27 chances to forget one, and a forgotten one is a hook that silently never connects. It is keyed by api NAME, so an app with an analytics api it touches on one page does not open it on every page.
+  There is no runtime channel to read instead: public values are baked at build time by construction. So the value has to be computed where it is known, which is the browser — and the entry is generated anyway, so it can call something. The resolver's result is spread LAST and may be async.
 
-  Verified on the same page that showed 6: **0 sockets** with `'lazy'`, and the Todos page still 5.
-- **@voltro/runtime, @voltro/cli, @voltro/database** — **`defineSubscriber({ once })` — run a handler once per change across the fleet, instead of once per replica.**
+  **And `voltro start` now says when a `VOLTRO_PUBLIC_*` cannot reach the browser.** Setting one as a deployment variable looks right, deploys cleanly, and does nothing — no error, no warning, no failed request. The check is exact rather than a guess, because both halves are present at boot: the process environment, and the object the build wrote (`.framework/env.public.json`, emitted alongside the baked module from the same source). A variable set to the value that was baked stays silent; one that was never baked, or that disagrees with the built one, is named with the reason. An unreadable manifest reports every runtime variable rather than none — "we could not check" and "there is nothing to report" are opposite facts.
+- **@voltro/cli, @voltro/plugin-sentry** — `voltro build` uploads source maps to Sentry and then removes them from the output.
 
-  A subscriber binds to the change stream on every api instance, so one `INSERT` behind three replicas calls the handler three times. That is the right default and stays the default: a handler that refreshes a search index, warms a local index or drops a process-local cache entry *has* to run everywhere, and a fleet-wide gate would leave every other replica stale. It assumes the handler is idempotent.
+  `web.sourcemaps: 'hidden'` already produced `.map` files, and the note beside it said to upload them in a deploy step and delete them before the image is built. Every word of that was right and all three hard parts belong to the build:
 
-  It is the wrong default for an EFFECT — a notification, a mail, a webhook, a payment — because there is nothing to make idempotent: the effect IS a write, so each run produces another one. `SubscriberDefinition` had no way to say so, while the primitive rubric recommended a subscriber for exactly that job.
+  - **the moment** — there is no seam in a Dockerfile between "the bundle exists" and "the image is built"; - **the release** — Sentry matches an artifact to an event by release, and the event's comes from `SENTRY_RELEASE` via `sentryPlugin`. Upload under a different value and no frame resolves, silently: an upload that matched nothing looks exactly like one that worked. A configured upload with no release now refuses the build rather than uploading under nothing; - **the deletion** — a `.map` left in `dist` is the app's source, downloadable by anyone, and "we delete it in the deploy step" is a promise a failing build breaks. It is a `finally` here: the maps go even when the upload fails, and a configured upload that did not happen fails the build. Verified against a real build — a failed upload left zero `.map` files and all five chunks.
 
   ```ts
-  export default defineSubscriber({
-    table: 'absence_requests',
-    on:    ['insert'],
-    once:  (event) => String((event.new as { id?: string } | null)?.id ?? ''),
-    handler: notifyApprovers,
-  })
-  ```
-
-  The key is claimed in the new `_voltro_change_claims` table — `insertIgnore` on a `UNIQUE(scope, key)`, the same INSERT-wins arbiter the cron scheduler uses for a (schedule, bucket) firing — and exactly one replica wins it. The scope is the subscriber's file id, so two subscribers watching one table never lock each other out.
-
-  Three things the type states rather than leaves to be discovered:
-
-  - **The key must tell two genuine changes apart.** A row id is enough for `insert` and `delete`. It is not enough for `update`: two edits to one row produce the same id, and the second is dropped as a duplicate. Use `` `${id}:${updatedAt}` ``. - **AT MOST once, not exactly once.** The claim is taken before the handler runs, so a replica that wins and dies takes the event with it. A claim that cannot be written at all is taken by nobody — fail-closed, because `once` promising "at most once" is what makes it worth having. Both are loud in the log; neither is retried. - **Which coordination each subscriber got is in the boot log**, because the two behaviours differ by a factor of the replica count and were otherwise indistinguishable:
-
-  ```
-  subscriber: registered table=absence_requests on=["insert"] once=fleet
-  subscriber: registered table=posts on=["insert","update"] once=per-replica
+  web: { sourcemaps: { mode: 'hidden', upload: { org: 'acme', project: 'web' } } }
   ```
 
-  `_voltro_change_claims` is created for every sql app and swept after an hour (`VOLTRO_CHANGE_CLAIMS_TTL_HOURS`). It rides the declarative differ, so `voltro db apply` and a `voltro dev` boot both create it, on every dialect.
-- **@voltro/cli** — **`voltro doctor` now asks the question a subscriber's author is the only one who can answer: should this effect repeat on every replica?**
-
-  `store.onChange` is a broadcast. That is CORRECT for a reader — a cache drop, an index refresh, a live query must run everywhere — and a multiplier for an effect, because there is nothing to make idempotent: the effect IS the write, so each run produces another one. One `INSERT` behind two replicas writes two notification rows; with a broadcast bus in front, four.
-
-  `subscriber-effect-without-once` fires when a `*.subscribe.ts` handler writes (`ctx.store.insert` / `update` / `upsert` / …), publishes (`ctx.publish`), or calls a `notify` / `sendWebhook` / `sendMail`-shaped helper, and the subscriber declares no `once:`. Advisory like every rule in that scan — it prints, it never fails a build, because `once:` on a READER would silence it on every replica but one, and only the handler's author knows which of the two they wrote.
-
-  It reads the handler through the AST, for two reasons at once. `once:` and the handler sit in ONE object literal, so "this file mentions `once`" is not the question. And the effect has to be found inside the handler under whatever name it gave its context parameter — `(event, ctx)`, `(event, { store })`, or a `handler: notifyApprovers` naming a function in the same file, which is the form the primitive's own doc comment teaches. A handler IMPORTED from another module is not judged: its body is not in the file being read, and a finding about code the rule never opened would be a guess wearing a file path.
-
-  **And `mutation-tail-effect` no longer fires on the file that took its advice.** That rule matches a `notify(...)`-shaped call in any file with an `export default` — which a `*.subscribe.ts` has. So a subscriber calling `notify(...)` was told to move its effect into a subscriber: our own two rules disagreeing on one file, which is how a whole section of the report gets skipped. Detected by the CALL (`defineSubscriber` / `defineReaction`) rather than the filename, for the reason the adoption check already exists — a file can adopt the primitive under any name.
-- **@voltro/protocol, @voltro/database, @voltro/runtime, @voltro/cli** — **`?replica=<id>` — ask ONE named replica, through the one you can reach.** The answer comes back with that replica's `origin`, process-scoped: the proxy does not launder whose answer it is.
-
-  **The address comes from the shared store, not from membership** — and that is a correction to the obvious design. Membership rides the broadcast bus, so peer addressing built on it works only for an app that configured one, and the operator who most needs to reach a specific pod is not reliably the one who did. The row already exists, every replica already writes it, and the database is already the thing that must be up. `_voltro_replica_observations` gained a `reachableAt` column.
-
-  **An endpoint that fetches a URL on request is an SSRF primitive unless it is built not to be.** Four rules, each closing a distinct way this could become one, and each with a test:
-
-  - **The caller names an ID, never a URL.** The address is resolved from a set we wrote; an unknown id is a `404` and no request leaves the process. "Unknown replica" and "published no reachable address" give the same message, because distinguishing them would tell a caller which ids exist. - **A proxied request carries a hop header and is always answered locally**, so `?replica=a` on A pointing at B pointing at A cannot cycle. The forwarded URL also has `replica` stripped and `scope=process` forced. - **The peer call forwards the caller's token and adds nothing.** A replica is not a more privileged caller than the human who asked. - **Only reads are addressable.** `?replica=` on `/invoke`, `/seeds/run`, `/migrations/rollback` or `/agent/call` is refused before any lookup.
-
-  A peer that does not answer inside a short deadline becomes a `504` naming it: a diagnostic that hangs is worse than one that says no.
-
-  **A declared address and a fallen-back one are different facts.** An unset `POD_IP` falls back to `127.0.0.1`, which is a shrug — recorded as NOT reachable, and no peer tries it. `VOLTRO_INSPECT_ADVERTISE_HOST` declares one, including `127.0.0.1` when the peers really are on this machine. This is the same posture the framework takes everywhere: we do not second-guess a declaration, and we do not treat a fallback as one.
-
-  Measured between two real replicas (`scripts/fleet-observation-e2e.mjs`): A answers for B, B's identity survives the hop, an unknown id is refused with no outbound request, and a mutating endpoint is refused with `400`.
-
-  **And the consumer that nearly shipped broken.** Both dashboards unwrap the envelope in their single fetch helper; the CLI's `inspectFetch` — which thirty-odd subcommands read through — was missed. `voltro cluster status`, `voltro logs`, `voltro schedules` would each have read `undefined` off an envelope and printed an empty table. Found by asking what ELSE reads these routes, not by a failing test, which is why the seam now has one: the payload comes out, the envelope is kept so a command can say "1 of 3", an answer that predates the envelope passes through unchanged, and a payload that merely HAS a `data` key is not mistaken for one.
-- **@voltro/cli** — **`/_voltro/inspect/stream` events carry `origin`.**
-
-  A live SSE stream is the same defect as an unlabelled `/logs` response, except it keeps producing it: a viewer watching a tail on a three-replica fleet sees one third of it, continuously, and the connection landed on whichever replica the load balancer chose.
-
-  On **every event**, not on a handshake — because a consumer that connects late never receives a handshake. A reconnect, a second browser tab, a `curl` piped into `jq` all read the buffer, and a handshake they never saw would leave every buffered line unattributed. That is the assertion the test pins.
-
-  `ts` is that replica's clock. Two origins must not be ordered by it, which is the same rule `events.origin` already states as "serials are only comparable within it".
-- **@voltro/devtools-ui** — **A Fleet panel, in both dashboards.** `FleetPage` renders what every replica published about itself — the self-hosted DevTools wire it over HTTP, the hosted customer console over the cloud RPC proxy, from one shared component.
-
-  **It renders THREE populations, and the two after the first are the point.** A page that shows only the replicas which ANSWERED is worse than no page: the reader now believes they asked everybody. So the silent replicas get their own section rather than being omitted ("not shown" and "not there" look identical and mean opposite things), and the stale ones are shown WITH their age (filtering them makes a partial answer look complete; leaving them unmarked presents old numbers as current). A mixed-version note appears when the responders disagree, because a rolling deploy means the numbers span two shapes.
-
-  The completeness banner is a RATIO — "3 of 5 replicas answered" — not a count. A count invites the reader to believe that is the fleet.
-
-  **Two guards, one per dashboard, because neither repo can see the other.** Each fails when a page the shared package exports has no nav entry in that dashboard, with a declared exemption list whose stale entries also fail. The asymmetry is the argument: the self-hosted dashboard is opened daily and the customer one is opened when something is wrong, so a panel missing from the second fails in the direction nobody notices.
+  Selective by ordinary means: `app.config.ts` is TypeScript, so `sourcemaps: process.env.CI ? { … } : 'hidden'` emits-and-keeps locally and uploads in the pipeline. `keep` defaults to "keep them only if nothing consumed them" — false with an upload, true without.
 
-  **Measured in a real browser** (`voltro-devtools/scripts/fleet-panel-browser-check.mjs`): two replicas behind one dashboard, the panel renders BOTH, the nav link resolves (a page reachable only by typing a URL is not a panel), and the console is clean. That check immediately earned itself — it caught a `<div>` inside `CardDescription`'s `<p>`, invalid HTML that React reports only in a browser and that the page's own jsdom suite passed over.
+  **There is no `authToken` option**, on purpose. It is read from `SENTRY_AUTH_TOKEN`: `app.config.ts` is a committed file, and a token with `project:releases` scope can write to every project in the org. It belongs to the build, not the deployment.
 
-  The devtools-ui catalogue also gained an en/de parity test. English is the fallback, so a missing German string does not crash — it renders English in a German console, which looks like a working UI rather than a hole.
-- **@voltro/cli, @voltro/runtime** — **Four serving changes: pre-compressed assets, a CDN prefix, a keep-alive that survives a proxy, and a preconnect for a cross-origin api.**
+  The upload runs through `@sentry/cli` rather than a hand-written HTTP client, because Sentry's artifact model is debug-ID based — the ids are injected into the built JS and the map, and the matching happens on them. An uploader that skipped that injection would produce artifacts that upload cleanly and resolve nothing. **You install it: `pnpm add -D @sentry/cli` in the web app.** The framework does not depend on it anywhere, and that is a licence decision rather than a packaging one. `@sentry/cli` is FSL-1.1-MIT, which restricts competing commercial use — so unlike the MPL and LGPL dependencies we do carry, "the consumer's own install fetches it, and we neither distribute nor modify it" does not answer the question: FSL binds a user, not a distributor. An optional dependency of a package we publish is part of that package's licence surface, so it is not one.
 
-  **Pre-compression (automatic).** `voltro build` writes `.br` (quality 11) and `.gz` beside every content-hashed asset over 1 KB; `voltro start` serves the variant when the client accepts it. Before, every hit compressed from scratch — measured on one 321 KB chunk, three requests each:
-
-  | | time | bytes | |---|---:|---:| | compressed per request | 5.6 / 5.0 / 4.6 ms | 100 665 | | pre-compressed | 1.6 / 1.7 ms | **86 083** |
-
-  Faster and smaller at once, because a build can afford q11 where a per-request path cannot (the runtime uses q4 precisely so it never stalls a response). Only hashed assets get variants: a stale `.br` beside a changed original is a corrupted response rather than a slow one. The `ETag` is computed over the UNCOMPRESSED file and passed through, so brotli, gzip and identity share one tag — the invariant `httpResponseWrite.ts` states, which hashing the variant would have broken.
-
-  **`web.assetPrefix`.** Becomes vite's `base`, so every emitted URL is written with the prefix at build time. Without it an app with a single `ssr` route serves every byte of its bundle from the container — `voltro static`, the documented cost-offload, only applies to an app that is entirely static. Verified on a fixture: all ten asset URLs in the shell AND in every pre-rendered page carry the prefix.
-
-  **`http.keepAliveTimeoutMs`, default 72000.** Node hangs up an idle keep-alive connection after **5 seconds** — confirmed on a running server (`Keep-Alive: timeout=5`) — while nginx holds one for 75s and ALB/Envoy for 60s. The proxy then sends onto a socket the server is closing and answers 502. Rare per request, certain over time, and invisible in testing. `headersTimeout` is derived above it and a declared value at or below `keepAliveTimeout` is RAISED rather than applied: node measures it from connection start, so honouring it would destroy healthy connections. Applied on both serving surfaces from one resolver. Verified: `Keep-Alive: timeout=72`.
-
-  **`preconnect` for a cross-origin api.** When an api's `wsUrl` is on another host the shell carries `<link rel="preconnect" … crossorigin>`, so the handshake overlaps the bundle download instead of following it. Same-origin apis emit nothing — the browser already has that connection, and a redundant hint costs a wasted socket. `crossorigin` is required: without it the warmed connection is anonymous and the credentialed one the socket needs is a second handshake.
-
-  **`web.sourcemaps: 'hidden'`.** Emits `.map` files with no `//# sourceMappingURL` comment. `plugin-sentry` reads `SENTRY_RELEASE` explicitly "for release health AND source maps" and there was no way to produce any, so every production stack trace was minified — from an integration advertising the opposite. Off by default, and named for what it does rather than being a boolean.
-
-  **And `voltro start` now refuses to serve a `.map` at all**, whether or not one is on disk. The docs say to upload the maps and delete them before the image is built, and "say" is not a mechanism: a hidden map is undiscoverable but perfectly REACHABLE — its URL is the chunk's own name plus `.map`. One forgotten deploy step would publish the app's source. 404, not 403, because a 403 confirms the file exists. Red-verified: with the refusal removed, the same request returns **200 and the map's contents**.
-- **@voltro/i18n, @voltro/cli** — **`<LocaleSwitcher>` now ships unstyled from `@voltro/i18n`, and `voltro doctor` reports the failure that made it necessary.**
-
-  Counted across the shipped templates: 16 declared `@voltro/ui-shadcn`, and **13 of them never imported `@voltro/ui-shadcn/tokens.css`**. The only kit component they used was `LocaleSwitcher`, which is `h-9 rounded-md border border-input bg-transparent px-2 text-sm shadow-xs …` and nothing else. Tailwind v4 emits a utility only when a CSS entry declares it, and the kit deliberately does not import its own stylesheet (the app owns its CSS entry) — so every one of those class names referred to a rule that did not exist. The control rendered as a bare `<select>` with dead `class` attributes, in templates whose own docs say they do not use the kit.
-
-  Nothing could have caught it: `voltro build` succeeds (a missing utility is absent bytes, not an error), `tsc` succeeds (the import is real), and the page renders.
-
-  Two changes:
-
-  - **`@voltro/i18n` exports `LocaleSwitcher`** — the same behaviour (writes the `voltro:locale` cookie, reloads, `onChange` can suppress the reload) as a native `<select>` you style yourself. It belongs here for the same reason `LOCALE_COOKIE` already moved here: an app on the framework's i18n and not on the kit had no way to reach it. `@voltro/ui-shadcn`'s styled version is unchanged. - **`voltro doctor` reports a kit rendered with no stylesheet** — advisory, and it names the offending files. Quiet when the app imports `tokens.css`, quiet when the app declares Tailwind itself, and quiet on a `import type` (which emits nothing and therefore cannot produce a class attribute).
-
-  The 13 templates now import the unstyled control and no longer declare `@voltro/ui-shadcn` at all — which also drops that package's `shiki` dependency from every one of them.
-
-### Changed
-
-- **@voltro/content, @voltro/ui-shadcn, @voltro/cli** — **The production bundles carried 308 syntax grammars and three cloud SDKs for apps that asked for none of them.**
-
-  Both shiki callers already restricted their languages correctly — `@voltro/content` to nineteen, `@voltro/ui-shadcn` to eighteen — at RUNTIME. A bundler cannot read a runtime list, and the `shiki` barrel maps all 700+ of its languages to their own dynamic import, so every one was emitted as a chunk. Measured, by intersecting the emitted filenames with `@shikijs/langs` + `@shikijs/themes`: **6.67 MB across 308 files, in BOTH the api serve bundle and the web start bundle**. In a browser bundle it is the same set: an app rendering one `<HighlightedCode>` made 308 chunks reachable.
-
-  Both now build from `shiki/core` with the grammars and themes imported by name. Every specifier stays dynamic and node-gated — `shiki` is an optional dependency and `@voltro/content` is isomorphic, so a static import would both break an app that never renders markdown and put the highlighter in the browser graph of anything importing `renderMarkdown`.
-
-  The same shape, one layer out: the api serve bundle also carried the Azure Blob SDK (604 KB) and `@react-email/render` + `react-dom/server` (972 KB) for a fixture that declares one plugin and neither storage nor mail — they arrive through `@voltro/cli`'s own dependencies on `plugin-storage` / `plugin-mail`. Each is already reached by a dynamic import inside its plugin and is an optional peer of it, so each joins the runtime-external list beside `ioredis` and `nodemailer`: an app that configured the provider resolves it from its own `node_modules` at boot, one that did not never ships it.
-
-  Measured end to end, on the reference fixtures:
-
-  | | before | after | |---|---:|---:| | api serve bundle | 26.9 MB / 535 files | **5.72 MB / 138** | | web start bundle | 13.59 MB / 427 files | **1.48 MB / 39** |
-
-  Both are pinned now (`bundle-budget.mjs --artifacts`), in bytes AND in file count — 427 is a number somebody notices, where "13.6 MB" reads as "it is a bundle".
-
-  Highlighting is unchanged and verified through a real build: the docs site's pre-rendered pages still carry `class="shiki shiki-themes github-light github-dark-dimmed"`.
-- **@voltro/cli** — **The artefacts that exist to collapse a cold boot were shipped unminified — and nothing enabled node's code cache.**
-
-  `VOLTRO_BOOT_TIMING=1` says where a boot goes, and the answer is the phase the bundles were built for: `modules` (node init + loading the precompiled bundle) is **46 %** of a `voltro start` and **65 %** of a `voltro serve`. V8 parse time tracks bytes, and neither `webStartBundle.ts` nor `apiBuild.ts` set `minify`, while vite leaves an SSR build unminified by default.
-
-  Both are on now, plus `enableCompileCache()` in the launcher. Measured on the reference fixtures, five fresh processes each, median:
-
-  | | before | after | |---|---:|---:| | `voltro start` boot | 166 ms | **83 ms** | | `voltro serve` boot | 287 ms | **222 ms** | | start bundle | 13.59 MB | 11.75 MB | | serve bundle | 26.9 MB | 18.25 MB | | `dist/server/ssrEntry.js` | 1.91 MB | 0.85 MB |
-
-  `keepNames: true` is not optional and is the one thing to preserve if you touch this: Effect's tags, error `name`s and the boot-refusal marker (`bootRefusal.ts`) are compared as STRINGS across the bundle boundary, and a mangled class name turns a precise refusal into an anonymous one. It costs a few percent of the saving and buys back every diagnostic the bundle exists to keep.
-
-  The compile cache is only enabled when `NODE_COMPILE_CACHE` is unset, so an operator's directory always wins. In a scale-from-zero container the OS temp dir starts empty, which is why the shipped standalone Dockerfiles point the variable at a directory the image BAKES during its boot smoke — the run that was already happening.
+  A configured upload with the package absent refuses the build and names the command, rather than skipping the upload and leaving you to discover months later that no frame resolves.
 
 ### Fixed
 
-- **@voltro/database** — **Two replicas booting at once against a schema with work to do killed one of them.**
-
-  `applyPlan` takes the migration advisory lock, so two writers cannot execute at the same time. What it did not do was ask again once it held the lock. Both replicas plan against the same live state, then queue; the winner applies, and the loser wakes holding a plan for a database that no longer exists:
-
-  ```
-  ═══ applier: statement failed (op=add-check) ═══
-  statement: ALTER TABLE "actors" ADD CONSTRAINT "actors_kind_check" …
-  db.message: constraint "actors_kind_check" for relation "actors" already exists
-  dev server exited — supervisor stopping   exitCode: 1
-  ```
-
-  A classic time-of-check/time-of-use: the lock serialised the apply and did not protect what the apply rests on. It self-heals — the pod restarts and finds the schema applied — so what it looked like in production was one crash per replica on every deploy against a schema that had work to do, on a plan that was correct when it was made. A cold fleet start is exactly when every replica has work to do.
-
-  The first thing under the lock is now `ctx.replan` — the same hook the convergence proof uses at the other end, required for the same reason (only the caller knows the planner inputs). Everything downstream reads the re-planned set: the operations, the resume ledger's comparison, and the recorded fingerprint. Using the stale one for any of those would record that a replica applied work it did not.
-
-  Where the plan is already current — the ordinary case, nobody raced — the re-plan returns what was passed in and costs one introspection. `applyPlan` is not called at all for an empty plan, so that cost lands only where there was real work.
-
-  A plan that becomes blocked under the lock is refused as loudly as one that started blocked; the pre-lock check judged a different set.
-- **@voltro/cli** — **A proven change-stream gap now drops the cache, not only the live queries.**
-
-  Re-running every live subscription repairs what a subscriber sees, and that is the half you look at. Cache invalidation rides `store.onChange` — so while the stream was down, nothing was invalidated — and the dispatcher's recompute re-seeds only the entries a LIVE subscription owns. Everything else keeps serving pre-gap rows until its TTL: a `ctx.cache` read, an ISR page, a cached query nobody is currently subscribed to. On a replica that has just announced, in its own log, that it knows it was behind.
-
-  The recovery now evicts every registered table before refreshing. Blunt for the same reason `refreshAll` is blunt — we do not know which tables the lost changes touched, and guessing narrower is how the silent staleness comes back. Cache first, then the queries: the recompute reads the store directly and writes its result back, so dropping afterwards would throw the fresh rows away again.
-
-  Both boot paths, through the shared builder, with the parity asserted.
-- **@voltro/cli** — **`voltro start` sets `Cache-Control`. It sent none at all.**
-
-  Measured against a running production server, on a chunk whose FILENAME carries its content hash:
-
-  ```
-  $ curl -D - http://localhost:5399/assets/index-7N08IhkU.js
-  HTTP/1.1 200 OK
-  content-type: application/javascript
-  vary: Accept-Encoding
-  content-encoding: br
-  etag: W/"4bff20f74ba2a65fde4443acd7ed80b6"
-  ```
-
-  No `cache-control` and no `last-modified`. RFC 9111 derives heuristic freshness from `Last-Modified`, so with neither header a browser has nothing to reason about and revalidates. The reference fixture's first load is an entry plus nine `modulepreload`s — ten conditional round-trips before the page is interactive, on every visit, for files that by construction can never change. A CDN or reverse proxy in front of the container could cache nothing at all, for the same reason.
-
-  The framework already knew the rule: `plugin-storage` serves its public objects with `public, max-age=31536000, immutable` and `plugin-atlassian` its avatars. Only the arm serving our OWN chunks had no policy.
-
-  Now, from one place (`staticCachePolicy.ts`, so the arms cannot disagree): content-hashed assets get a year and `immutable`; anything else out of `public/` gets an hour; a pre-rendered page gets `max-age=0, must-revalidate`, which the existing ETag answers with a `304`.
-
-  Nothing gets an `s-maxage` by default — a shared cache holding HTML past a deploy serves the previous build's asset URLs, and there is no purge hook to fix that. An app that owns its CDN opts in through the new `http.cache` block (`htmlSMaxAgeSeconds`, `isrShared`, and both lifetimes; `immutableMaxAgeSeconds: 0` turns the immutable header off entirely).
-
-  The hash detector is the part with an edge: it requires `/assets/` AND a `-<6..12 chars>` suffix, so a hand-named `page-2.js` is never frozen for a year — a mistake that cannot be undone without renaming the file.
-- **@voltro/plugin-row-history** — **`timing: 'post-commit'` recorded one history version per replica, with different version numbers.**
-
-  The in-transaction timing is safe by construction: the writing replica records the entry inside its own transaction and the tap returns early. Post-commit has no such writer — on a `changeScope: 'fleet'` store the injected event reaches EVERY replica and each one calls `recordChange`.
-
-  It did not surface as a conflict. `recordChange` numbers a version as `MAX(version) + 1` and derives the row id from it, so two replicas both computed version 1, one won the primary key, and the loser's RETRY re-read MAX, got 2, and appended a SECOND entry for the same change. That retry exists for a genuine concurrent write to the same row and cannot tell that case from this one.
-
-  Measured with the gate removed: three replicas, one change, versions `1, 2, 3`; two replicas, three changes, `1, 2, 3, 4, 5, 6`. Not merely doubled — mis-ordered, and `selectAsOf` / `sortHistory` / `diffVersionRows` all read `version`. A duplicate can be deduped; a wrong order cannot even be detected from the data.
-
-  The tap now claims each change fleet-wide before recording, through the same arbiter behind `defineSubscriber({ once })`. The key names the CHANGE, not the row: a row id would collapse two genuine edits to one row, and for a history trail a silently missing version is the worse direction.
-
-  Nothing to configure. `timing: 'in-transaction'` is unaffected — it never had this.
-- **@voltro/sql-postgres, @voltro/database, @voltro/cli** — **A postgres replica no longer goes permanently deaf when its LISTEN connection drops.** Under `changeStrategy: 'cdc'` — the multi-replica default on postgres — the CDC consumer holds one dedicated connection. `@effect/sql-pg` registers a no-op `client.on('error')` on it, so when that connection dies the socket error is swallowed, the stream neither fails nor ends, and the fiber draining it stays alive forever. Nothing throws. Nothing is logged. No fiber dies.
-
-  Measured against a live server: kill the backend holding the LISTEN, write from another connection, wait twenty seconds — nothing arrives. Every subsequent change from every other replica is lost too, until the process restarts. A failover, a proxy recycling an idle socket, an admin `pg_terminate_backend`, or the database pod restarting all produce it, and none of them touch the app process, which is exactly why the app process did not notice.
-
-  The consumer now carries a watchdog. It cannot wait for an error — there is none — so it probes: after silence on the channel it sends a `pg_notify` through the pool and requires the echo back on the LISTEN stream. Any traffic counts as the answer, including another replica's probe, so a busy channel never pays for one and a fleet pays roughly one probe per idle window however many replicas it has. An unanswered probe means the connection is dead; the consumer re-opens it, retrying with backoff, and does not declare success until it has heard its own heartbeat come back.
-
-  **And the reconnect declares a gap**, which is the half that makes it a recovery rather than merely a pulse: postgres queues nothing for a listener that is not there, so every change written during the outage is gone. Stores expose that through a new optional `DataStore.onChangeStreamGap`, and both `voltro dev` and `voltro serve` wire it to the same refresh the broadcast bus's gap already used — re-run every live query, which is safe and complete because a query is idempotent.
-
-  `VOLTRO_CDC_HEARTBEAT_MS` (default 20000) and `VOLTRO_CDC_HEARTBEAT_TIMEOUT_MS` (default 10000) tune it.
-
-  `apiSurface: compatible`: `PostgresDataStore`'s constructor gains a TRAILING OPTIONAL parameter (`cdcLiveness`), which the golden renders as a changed line. Every existing call still compiles — the store is built through `makePostgresDataStore` in any case.
-
-  The mysql binlog reader has had an error-driven reconnect and a watchdog for a silently-dead stream for some time. This is the postgres half of the same idea, on the dialect the documentation steers people to.
-- **@voltro/plugin-broadcast, @voltro/cli** — **A change delivered by the database was re-published onto the broadcast bus, and the amplification was quadratic.**
-
-  On a dialect with a native change transport — postgres LISTEN/NOTIFY, mysql binlog — the store injects every change on EVERY replica; that is what makes the transport cross-instance in the first place. `@voltro/plugin-broadcast`'s outgoing listener then published those injected events again, under its own replica's origin, which is not own-origin for any peer. So every peer injected the change a second time.
-
-  Per change, with N replicas: N deliveries from the transport, N publishes onto the broker, and N(N-1) more injections from the peers — **N² local deliveries**. Every consumer of the change stream paid it: every `*.subscribe.ts` handler, every live-query wake, every plugin tap, every cache invalidation. At two replicas a subscriber's handler ran four times for one `INSERT`, twice per instance — and the per-instance half needs no cluster to reproduce, which is why it does not read as a clustering problem.
-
-  The suppression required the bus to be mid-inject (`injecting && …`), which only ever covered the bus's own echo. It is provenance alone now: an event stamped `origin: 'injected'` reached this process through some transport, and forwarding a transport delivery to a second transport is the amplification. A local publish that states `origin: 'inline'` — `publishReactivity` does — is still published, so reactivity channels keep crossing replicas.
-
-  The boot banner said the same thing the code did. It used to read `both paths active (own-origin skip dedups)`; it now names what each path carries:
-
-  ```
-  reactivity: native LISTEN/NOTIFY (postgres) carries table changes;
-  @voltro/plugin-broadcast (redis) carries reactivity channels
-  ```
-
-  Nothing to change in an app. If you run postgres or mysql with a broadcast plugin, the duplicate deliveries stop on upgrade.
-- **@voltro/cli** — **`voltro db plan --json` and `voltro db drift --json` were silently truncated when piped.** `fs.writeSync` is not "write this"; it is "write as much as the fd accepts right now, and return how much that was". On a file that is everything — which is why `> plan.json` worked and every manual check passed. On a pipe the kernel takes one pipe buffer, 64 KiB, and the rest is simply not written.
-
-  A plan crossing 64 KiB therefore reached `| jq`, or a CI step capturing the command, as exactly 65 536 bytes: valid JSON up to the cut and a parse error after it. It reads like a malformed plan and it is a malformed read — and the documented production route is to review that JSON and apply it.
-
-  The line it replaced carried a comment saying `writeSync` "always flushes", written as the fix for the previous version of this same bug (`console.log` to a non-TTY is block-buffered, and `process.exit` dropped the buffer, so `--json` emitted *nothing*). That fix was right about `console.log` and wrong about its replacement, turning "nothing on a pipe" into "the first 64 KiB on a pipe" — the more dangerous of the two, because an empty output is noticed at once and a truncated one is noticed by whoever parses it later.
-
-  `writeAllSync` loops over partial writes. Its test spawns a child with a real pipe, because on a file the defect does not exist.
-- **@voltro/plugin-search** — **The search panel could over-count a fleet's sync stats, because the plugin derived its replica id instead of using the one it was handed.**
-
-  `_voltro_search_stats` keeps one row per replica and aggregates on READ: SUM under `changeScope: 'local'` (each replica counted a different slice) and MAX under `'fleet'` (every replica received the full stream, so each row is already a fleet-wide count — summing three of those is the 3× inflation the design exists to avoid).
-
-  That only works if the rows are actually per replica. `dataStoreStatsStore` takes the id as a parameter and the plugin never passed one, so it fell back to the process global — which is correct in production and made the identity undiscoverable to the plugin's own configuration. The id now comes from `PluginBindContext.instanceId`, the same value the event bus stamps and the membership registry announces under, and the reason the context carries it.
-
-  Found as a red test rather than by reading: the fleet-stats case simulates three replicas in one process, which it used to do by setting `VOLTRO_REPLICA_ID` around construction. Once process identity became memoised — one process, one identity — all three "replicas" shared an id, wrote to one row, and the panel reported 3 where the case asserts 1. The property was right and the simulation had become impossible to express; taking the id from the context makes it expressible again, through the same seam production uses.
-- **@voltro/cli** — **`voltro build` could not produce a serve bundle for any app declaring `@voltro/plugin-sentry`** — 35 errors, all `No loader is configured for ".node" files`, and a `fatal: serve bundle build FAILED — refusing to ship a bundle-less image`.
-
-  `@sentry/profiling-node` reaches `@sentry/node-cpu-profiler`, which `require()`s a per-platform `.node` binary. It is the strongest possible case for the native-leaf list — BOTH of that list's reasons at once, a compiled binding that cannot be inlined AND a `await import(…)` behind a `profiling: true` flag that already degrades to a warn when absent — and it was simply never added.
-
-  **The second half is why adding the leaf alone would not have fixed it.** The runtime shim resolves a leaf from a chain of roots: the declared SQL drivers, then `@voltro/cli`, then the app root. An optional peer lives under the plugin that dynamic-imports it, and pnpm strict does not hoist it — so `@voltro/cli` covers the peers of the plugins the CLI itself depends on (mail, storage) and nothing else. `@sentry/profiling-node` is an optionalDependency of `@voltro/plugin-sentry`, which the CLI does not depend on, so no root in the chain could have found it at runtime.
-
-  The chain now includes **every `@voltro/plugin-*` the app declares**, derived from its `package.json` rather than listed. A hard-coded plugin list is the shape that produced the gap: correct until the next plugin ships an optional peer, and silent when it does.
-
-  Found by the first `--build` run of the template harness. `voltro test` transpiles and `tsc --noEmit` typechecks; neither runs a build, so an unbuildable template stays green in both.
-- **@voltro/protocol, @voltro/cli, @voltro/plugin-ratelimit** — **Two defaults that are correct for one process and silently wrong for several now say so.** Neither default changes — a process-local store is right on one process, and demanding Redis to run a single instance would be worse. What was missing is the deployment noticing.
-
-  - **The rate limiter.** `rateLimitPlugin` defaults to a process-local counter, so `100/min` on five pods is 500/min. That is not a performance detail: a limiter is usually what stands between an endpoint and abuse, which makes this the one default whose silent multiplication has a security consequence. - **Read-your-writes.** The RYW position store defaults to a process-local Map. With `DB_REPLICA_URLS` set, read-your-writes then holds only when the next request happens to land on the same pod — a user saves, the load balancer sends them elsewhere, and that pod routes the read to a lagging replica and serves the row as it was before the write. The boot line said `ryw policy 'fallback'` as though the policy were in force.
-
-  Both warn on the same signal the reactivity audit already used (`replicaEvidence`: `POD_NAME`, `FLY_ALLOC_ID`, `K_REVISION`, … and an explicit `REPLICA_COUNT` as a declaration in both directions), and each names the way out.
-
-  `replicaEvidence` moves to `@voltro/protocol/identity` — it began in the CLI, a plugin cannot import the CLI, and copying twenty env names is how one question acquires three answers. It is still exported from its old place.
-- **@voltro/cli** — **The outbox runner's shutdown could settle the wrong pass.** `close()` awaits the in-flight drain rather than truncating a delivery mid-flight — that is the half of the shutdown gap a `clearTimeout` cannot cover, and it was already tested. What it awaited was `inFlight`, which `kick()` overwrote on every call including one that immediately returned because a pass was already running. So `close()` could await a promise for a pass that never ran while the real one was still inside its handler, and the next step of the real shutdown sequence is `store.close()`.
-
-  The window only opened when a second kick landed inside the first pass, which is why it survived: it took adding one round trip to the drain to widen it enough for the existing settle test to catch. An early-returning pass now hands back the pass it deferred to, so `inFlight` always names real work.
-
-  Found by a test that was already asserting the right thing and had been passing for the wrong reason.
-- **@voltro/protocol, @voltro/runtime, @voltro/cli, @voltro/voltro** — **A peer that restarted stopped being heard by reconnecting clients.** `EventEnvelope.origin` says what it is — *"Publishing instance. Serials are only comparable WITHIN one origin"* — and both boot paths handed it the replica NAME. A name survives a restart; a serial does not. A StatefulSet pod keeps its `POD_NAME` and `VOLTRO_REPLICA_ID` is stable by definition, so a restarted peer publishes serials 1, 2, 3… under an origin whose watermark still reads 500.
-
-  Two silent losses follow from that one stale number. The watermark never advances, so a reconnecting client is told it missed nothing; and the resume replay filters by `n > lastSeen`, so the new process's events are dropped from the replay entirely. The peer is publishing normally the whole time.
-
-  The event bus now keys on `instanceId()` — `<replicaId>@<startedAt>.<nonce>`, newly exported from `@voltro/protocol/identity`. It carries the replica name as its prefix, so correlating the subsystems across pods still works.
-
-  `apiSurface: compatible`, and it covers a second thing: regenerating the goldens caught up drift the fleet-observation work left in the `@voltro/voltro` AGGREGATES, which are re-exports and so do not regenerate when their source package does. The one changed line there is `checkFrameworkCompat`, whose `runningVersion` parameter WIDENED to `string | undefined` and whose success result gained an optional `unverified`. A widened parameter accepts every call that compiled before; an added optional field breaks no reader.
-
-  The membership registry deliberately keeps the NAME: it detects a restart by comparing `startedAt` under a stable id, and a per-process id would turn every restart into a join plus a silent leave.
-- **@voltro/cli, @voltro/database** — **`_voltro_idempotency` grew without bound, and its own documentation said it did not.**
-
-  The table's doc comment claimed "a periodic sweep / lazy-TTL drops rows past their window". The lazy TTL is real and fires only when the SAME key is claimed again — and an idempotency key is used once by definition, so the row it leaves behind is never read and never deleted. There was no periodic sweep at all: the table was the one member of its family with no entry in the retention registry.
-
-  It has one now, and the TTL is a FLOOR rather than a setting that can be turned down. A record dropped while still inside the app's own dedup window would let the duplicate request it exists to stop execute a second time, so `VOLTRO_IDEMPOTENCY_TTL_HOURS` may lengthen the window and may not shorten it below the app's `idempotency.ttlMs` plus a clock-skew margin. When it asks for less, the floor wins and the boot says so — a silently-ignored setting is worse than a refused one.
-
-  The reaction rate-limiter's slot rows used to live in this table too and now use `_voltro_change_claims`, whose window is an hour rather than the idempotency window. Two row families with different lifetimes cannot share one retention policy: the registry is keyed by table, so one table carries exactly one TTL.
-
-  Also corrected: the table is created for EVERY sql app (`when: 'always'`), not "only when `idempotency` is set in `app.config.ts`" — that is what the config gates, not what the table registry does.
-- **@voltro/plugin-presence** — **`usePresence` re-announced its membership on every render, which is a write loop.** Measured on a real page against a real api, ONE page load, a fresh browser context: **~9 300 uncaught `RateLimited: presence.heartbeat` pageerrors in 3.5 seconds** — about 2 700 per second, and the same rate of mutations arriving at the server. The 60/min rate limiter was the only thing standing between this and an unbounded write loop.
-
-  `meta` sat in the join effect's dependency array, and the documented way to call the hook is an inline object:
-
-  ```tsx
-  usePresence('room', { key: me.key, meta: { name: me.name } })
-  ```
-
-  which is a new identity every render. So: leave → join → roster push → re-render → leave → join → … The hook already refd its two mutations for exactly this reason and left the one caller-supplied value in.
-
-  `meta` is refd now, so the interval always sends the CURRENT value, and the join effect is keyed on the membership identity only — a metadata change publishes immediately through a separate effect instead of tearing the membership down and re-announcing it. A serialisation failure degrades to "publish at the next beat" rather than throwing: a roster is not worth a render crash.
-
-  **Nothing in this package could have seen it.** Closing the loop needs a REAL subscription pushing a real roster back; a mocked transport re-renders once and stops. So the regression test asserts the property that BREAKS the loop — an equal-but-new meta object does not re-announce — and was falsified first: with `meta` back in the deps, two re-renders produce three heartbeats instead of one.
-- **@voltro/protocol, @voltro/runtime, @voltro/cli, @voltro/plugin-billing, @voltro/plugin-search** — **One process, one identity.** `replicaId()` / `processIdentity()` from `@voltro/protocol/identity` is now the only place the framework decides which replica it is running as. It was an expression, sixteen times, in three packages, in FOUR spellings — and the spellings disagreed.
-
-  Two ignored `POD_NAME` entirely and read `HOSTNAME` alone; one read `HOSTNAME` *before* `POD_NAME`; only one honoured the explicit `VOLTRO_REPLICA_ID` override. The variants landed in different subsystems: the `HOSTNAME`-only one stamps `_voltro_schedule_runs.replicaId` and `claimedBy`, while the `POD_NAME`-first one answers `/_voltro/inspect/cluster`.
-
-  **So a single inspect response could name the same pod twice, differently.** `instance.replicaId` came from one spelling; `coordinationState.recentReplicaIds` — read back out of the schedule-run rows — came from the other. A dashboard asking "which of these is me" found itself in neither list. The doc comment on that field asserted the two were the same id; it is now true rather than aspirational.
-
-  This matters beyond tidiness: every aggregation across replicas groups by this id, and grouping by an id that depends on which subsystem wrote it is worse than not aggregating at all.
-
-  The identity says four things, because two of them were missing:
-
-  - `replicaId` is the PLACE in the fleet and survives a restart; `instanceId` carries the GENERATION and does not. Conflating them made "one pod restarted forty times" and "there are forty pods" the same number. The generation carries a nonce below the clock's resolution — two generations starting in the same millisecond would otherwise collide, and an aggregation keyed on it would merge two processes into one. - `version` is what this process runs, for the window in which a rolling deploy makes the fleet genuinely mixed. `undefined` when it cannot be determined — never a plausible-looking `0.0.0`, which two of the old resolvers returned and which compares equal to another unknown. - `reachableAt` / `reachable` record where a peer could reach this process, with loopback recorded as NOT reachable — the same distinction `resolveRunnerIdentity` already draws as `localhostRisk`.
-
-  **The framework VERSION had the same disease, with sharper teeth.** Three resolvers: two hunted for `package.json` relative to their own module, and one read `npm_package_version` — the APP's version when started through an npm script, reported as the framework's. The manifest hunt cannot work inside a bundle, where the framework is inlined and `../package.json` belongs to whatever sits there, so a bundled `voltro serve` fell into its `catch` and reported `'0.0.0'`: right under `voltro dev`, wrong in production, which is the one place nobody can go and read it out of the source tree.
+- **@voltro/database, @voltro/protocol, @voltro/runtime, @voltro/sql-mysql** — A write the FRAMEWORK refuses now reaches the caller as a typed `ConstraintViolation` instead of a defect.
 
-  And `'0.0.0'` PARSES. It reached `checkFrameworkCompat`, where every plugin declaring a `framework:` range was judged incompatible against a version nobody was running — a warning on every production boot, and a refused boot under `VOLTRO_STRICT_PLUGIN_COMPAT`. That check now treats an unreadable version as **unverified rather than incompatible**, and says so: absence of evidence is not evidence of a mismatch. `voltro build` writes the version into every server bundle's banner (one definition, three bundles — it was a repeated string literal, which is how the injection would have reached one and missed the others).
+  Every failure the DATABASE reports already had this: `storeMiddleware` reads the driver's error and maps it. A refusal the framework decides had nothing to map from — there is no driver code for our own decision — so it stayed a plain `Error`, which Effect classifies as a defect. It arrived at the client as a `Defect` wrapping a stringified `InternalError`, untagged, for a condition an app can genuinely branch on. A form shows a support id over an input that saved nothing.
 
-  **`mode` gained `'serve'`.** An api under `voltro serve` reported `'start'`, and `voltro start` is web-only — it refuses an api with "no web app found". The readout named a command the process could not have been started by, while `/members` reported `meta: { mode: 'serve' }` for the same process: one fact, two endpoints, two answers. It is now a projection of the resolved boot path, stamped on the function the production container command actually enters (`node serveEntry.js` calls `runServe` directly and never passes through the dispatcher — stamped one level up, a bundled serve reported `'cli'`).
+  The MySQL-family upsert raises one: `ON DUPLICATE KEY UPDATE` fires on whichever unique key the incoming row violates, so the store checks afterwards that it reached the row the caller's `conflictColumns` name, and rolls back when it did not. `unique` is the kind — a row did collide on some unique key of that table; what the engine will not say is which, and that silence is the reason the check exists, so `constraint` stays absent rather than guessed at.
 
-  Measured against a real bundled production serve, not inferred: `{"voltroVersion":"0.55.0","mode":"serve"}` where it previously read `{"voltroVersion":"0.0.0","mode":"start"}`.
+  `ConstraintViolation` gained an optional `detail`, populated only by these refusals and never from a driver message or a row value. The generated sentence exists because the driver's own text carries row data on several dialects; that is a rule about the DRIVER's sentence, not about length, and a sentence the framework authored carries exactly what we put in it.
 
-  `scripts/check-process-identity.mjs` (CI + `pnpm gate`) fails on any second derivation, and ships a `--selftest` that classifies eight shapes — the four that were really in the tree, plus four benign reads that must not trip it.
-- **@voltro/cli, @voltro/devtools-ui** — A sweep of all 31 dashboard pages in a real browser, against a running api, found four defects nothing else was looking for. None threw where a test could see it; three of them blanked a whole page.
+  The mark is read BEFORE the driver-parser and never folded into it: giving our own decision the fields `classifyConstraintViolation` reads would make the two indistinguishable inside the one function whose contract is "this is what the database said".
 
-  **A "structured empty" that was not the structure.** `/_voltro/inspect/database` answered `{ migrations: [], seeds: [] }` when the app had no snapshot to give, while `DatabaseStatus` declares `dialect` and `replication` as present. The page read `status.replication.replicaCount`, threw during render, and the Database page went blank with a console trace. A structured empty exists so a reader can render it WITHOUT branching; one that omits half the structure is a differently-shaped payload wearing the word. It answers the full shape now, and the panel tolerates the short one because a customer app on an older version still sends it — a dashboard that crashes on an old app cannot be used to diagnose one.
+  Not everything the store throws becomes a failure. An upsert whose conflict key cannot be looked up at all — every column database-GENERATED — stays a defect, because it is a call that cannot be served as written rather than a condition in the data, and typing it would invite an app to swallow a wiring mistake as though it were a busy row.
+- **@voltro/sql-mysql, @voltro/testing** — An upsert whose `conflictColumns` are NOT the primary key now works on MySQL and MariaDB. It threw, rolled back, and reported "Nothing was changed" — accurately, which is the only reason it was not worse.
 
-  **One endpoint, two shapes, depending on the app.** `/_voltro/inspect/metrics` answers with the runtime registry snapshot (`MetricSample[]`) for a web app and the rpc collector's aggregate (`{ windowMs, capturedAt, totalSamples, buckets }`) for an api — two unrelated types that happen to share the name `MetricSample`. The client declared the first for both, so `samples.filter` threw on every api app, during render, taking the overview down with it.
+  Postgres names its target (`ON CONFLICT (a, b) DO UPDATE`); MySQL and MariaDB have no such form, so `ON DUPLICATE KEY UPDATE` fires on whichever unique key the incoming row violates. `id` is excluded from the update — it identifies the row and must not be silently rewritten — so the store checked afterwards that the returned row was the one it aimed at, by comparing the returned `id` with the one passed in.
 
-  Which shape the endpoint should settle on is a wire decision and is NOT made here. `deriveMetricRows` returning nothing rather than throwing is not a decision: a derivation that cannot read its input must not take the page down.
+  That is the shape of the dangerous case, and it is also the shape of every correct update: an upsert that legitimately matches on the caller's own columns returns THAT row's id, never the freshly minted one. So the check fired on the case it existed to permit. The `op` classification one line below it (`id unchanged → insert, else update`) is written for a branch the throw made unreachable.
 
-  **A 500 for "this app has no workflows".** A framework table exists only when the app declares the feature that owns it, so a workflow read on an app with no workflows fails at the driver — and three handlers turned that into `500 … query failed`. "The server is broken" for a fact that is simply "there is nothing here". They answer the endpoint's own empty shape plus an `unavailable` reason now. The classifier matches the driver message per dialect, which is not something to build a control path on and is not one: it chooses between two ways of REPORTING, and an unrecognised message falls through to the 500 that was there before — the failure direction is always the old behaviour.
+  What decides it is the conflict-column VALUES, which are excluded from the update too and therefore still carry the matched row's own: equal to the input means the named key is what matched, and no other row can carry those values because the column set is unique. A difference means the statement was sent somewhere the named key could not have sent it — still refused, and the message now names the differing COLUMN instead of asserting a constraint it cannot identify. Not its values: that sentence reaches the client, and a conflict column is as likely to hold an email address as a team id — the same line `ConstraintViolation` draws when it refuses to carry the driver's own sentence. The values go to the server log, where the row already is. A conflict column the database GENERATES cannot be compared; when none of them can, that is said rather than resolved to "fine".
 
-  **And the reason the server sends is no longer discarded.** The inspect surface answers a dev-only path with a 404 whose body says "this endpoint exists and your deployment does not mount it… this is not a missing token" — a sentence written because a deployment reported the bare 404 as unreadable. The dashboard threw it away and rendered `[inspectClient] <url>: HTTP 404`, on six panels against every production app. The CLI's own inspect client had already fixed this exact blind spot and recorded that the fix belongs in the shared helper; this is the same helper on the browser side.
-- **@voltro/cli** — Two defects that produced a console error on every app page of the DevTools dashboard, found by a browser check and by nothing else — neither threw, neither changed a status code any test was watching.
+  The parity suite gained the case that was missing: every upsert scenario in it conflicted on `id`, so the returned id always equalled the one sent and a store could not be caught being wrong about this. It now upserts on a composite unique key from a fresh id on every dialect, with a second row that must NOT be overwritten.
 
-  **The live inspect stream did not exist under `voltro serve`.** `/_voltro/inspect/stream` was supplied by `dev.ts` and by nothing else, so the URL 404'd in production: the dashboard's log tail, its app-overview feed and the data viewer's CDC refresh all worked while you developed and were dead where it counted. The boot-path parity test had this on its EXCEPTION list, with the reason "there is no overlay" — true about the in-page dev overlay, and wrong about the surface, because the DevTools dashboard opens the same stream against whatever app is registered including a deployed one. An exception list is only as good as the reason on each line, and that line reasoned about one consumer of a surface with two. It is deleted, and the correction is written where it stood.
+  The LOOKUP half of the same operation — taken by every MySQL upsert, and on MariaDB by a partial row or a function `update` — now refuses clearly when a conflict column is database-GENERATED, instead of failing inside the driver.
 
-  The stream is now mounted by ONE builder both boot paths call (`buildInspectStreamWiring`) — the authorize/replay/subscribe quartet is a security surface carrying the DNS-rebinding host guard and the token resolver, and copying that into a second path is how one copy loses a guard. Serve feeds it the channel it genuinely owns (the subscription registry, via the same snapshot builder its HTTP path uses) and tears both down on shutdown: a stream that connects and never emits is worse than the 404 it replaced, because a silent feed reads as "nothing is happening".
+  It matches by value, and the value of a generated column is not in the row the caller passed: the classic partial-unique index on this engine IS such a column (a STORED expression plus NULL-distinct semantics, so the key constrains only the rows the expression marks). Binding the absent value reached mysql2 as `Bind parameters must not contain undefined` — a TypeError naming no column, no table and no cause, for a write that did nothing. Binding SQL NULL would make the predicate never true, so the lookup finds nothing and falls through to an INSERT the very key rejects; dropping the column would widen the lookup and can match a row the write would not have collided with, which is the one outcome that overwrites somebody else's data.
 
-  **The SSE proxy could only ever present its OWN token.** `EventSource` accepts no headers, so the browser cannot attach a per-app bearer the way every other inspect call does — the proxy fell through to the dashboard process's `VOLTRO_INSPECT_TOKEN`, which is the right token for an app that process minted and the wrong one for an app registered by URL. `voltro dev` mints a token per project, so that was every app, and the stream answered 401.
+  So it refuses, names the column, and points at the path that CAN answer: the single-statement form, where the database evaluates the expression itself. That path is reached on MariaDB with a complete insert row and a column-list `update`.
+- **@voltro/kv** — Closing a RESP client can no longer take the process down.
 
-  The token now travels as a same-origin cookie scoped to the proxy's own path, `SameSite=Strict`, cleared as soon as the stream opens — not a query parameter, because a bearer in a URL lands in every access log that touches it. It is moved into an Authorization header by the proxy and never reaches the target as a cookie. The precedence (caller's header → stream cookie → this process's own, loopback only) is resolved in ONE function both boot paths call; it had been written out in both, which is how a rule of this kind starts to differ.
+  A previous round added a silent `error` listener so an ioredis client without one could not crash the process. That is a different failure, and a deployment on `voltro dev` measured the difference: after the fix, roughly one reload in three still ended in `Error: Connection is closed.` thrown from `ioredis/built/redis/event_handler.js`, unhandled, with no framework frame in the stack.
 
-  **And a poll that ran before it knew what it was polling.** The app overview guarded its ISR-cache poll with `status === 'ok' && kind !== 'web'`, so while the status was still `pending` — i.e. before the app's kind was known — every api app fetched the web-only cache endpoint and took a 404. Twice, because the effect re-runs when the status settles.
-- **@voltro/cli** — **`voltro update` said the same thing about two opposite outcomes.** An update that changed nothing printed `codemods: nothing to apply for this jump` whether the jump ships no codemods at all, or ships several and every one of them gated ITSELF out through its own `appliesTo`. A reader takes the first meaning, because that is what the sentence says.
+  That is not an `error` event. `event_handler.js`'s `close` is where ioredis REJECTS the promises of commands that were in flight when the socket went — and `quit()` is one of those commands. Calling it on a connection that is already closing rejects, and `close: () => c.quit().then(() => undefined)` had no `catch`. A reload closes the client while the previous instance is still shutting down, which is the race.
 
-  The second is the state worth naming. A codemod's `appliesTo` is a predicate, and a predicate can be wrong in the direction that stays quiet: a gate reading the wrong files answers "does not apply" for a project that is fully affected. That has happened here — a `manual` codemod's gate searched the ts-morph project for a subject that only ever appears in a shell script or a CI job, which is why `codemodTextScan` exists. That fix made the GATE see more files; it did not make the SUMMARY admit a gate had run and said no.
+  `close()` now cannot reject, and falls back to `disconnect()` so giving up on the error does not mean giving up on the teardown — a `quit` that failed has not necessarily closed anything, and a socket leaked per reload is its own slow failure. Swallowing is right here and nowhere else in that file: a failed COMMAND reaches its caller as a `KvError`, because that is where it can be acted on, and a failed close has no such place.
+- **@voltro/plugin-broadcast** — A subscription's teardown can no longer kill the process.
 
-  So the summary now separates them: `none ship for this jump` when the range is empty, and otherwise the count plus every skipped id by name, with a line saying that a subject you recognise in that list is a bug in the check rather than a fact about your code. A partial run reports its skipped ones on one line for the same reason — two applied and one silently gated out reads as "all three considered and handled".
+  `void sub.unsubscribe(channel)` in the dispose function returned by the redis broadcast provider was fire-and-forget with no `catch`. ioredis rejects the promises of every command in flight when the socket closes — `Connection is closed.`, thrown from its own close handler — so a `voltro dev` reload, which disposes subscriptions while the previous connection is going away, produced an unhandled rejection and node killed the process.
 
-  **A claim this entry made in its first draft was wrong, and it is corrected here rather than quietly dropped.** It said the dialect half of the framework-table rule "was not covered below the planner at all", and announced a new MariaDB test as the fix. Both halves were false: `sql-postgres/__tests__/frameworkTableEvolution.integration.test.ts` and its `sql-mysql` twin have covered exactly this since the rule landed — on BOTH mysql engines, asserting a column RESHAPE (harder than the ADD the new test made), with a premise assertion, the outcome KIND, and convergence. The new test was deleted; it measured less than what was already there, in the wrong package.
+  This is the THIRD round on one symptom with three different causes: a client with no `error` listener, `quit()`'s unguarded promise, and now a discarded command. Each fix was correct and none of them was the next one, so this round adds a rule instead of a fourth fix: `scripts/check-resp-fire-and-forget.mjs` (CI + gate, with a `--selftest`) fails when a discarded RESP command has no `.catch`.
 
-### Internal (no consumer-facing effect)
+  The rule is deliberately narrow. The general property is `no-floating-promises`, which this repo has no eslint to run — and measured before writing it, a blanket `void <call>` rule matches **194** sites in `packages/*/src`, nearly all legitimate. The RESP subset matches 3, all correct. Widening the command list to "any method" costs the 194; the header says so, next to the number.
 
-- **@voltro/voltro** — **`packages/voltro` declares `lib: ["ES2024","DOM","DOM.Iterable"]` now, because it compiles `@voltro/i18n`'s source under its own options.**
+  The local half of the teardown still runs unconditionally: detaching the message handler is synchronous and cannot fail, and it is what stops a reloaded module receiving the previous one's messages.
+- **@voltro/runtime** — A schedule firing that is rejected before its handler runs no longer outlives itself. `runHandler` wrote the `running` row, armed the watchdog, armed the heartbeat, and only then built the app context — with the `try` whose `finally` releases all three starting after them. The context build is the one step in that window that can throw on input the scheduler does not control, and when it did, each acquisition survived in its own way:
 
-  The aggregate re-exports that package's ROOT entry — its browser half — so `tsc` follows the path mapping into `../i18n/src/**` and compiles those files with the AGGREGATE's compiler options, not the ones `@voltro/i18n` declares for itself. The moment i18n exported a component touching `document`, `@voltro/voltro#typecheck` failed with TS2584 while `@voltro/i18n#typecheck` stayed green: legal there, illegal here, one file. The aggregate already carried `jsx: react-jsx`, so this completes a decision that was half made.
+  - the watchdog rejected a promise `Promise.race` never received, `maxRuntimeMs` after a firing that never started. Nothing was listening, so the rejection went unhandled and ended the process — with no recorded failure in between to connect the two events. Lowering `maxRuntimeMs`, the obvious response to a run that appears stuck, only widened the gap; - the heartbeat kept stamping `heartbeatAt` on a run that had not begun. That beat is what tells a live run from a corpse, so it certified one: a peer's overlap guard reads a beating row as alive for the life of the process, turning a bounded stale window into a permanent skip for that schedule; - the `catch` never ran either, so the row stayed `running` — the only artefact the firing left behind, saying the opposite of what happened.
 
-  `apiSurface: compatible`, and this is the part worth stating rather than asserting. DOM declares `Notification`, `Option` and `Cache` as globals, so once they are in scope api-extractor must disambiguate the aggregate's own symbols from them — `interface Notification_2` + `export { Notification_2 as Notification }`, `import { Option as Option_2 }`, `class Cache_2` + `export { Cache_2 as Cache }`. Three goldens therefore show REMOVED lines, which is what the narrowing detector reports and it is right to.
+  Everything that acquires now lives inside the `try`, so a throw from anywhere records `failed` with its reason and releases both timers. The watchdog promise additionally carries a discarded rejection handler, which makes the CONSEQUENCE of a future leak impossible rather than only this one: `race` still sees the rejection, and node can never see it as unhandled.
+- **@voltro/runtime, @voltro/cli** — A `defineStream`'s declared `guards:` are enforced — before the executor runs.
 
-  Nothing left the surface. Public names extracted from BOTH the `export const|type|interface X` and the `export { X_2 as X }` forms, on both sides of each golden, are identical sets: 965/965 for `voltro-server`, 293/293 for `voltro-ai`, 26/26 for `voltro-cache`. A consumer importing `Cache`, `Notification` or `Option` from `@voltro/voltro` sees no change; only the report spells them differently.
-- **@voltro/runtime** — The event-bus perf budgets are RATIOS now, not absolute microseconds.
+  Measured against a running api: two `POST /rpc` calls with no Authorization header, milliseconds apart, both descriptors declaring the same scope. The QUERY refused with `ScopeError`; the STREAM answered tokens. It had called a model and paid for it, so the missing check was not only a read permission — an open stream is an open wallet.
 
-  `expect(full).toBeLessThan(60)` read 87.6 µs on a release runner and took the run down. Nothing had regressed: the runner was ~19x slower than the machine the constant was written on, and 60 µs against a 4.6 µs local reading left only 13x of headroom. Two more assertions in the file had the same shape and had simply not fired yet — the publish budget sat at 86% of its constant on that runner.
+  Two defects, and the second survives fixing the first.
 
-  Each is now a ratio between two measurements taken in the same test on the same machine, so machine speed divides out:
+  **Nothing passed the guards.** `bindStream` has taken a `guards` argument since it was written, implements the subscribe-time gate and the per-element re-check, and documents both — and neither boot path passed it. Declared, documented, implemented, wired at zero call sites. The call's input goes with it, because a resource-scoped guard (`{ scope: 'x:read', from: 'id' }`) reads which resource was asked for out of it and otherwise fails closed.
 
-  - `full < raw * 12` — the assertion the test is NAMED for ("the wrapper is not where the cost is") and never made. Both numbers were already measured three lines apart, and the file even printed `full - raw` before discarding it. - `warm < cold * 5` — the resume test claimed "attaching after 5k publishes must cost about what attaching after 5 does" and then measured only the 5k end. It measures both now, which is the first time it tests its own stated property. - `micros < machineMicros() * 150` — the one claim with no same-code comparand, denominated in a keyed-Map/string reference in a publish's own cost class.
+  **The gate ran after `buildStream`.** That is where the user's executor runs, so an unauthorized caller had already been served by the expensive half by the time authorization was decided. Passing the guards alone would have stopped the tokens reaching the client while still paying for them, and from the client side those two are identical. The doc comment said "before anything is registered"; the code registered first. It is first now.
 
-  The ratio form is also STRICTER than what it replaces: these fire at ~3-6x regressions where the constants needed 13-331x. Each was falsified by tightening its bound and watching it go red — a budget that can no longer fail is the failure mode this file exists to avoid.
+  This is the SECOND time this exact defect shipped: `defineEvent` accepted `guards:`, documented them, and nothing checked. That was fixed for events and `defineStream` kept the identical hole. So the test asserts the property over the SET — all five primitives that accept `guards:`, each at its named enforcement point — rather than over the one that was reported. Query, mutation, action and event were all already enforced; the stream was the only gap.