@voltro/plugin-audit 0.27.0 → 0.29.0

package/CHANGELOG.md

@@ -39,6 +39,519 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [0.29.0] — 2026-08-07
+
+### ⚠ BREAKING
+
+- **@voltro/web** — **`useLoaderData()` throws where no `loader` is declared, and `useOptionalLoaderData()` is the way to read where one may be absent.**
+
+  `useLoaderData()` was `useContext(LoaderDataContext) as LoaderData<T>` — a cast over a context whose default was `undefined`. At a level with no `loader`, `const { project } = useLoaderData<Data>()` died at `Cannot destructure property 'project' of undefined`: a message naming the property rather than the mistake, and under `renderMode: 'ssr'` a throw that fails the entire server render instead of degrading. Reported by a consumer who spent a cycle on it.
+
+  **What this is NOT: a `| undefined` return type.** That was the obvious fix and it is wrong. The router never renders a page that declares a `loader` without its data — a settled loader commits its data and the displayed route together, a pending one renders the `Pending` skeleton (or keeps the previous page), and one that threw renders the error subtree; three separate branches. Widening the type would have taxed every correct call site to model a state the router already prevents.
+
+  So the return type is unchanged and the absence becomes loud instead:
+
+  - a level with **no `loader`** throws, naming the cause and pointing at `useOptionalLoaderData()`; - **`useOptionalLoaderData()`** returns `undefined` there — for the one legitimate case, a component genuinely mounted both under routes that declare a loader and routes that do not; - a loader that legitimately resolves to `undefined` does **not** throw. Declaring a loader and returning nothing is a choice; having no loader is not.
+
+  **An empty RESULT is not an absence.** A loader returning `{ items: [] }` returns exactly that through both hooks. `undefined` never means "the query found nothing" — only "there is no loader at this level". The wire already made this distinction (`pageLoaderRan`, documented as "not derivable from loaderData"); the hooks now honour it too.
+
+  Internally the provider carries a `NO_LOADER_DATA` marker instead of `undefined`. It is still a provider, deliberately: dropping it for loader-less levels would let a page fall through to its layout's data and silently render a neighbour's value — worse than the crash it replaces, because nothing would report it. Server and client set the marker from the same fact (`descriptor.loader` / `segment.loader`), so a component cannot render on one side and throw on the other.
+
+  Covered by `loaderDataAbsence.test.tsx` (both render paths, the shield, the empty-result and legitimately-undefined cases), red-verified by removing the marker.
+
+  **`voltro update` carries you across this** — codemod `0.29.0/01_loader-data-absence`.
+
+### Added
+
+- **@voltro/runtime, @voltro/cli** — aggregate-derivation (sharpened): the mutation/action interceptor `meta` now carries the descriptor's DECLARED write-target table names (`meta.target`) for an audit/derivation consumer — purely additive, omitted when no target is declared. And `voltro doctor` gains a junction-FK finding: it flags a link/junction table whose FK wiring is suspect (composite-PK member unwired, an unwired id beside a real `reference()` sibling, pure link-only table), reading real declared column types (not regex) with a tight non-FK-id exclusion so a lone foreign id on a normal entity stays silent. The FK-walk DSL + `voltro audit map` are deferred (single-consumer). apiSurface compatible — additive exports + type-alias renumbering only. codemod: none.
+- **@voltro/plugin-billing** — Stripe Checkout now collects a customer's VAT / tax ID (`tax_id_collection`), and reuses an existing customer's captured name + address so the tax ID attaches correctly. Additive; `automatic_tax` was already on.
+- **@voltro/database, @voltro/protocol, @voltro/runtime** — New `rule()` primitive: `table(...).rule(name, predicate, { severity? })` declares a cross-table transactional invariant evaluated INSIDE the mutation transaction (predicate reads share the write's MVCC snapshot via the dialect-neutral query layer — correct on all four dialects, no per-dialect code). A violation rolls the transaction back and fails with the typed, wire-preserved `BusinessRuleViolation` (auto-merged into every mutation's error union at `mutationToRpc`, like `ScopeError`); `severity: 'warning'` logs + commits instead. codemod: none.
+- **@voltro/cli** — Three CLI commands: `voltro typecheck` (runs `tsc --noEmit` using the APP's own TypeScript, resolved from the app's node_modules), `voltro info` (CLI/node/pm/dialect + every installed `@voltro/*` version, flags lockstep skew with a non-zero exit), and `voltro new <query|mutation|action|workflow|page> <name>` (scaffolds the correct file convention incl. the descriptor/executor split; refuses overwrite without `--force`). codemod: none.
+- **@voltro/cli** — DNS-rebinding Host guard on the `voltro dev` inspect surface (the API dev server binds 0.0.0.0 and had no Host validation, unlike the web dev server's vite `allowedHosts`). Allows loopback names + any IP literal (an IP can't be DNS-rebound, so phone-on-LAN testing keeps working) + an operator `VOLTRO_INSPECT_ALLOWED_HOSTS` allowlist; any other Host domain → 403. Dev-only by design (prod is token-gated + served on a public hostname). codemod: none.
+- **@voltro/datetime** — New `@voltro/datetime` package (Phase 1): UTC-storage + timezone-aware helpers on the TC39 Temporal standard, plus a request-scoped timezone-context seam (`@voltro/datetime/context`). The `.` entry is browser-safe (no `effect`, no `node:*`); `effect` is an optional peer for the context seam. `interval()`/`rrule()`/schema DSL types are deferred to later phases.
+- **@voltro/runtime** — `defineExpectation()` — reactive data-quality contracts as standing reactions. An expectation over a table (`freshness`/`nullRate`/`rowCount`/`valueBounds`) is maintained incrementally from `store.onChange` CDC deltas by the same IVM engine that backs `defineAggregate({ incremental })` (O(1) per write, no re-query); it tips `holding`↔`violated` with the provenance (traceId/subject/procedure) of the write that caused it, observable via `ExpectationRegistry`. `freshness` also re-compares its IVM-maintained max against the moving clock (so "writes stopped" is detectable — a metric re-comparison, not a data poller). `*.expectation.ts` file discovery wires in the CLI. codemod: none.
+
+  (apiSurface: compatible — the runtime golden churn this session is additions plus api-extractor renumbering its internal `Row_N` dedup alias; no public symbol was removed or resignatured, so no consumer breaks.)
+- **@voltro/runtime** — `defineExperiment()` — online A/B / holdout experiments as live IVM aggregates. Per-variant metrics (count/sum/avg/conversionRate) are maintained incrementally from a table's CDC by grouping rows onto a synthetic variant column through one `AggregateMaintainer` (real-time lift/diff vs a baseline, no batch pipeline); assignment is a salted FNV-1a hash → `[0,1)` (client-reproducible, no `node:crypto`), holdout carved off the top so treatments don't perturb it. Observable via `ExperimentRegistry`/`useExperiment`. Correctness pinned by a brute-force oracle (incremental == full recompute) over insert/update/delete for all four metrics. `*.experiment.ts` file discovery wires in the CLI. codemod: none.
+- **@voltro/cli** — `voltro doctor` gains two findings over declared events. **Delivery-semantics visibility** (informational): it now NAMES each declared event's delivery mode (`each` vs `latest`) — the mode decides what a MISSING message means (`each` counts a drop as a loss and tells the subscriber; `latest` supersedes and says nothing), and it was invisible after the fact everywhere except the devtools panel. **A scale WARN** for two declared-but-won't-scale shapes: a routing key with 3+ fields (every field fragments the subscriber set — distinct routes are the product of the fields' value spaces, so a payload discriminator smuggled into the key multiplies routes for nothing), and a `webhook:` block on a per-frame-looking event (`player.moved`, `cursor.moved`, `*.frameRendered` — every publish becomes N HTTP deliveries per second per target, and the plugin DEFERS the excess as pending rows rather than failing, so the symptom is a growing table). Both read the REAL declared descriptors — the routing-key field count comes from the same top-level schema-property reader the runtime validation uses, so it cannot disagree with the key the event routes on. Advisory, never blocking (same ladder as the orphan audit); surfaced in `--json` as `eventDelivery`. codemod: none.
+- **@voltro/runtime, @voltro/cli** — Reactive-finops now EMITS cost events on real reactive work — the deferred second half of `attachFinops`. The Dispatcher gained a `recordCost?: (e: CostEvent) => void` sink (sibling to `recordDelivery`); each time a change re-runs an affected subscription and pushes it a delta, it records one `{ unit: 'recompute', amount: 1 }` event attributed to the subscription's tenant + traceId (both the row-set and computed-query delivery paths). Both boot paths (`voltro dev`, `voltro serve`) thread the finops runner's `record` into the dispatcher as `recordCost` — ONLY when `*.budget.ts` cost budgets were discovered, so an app with none allocates no `CostEvent` on the reactive hot path. Live attribution is observable via `CostRegistry`. codemod: none.
+
+  (apiSurface: compatible — one additive optional field on `DispatcherDependencies`; no public symbol removed or resignatured.)
+- **@voltro/database, @voltro/runtime, @voltro/local-first** — local-first (deepened toward a working vertical): `crdtText()` is now a real database column type (`@voltro/database`). It stores an encoded CRDT state as `bytes` + a pure `crdtManaged` marker, so the declarative differ treats it as an ordinary nullable `bytes` column — no special DDL, and it round-trips through a plan on every dialect with zero churn (`crdtColumn.test.ts`). The authoritative server-side merge is wired into the runtime write path: the MutationStore folds an incoming encoded update into the stored state with `mergeCrdtStates` (`@voltro/local-first`) before writing, so two concurrent clients converge, and the reactive engine broadcasts the merged result (`crdtMerge.test.ts`, in-memory store, order-independent convergence). `@voltro/local-first` also gains a client persistence CONTRACT — `PersistenceAdapter` + `createInMemoryPersistence()` — and `loadPersistedSyncQueue`, which drains the offline sync queue into it so writes survive a reload. The browser-safe merge primitives stay separate from any `database` handle (the column type is server-side in `@voltro/database`; the merge core is the pure `@voltro/local-first` `.` entry).
+
+  Still seamed (documented, not built): the durable persistence backing (WASM-SQLite / Turso), the bi-directional sync WIRE transport, the presence channel (Redis/NATS), and the higher-level `localFirst` table mixin + client codegen discovery. codemod: none (purely additive — no user-authored code is affected; a `crdtText()` column is opt-in).
+- **@voltro/local-first** — New opt-in `@voltro/local-first` package (Phase 4, first slice): CRDT + local-first primitives. `crdtText()` is a Yjs-backed CRDT text field behind our own `CrdtBackend` abstraction (the swap point for Loro later — nothing above the backend file imports `yjs`), with the deterministic merge primitive `mergeCrdtStates(a, b)` at its core (concurrent inserts converge order-independently, idempotent re-merge, empty-state identity). Ships the offline sync-queue as a pure reducer (`syncQueueReducer` — enqueue offline, FIFO drain on reconnect, requeue-on-fail with attempt counts), the connection-lifecycle state machine (`connectionReducer` + `deriveSyncStatus`), and `conflictPolicy()` / `lastWriteWins` for non-CRDT fields (deterministic, convergent tiebreak). React wrappers `useSyncQueue()` / `useConnectionStatus()` live under the `./react` subpath (`react` is an optional peer, kept off the pure `.` path). The `.` entry is browser-safe (no `node:*`, no `effect`). Client SQLite persistence (Turso/WASM), the bi-directional sync wire, the presence channel, and the `crdtText()` schema-DSL / `localFirst` mixin codegen wiring are declared as type-level seams (`./seams`) — deferred, not faked.
+- **@voltro/local-first, @voltro/database, @voltro/runtime** — local-first (the vertical, integrated with existing framework infra): three of the four seams from the first slice are now BUILT against real, tested wiring, and the `localFirst` table mixin ships.
+
+  **Bi-directional sync wire (`@voltro/local-first`).** `createSyncClient({ transport })` maps the pure sync-queue reducer onto a `SyncTransport` (two functions an app binds to its EXISTING primitives — `push` to the client's mutation caller writing the `crdtText()` column, `onRemoteState` to the reactive subscription streaming the row). A local edit merges optimistically + queues; reconnect drains to `push` with retry/attempt-bump; incoming merged state folds back via the CRDT. Tested against an in-memory dispatcher that mirrors the runtime's authoritative merge — offline edit drains on reconnect, a remote edit arrives and merges, two concurrent offline edits converge (`syncClient.test.ts`).
+
+  **Presence / awareness (`@voltro/local-first` + `./react`).** `usePresence(roomId, { cursor, name }, { channel })` returns `{ presence, others, setPresence }` over a `PresenceChannel` — the SAME dumb string-payload pub/sub shape as the framework's `BroadcastProvider`, so a runtime binding forwards straight onto the app's broker (in-memory locally; Redis/NATS at scale, already shipped). Join/leave, announce-back discovery, cursor propagation, and TTL expiry live in the pure `createPresenceRoom`; `createInMemoryPresenceChannel` is the test/local transport. Tested pure (`room.test.ts`) and in a real DOM (`usePresence.test.tsx`): two peers see each other, updates propagate, a leaver drops, a silent peer expires.
+
+  **Durable persistence (`@voltro/local-first`).** `createIndexedDbPersistence()` is a durable `PersistenceAdapter` over IndexedDB — no WASM, no added dependency. The IDB implementation is injected, so it is tested against a fake backend that survives a reopen — the durability the in-memory adapter lacks (`indexedDb.test.ts`).
+
+  **`localFirst()` table mixin (`@voltro/database` + `@voltro/runtime`).** A marker mixin (adds no column) that opts a table into local-first sync + persistence; `isLocalFirst()` / `localFirstTables()` are pure discovery helpers, and the runtime SchemaRegistry reflects it as `hasLocalFirst(table)` (beside the existing `crdtColumns(table)`) — the discovery surface, with NO codegen change (a marker mixin rides `.with()` like any column type). The registry id is re-declared and pinned to the mixin by `localFirstMixinId.test.ts`, exactly like tenant/expires.
+
+  Browser/server boundary preserved: the sync client, presence, and persistence are browser-safe (no `node:*`, no `@voltro/database`, no runtime); the authoritative CRDT merge stays server-side in `@voltro/runtime`. codemod: none — purely additive, all opt-in.
+
+  What GENUINELY remains a runtime seam (infra + a thin app binding, not un-built framework code): a `SyncTransport` bound to a specific running app's mutation/subscription, a `PresenceChannel` bound to a provisioned Redis/NATS broker at scale, and (optional) a wa-sqlite/Turso durable adapter for cross-tab SQL. All three sit behind interfaces the tested code already speaks.
+- **@voltro/cli** — Native mobile SDK generators: `voltro build api --target swift` emits a Swift Package and `voltro build api --target kotlin` a Kotlin Multiplatform module, generated FROM the app's capability manifest (the same procedure descriptors + JSON Schemas the TypeScript client codegen reads — no source is re-parsed). Each package ships type-safe models (Codable structs / `@Serializable` data classes + enums), a one-shot HTTP client (query/mutation/action), a WebSocket subscription client (streams), an auth/tenant-context helper, and a push-registration stub. Faithful type mapping (string/number/boolean/array/nested-object/enum, optional → Swift `Optional` / Kotlin nullable). Flags: `--target`, `--out`, `--name`, `--kotlin-package`; default output `<appDir>/sdk/<target>`. The generated SOURCE is golden-string tested; cross-language COMPILE (swiftc / Gradle) and the native runtime (native modules, the APNs/FCM push sender, OTA build pipeline) are out of scope. codemod: none.
+- **@voltro/cli, @voltro/web** — Page `export const preload` convention: a page declares `ReadonlyArray<string | { tag; input?(params) }>` and the SSR render (dev + start; inert for SSG) runs each subscription server-side and seeds it, so a `usePreloadedSubscription` on that page renders with data on first paint instead of re-fetching on mount. Read directly from the page module in the render loops (a purely server-side directive; the client never needs it). codemod: none.
+- **@voltro/client, @voltro/web** — SSR-preloaded subscriptions: `usePreloadedSubscription(api, tag, input)` (`@voltro/client`) — `useSubscription` that reads its FIRST value from the SSR hydration payload instead of flashing an empty state and re-fetching on mount, then upgrades to the live WebSocket stream. The value is seeded server-side during a render (a loader, a layout loader) with `seedPreloadedSubscription(api, tag, input, value)`, keyed by the SAME `stableKey([tag, input])` the SubscriptionCache uses, and carried into the hydration payload alongside the store seeds (mirroring their request-scoped-bag + resolver inversion; the `node:async_hooks` scoping stays in `@voltro/web/ssr`). Because the value flows through `useSubscription`'s `initialSnapshot` render branch — read identically on the server and the client hydration render — there is no hydration mismatch. When no seed exists for the key (a client-side SPA navigation the server never rendered), it behaves exactly like `useSubscription`. codemod: none.
+- **@voltro/react-native** — **New package `@voltro/react-native` — the credential-free mobile primitives.** The React client already runs in React Native (the runtime has no DOM dependency); this adds the mobile plumbing on top of it that needs no per-tenant Apple/Firebase credentials and no native runtime.
+
+  - **Device registration** — a `_voltro_devices` table (`@voltro/react-native/schema`: tenant + user scope, platform/token/locale/timezone, `(platform, token)` unique upsert target, per-user fan-out index) plus a `registerDevice(upsert, input)` client function. `resolveDeviceRegistration` normalises locale/timezone (input → env → ambient → `en`/`UTC` floor) into the row; `userId`/`tenantId` are the server's to stamp, never trusted from the client. - **`useBackgroundSync()`** — the interval / foreground-trigger state machine. The OS background-fetch registration stays the app's; the hook is a thin wrapper over a pure reducer (`backgroundSyncReducer` + `shouldSync`: single-flight, foreground-gated, interval-gated, forced triggers bypass only the interval). - **Offline-first defaults** (`offlineFirstDefaults`: local-first opt-out on mobile, sync on foreground + interval, status surfaced) and a standalone `useMobileConnectionStatus` (`connected | degraded | offline`) — deliberately not coupled to a transport or the in-flight local-first package. - **`defineDeepLink({ pattern, handler })`** descriptor + a pure matcher (`matchDeepLink('/orders/:id', '/orders/42')` → `{ id: '42' }`; segment-exact, scheme/host/query/trailing-slash normalised; params typed from the pattern literal).
+
+  The root export is RN-safe (no `node:*`, no `@voltro/database`; React is an optional peer reached only through the hooks). The `_voltro_devices` declaration is the server-side `@voltro/react-native/schema` subpath.
+
+  **Deferred as documented seams** (flagged in the package, not built): APNs/FCM **sender** adapters (need per-tenant Apple Developer / Firebase credentials); native module bindings (camera, biometrics, secure storage — need a native runtime); Swift/Kotlin SDK generators (open product decision); universal-links / App-Links file automation; and the `*.deepLink.ts` codegen discovery wiring (one additive file, landed after the current release — the descriptor shape is final, so until then links register via `matchFirstDeepLink`).
+- **@voltro/runtime** — `defineCostBudget()` + `attachFinops()` — reactive FinOps: per-tenant / per-subscription compute-cost attribution + budgets. A `CostAccountant` folds each `CostEvent` (`{ tenantId, subscriptionId?, unit, amount, … }`) in O(1) into a standing per-tenant attribution accumulator (`total` + `byUnit` + `bySubscription` — the chargeback/showback answer) and every budget that watches its unit. A budget is a POLICY holding EVERY tenant to the same ceiling independently (mirroring `requireAiBudget`); its per-`(budget,tenant)` windowed counter crosses `ok`→`warn`→`exceeded` with the provenance of the causing event, recovers on a tumbling-window rollover (event- AND clock-driven) or an explicit `reset(tenantId)`, and is observable via `CostRegistry` (same shape as `ExpectationRegistry`: snapshot / get / breaches / subscribe). The engine is store-free + unit-testable; the descriptor + registry Tag are browser-safe. `*.budget.ts` file discovery, the `attachFinops` call in both boot paths, and the dispatcher/query cost-event taps are the forthcoming CLI wiring. codemod: none.
+- **@voltro/cache, @voltro/ai** — Reactive semantic cache: `SemanticCache` (`@voltro/cache/semantic`) — an embedding-keyed LLM cache with a cosine-similarity vector index over the existing `CacheStore`, dependency-set capture as tags (`rowDep`/`tableDep`), and eviction by source change (`onSourceChange`/`onTableChange`, insert evicts table-coarse only). `@voltro/ai/semanticCache` wraps it: `semanticGenerateText`/`semanticGenerateObject` embed→lookup→hit-returns-cached (zero tokens) / miss-generates-and-stores under the captured deps, best-effort (a cache outage degrades to always-generate). Firing eviction on live writes is a one-line CLI-facade sink (documented; no runtime change). codemod: none.
+- **@voltro/database, @voltro/runtime, @voltro/cli** — Field-level read permissions: a new `.readableBy(...scopes)` column modifier (Part B of the column-wire-visibility seam). A column marked `.readableBy('billing:read')` is stripped from query + subscription wire OUTPUT for any subject that holds NONE of the listed scopes, and present for one holding ANY of them — checked against the subject's EFFECTIVE scope set (raw subject scopes ∪ rbac role-derived scopes), with the `admin:full` bypass seeing every such column. It is the graded middle of the wire-exposure axis between a plain column (visible to everyone) and `.serverOnly()` (hidden from every client); the two compose (`.serverOnly()` still wins — hidden from everyone including admins). Enforced at the SAME Dispatcher read chokepoint as `.serverOnly()` (initial snapshot + every reactive delta) and at the `publicApi` one-shot REST GET in both boot paths (`voltro dev`, `voltro serve`). Subject-independent — and therefore memo-sharing — for any table that declares no `.readableBy(...)` column. Server-internal reads (`ctx.store.query`) still see the value; the strip is a wire concern only. Declaration rejects `.readableBy()` with no scope (that is `.serverOnly()`) and a blank scope string. codemod: none.
+
+  apiSurface note: the one changed golden line is `OneShotQueryRunnerDeps.queryRows`, which gained a second `context: ServeRequestContext` parameter so the one-shot runner can apply the subject-aware strip. It is a callback the CONSUMER supplies, so an existing `(descriptor) => …` still satisfies the wider `(descriptor, context) => …` type — the change cannot turn compiling code into non-compiling code. Everything else is a pure addition (`readableBy`, `readableByColumns`, `ReadableByColumn`, `forbiddenColumnsForSubject`, `stripForbiddenForWire`).
+- **@voltro/cli** — `voltro evolve` — schema-evolution copilot for changing EXISTING schema safely. Given a change (`rename-column`/`retype-column`/`split-column`/`drop-column`/`rename-table`) it reads the OBSERVED graph (`app.graph.observed.generated.json`) + the app manifest to enumerate the real blast radius (handlers that actually touch the table; declared-but-unexercised ones flagged UNKNOWN, never assumed safe), then proposes a reviewable plan: a codemod (rename-column gets a real transform that renames the `*.entity.ts` field AND chains `.renamedFrom('old')` so the differ plans a catalog RENAME not a lossy drop+create, and annotates the handler sites the blast radius found; reshaping kinds get a `manual` codemod with generated steps) + a branch-verified backfill plan (per-kind SQL tied to `planBranchProvision`, snapshotting the exact tables the affected handlers touch) + a `voltro check` verify step. Dry-run by default; `--write` applies via the existing `runCodemods` toolkit; `--json` for CI. codemod: none.
+- **@voltro/env** — Live secret rotation: `refreshEnvValue(key, value, { previous, graceMs })` installs a re-resolved env value a running process serves immediately while holding the OLD value for a grace window (lazy prune-on-read, no timer); `rotateSecretLive(key, { graceMs })` (`@voltro/env/server`) re-resolves through the backend + does the cutover, and `getSecretWithOverlap(key)` returns `{ current, previous }` — the current/previous verifier pattern for app env. Bounds (documented): this updates what code reading a secret PER USE sees (outbound keys, webhook-signing, field-encryption); it does not reconnect a live DB pool built with the old credential. codemod: none.
+- **@voltro/cache, @voltro/cli** — The reactive semantic cache (`SemanticCache`) is now wireable as a framework-managed opt-in. Set `cacheSemantic: true` in `app.config.ts` and both boot paths build a `SemanticCache` over the SAME `CacheStore` the query `Cache` uses (`CacheLayer.storeLayer` is now exported so one store instance is shared by both), provide it as a `yield*`-able handler service, AND wire row-granular eviction off the runtime's existing `store.onChange` — a live DB write to a source row drops every semantic entry that depended on it (`onSourceChange`). Gated end-to-end: an app that leaves `cacheSemantic` off builds no vector index, no service, and no eviction sink. codemod: none.
+
+  (apiSurface: compatible — `CacheLayer.storeLayer` is a new export; nothing removed or resignatured.)
+- **@voltro/web, @voltro/cli, @voltro/ui** — Framework SEO + a11y primitives: `seoAlternates()` (reciprocal absolute canonical + hreflang alternates + x-default, browser-safe), `PageMeta.noIndex` (emits robots noindex on every render path + excludes the route from the sitemap), build-time `dist/sitemap.xml` + `dist/robots.txt` generation (per-locale alternates, `WebAppConfig.seo.siteUrl`, `VOLTRO_SEO_NOINDEX` staging override, never overwrites a user `public/` copy), a dev-server disallow-all robots. Accessible `<Field>` defaults filled: Schema-`description` hints wired via `aria-describedby`, the RadioWidget error now associated, required marker `aria-hidden` + `aria-required`.
+- **@voltro/cli** — File-convention discovery + boot attach for the standing primitives: `*.expectation.ts` (defineExpectation), `*.budget.ts` (defineCostBudget), `*.experiment.ts` (defineExperiment) are now discovered like `*.aggregate.ts` and attached in BOTH `voltro dev` and `voltro serve` (parity), each providing its registry (ExpectationRegistry/CostRegistry/ExperimentRegistry) as a handler Layer + a `GET /_voltro/inspect/{expectations,budgets,experiments}` snapshot. This is what makes the three primitives user-reachable via file convention. (Cost-EVENT emission — the dispatcher recordCost tap — remains the deferred secondary half, so budgets are declarable+observable but attribution stays 0 until it lands.) codemod: none.
+- **@voltro/ai, @voltro/cli** — `voltro eval` — replay real recorded agent/AI runs and gate the deploy on the result. `defineEval({ name, cases, assert?, judge? })` (`@voltro/ai`) declares golden cases from recorded runs; `voltro eval` discovers `*.eval.ts`, replays each case against the CURRENT model, judges with HARD assertions (`contains`/`matches`/`equals`/`nonEmpty`/`maxLatencyMs`) plus an optional LLM judge (`generateObject`-backed, schema-constrained verdict), and exits 1 on any regression — a deploy-gate signal, `--json` feedable into CI. Reuses run-recording (`runAndPersist`/`threads`), the data-branch identity machinery (`branchNamespaceName`, `--branch`), and mirrors `voltro check`'s gate shape. The runner (`runEval`/`scoreCase`/`evaluateAssertions`) is pure over an injected replay + judge, so it is fully unit-testable without a provider. `*.eval.ts` is read only by `voltro eval` — it is deliberately not a boot/browser file convention. codemod: none.
+- **@voltro/workflow, @voltro/cli** — Workflow **resume-from-step** — rewind a terminally-`failed` run to an operator-chosen step and re-execute from there, past the point it actually died. The generalisation of `redrive` (which only re-runs the failed step): resume resets the target step **and every step after it** (succeeded ones included), so a step that completed cleanly but on stale/wrong external state re-runs too, while the steps *before* the target replay from the durable journal. For the dead-letter case where the failure point is not the right recovery point.
+
+  - Engine adapter `resumeRunFromStep` on `@voltro/workflow/cluster` (sibling to `redriveFailedRun`, sharing the one `@effect/cluster`-coupling core — a live-cluster contract test asserts the step before the target REPLAYS while the target + downstream RE-RUN). - `voltro workflows resume-from-step <runId> <stepName>` + the inspect action `POST /_voltro/inspect/workflows/runs/:id/resume-from-step` `{ step }`, wired into **both** `voltro dev` and `voltro serve`. Refuses a non-`failed`/discarded run and an unknown step; declines cleanly (no journal / still running / already succeeded).
+
+  codemod: none
+
+### Fixed
+
+- **@voltro/client** — **`useAction(...).run` forked against the boot-window stub instead of waiting for the api.**
+
+  `useSubscription` survives that window by design — it reads through the loading cache, reports no data, and delivers when the real client arrives. `run` had no such backstop: called from a mount effect it threw *"rpc / cache calls are not invokable on a not-yet-resolved api"*.
+
+  A component that fetches once on mount therefore had a race it could not see. It usually lost on a cold load and won on an HMR reload, so the page "worked when you looked at it".
+
+  **And the message REPLACED the real one**, which is the expensive half: one app reported api resolution while its upstream was answering `403`, and the `403` was invisible because the call never left the browser. SSR sharpened it — seeding a subscription via `initialSnapshot` makes `isAuthenticated` true on the very first render, so guards that gated mount effects behind "we have a user" stopped gating anything.
+
+  `run` now waits for the api, which is what a caller expects and what the sibling primitive already does. The wait is **bounded** (15s) and the timeout says what happened: an api that never resolves is a real condition — a name matching no configured api, a supervisor that gave up — and hanging forever would trade a confusing error for no error at all.
+
+  The callback also stays stable across the window now: it reads the handle through a ref at call time rather than being recreated the moment the api resolves.
+
+  `isUnresolvedApi(useFrameworkApi(name))` still composes for a caller who wants the readiness bit itself.
+
+  **Measured in a real browser against a real api process**, not only unit-covered — `node scripts/browser-action-boot-window.mjs` (chromium, `e2e-fixtures/web-action-boot` → `memory-api`), with the pre-fix shape restored as a negative control:
+
+  | | on a natural cold load | with a 3s `authHeaders` resolver | |---|---|---| | before | `ERR: rpc / cache calls are not invokable on a not-yet-resolved api` after **17 ms** | same error after **3 ms** | | after | `OK: {"ok":true}` after **34 ms** | `OK: {"ok":true}` after **3039 ms** |
+
+  The window really is only ~15–30 ms wide on a warm machine, so the page takes a negative control in the same instant the call is issued — invoking `handle.client` directly, which still throws. Without it, "run succeeded" would be indistinguishable from "the api had already resolved". The bound is exercised too: a resolver that outlasts the budget settles at 15006 ms with the timeout message, rather than never.
+
+  One thing this does NOT claim, because an earlier draft did and was wrong: `run` waits for the api to RESOLVE, not to be REACHABLE. With the api process killed the supervisor still hands over a client in ~20 ms (an rpc client is built from a layer; nothing there needs a live socket), so the call goes out and fails with a genuine `Error in socket` — which is the point of the fix, a real transport error instead of a stub message that displaced it.
+- **@voltro/cli** — **The atlassian credential codemod now tells you to grep for your own key, not just for `credentialsResolver`.**
+
+  A team doing this migration found **four** call sites reading the PAT off the Subject and only one of them was the resolver: a session strategy stamping it into `metadata`, two delegation helpers building synthetic Subjects that carried it, and an avatar fetch. Fixing the resolver alone leaves the credential on the identity and the leak intact — which is the entire point of the change.
+
+  The note said as much in passing and was easy to read past. It now says it first, and names the reason: the resolver is where the credential is READ, not where it got onto the Subject. It also passes on what the reporter did afterwards — an invariant test that fails if anything puts a token-shaped key into a metadata bag again, mutation-tested by restoring the old line.
+- **@voltro/workflow** — First-deploy cluster convergence: N runners started simultaneously against a fresh database (no `@effect/cluster` schema yet) no longer silently fail to converge. Root cause was `@effect/cluster`'s first-boot storage migration racing the pg catalog (its Migrator creates the tracking table without `IF NOT EXISTS`, and its `LOCK TABLE` guard only exists AFTER that table does). A new `clusterMigrationGateLayer` serializes the FIRST migration behind a cross-dialect advisory lock pinned to a single reserved connection (so acquire+release share a backend and auto-release on crash — the pooled `withMigrationLock` leaks here because storage build checks out several connections), building the storages sequentially. Warm boots skip it. New knob `VOLTRO_CLUSTER_MIGRATION_LOCK_TIMEOUT_MS` (default 60s). codemod: none.
+- **@voltro/workflow** — **The cluster first-boot migration gate deadlocked on sqlite — an app on `store: 'sqlite'` with a workflow would never finish booting.**
+
+  The gate serializes `@effect/cluster`'s first schema migration behind an advisory lock pinned to a *reserved* connection, because acquire and release must land on the same backend. On sqlite the lock is a no-op on both sides — single-writer, single-process, no sibling to serialize against — but the reservation around it was not: `sql.reserve` takes the ONE connection an in-process sqlite client has, and the locked work is the library's storage build, which then asks the pool for another and waits on a connection its own caller is holding.
+
+  It presents as a boot that never finishes, not as an error. Nothing logs.
+
+  Sqlite now runs the migration without reserving. Every other dialect is unchanged — the reservation is load-bearing there, and removing it would leak a session lock onto an idle pooled connection that every late runner then blocks on.
+
+  **Never released** (it landed after 0.28.0), but worth reading for how it was found. The webhook delivery suite is the only place we build the cluster engine against `:memory:` sqlite; five of its tests sat at their 30 s timeout while the *same* tests on postgres, mysql, mariadb and mssql passed, because those pools hand out a second connection. So the one configuration with no infrastructure — the likeliest first thing a new user runs — was also the only one nothing else covered.
+
+  `clusterMigrationGate.test.ts` pins the connection count, not the outcome: a test asserting only "the work ran" passes on the broken code as long as its fake pool is willing to hand out a second connection, which is exactly the assumption the real sqlite client does not satisfy.
+- **@voltro/cli** — **The credential-purge query in two 0.28.0 codemods was postgres-only, and its MySQL/MariaDB translation silently under-reported.**
+
+  Codemods `03_atlassian-credentials-context` and `04_audit-redacts-subject-metadata` both told you to check your existing rows with `subject::text ILIKE '%token%'`. `::text` and `ILIKE` do not run on MySQL/MariaDB, so the natural translation is a bare `LIKE` — which is case-**sensitive** against the `utf8mb4_bin` collation our own migrator emits for a `json()` column. `'%token%'` therefore does not match `jiraToken`, and a credential key is almost always camelCase.
+
+  A team ran the translated query against 141 rows, got **0**, and nearly reported themselves clean. 117 of those rows held a working credential; they caught it only because the count looked implausible and they printed a sample row.
+
+  Both notes now use `LOWER(subject) LIKE '%token%'`, which is correct on every dialect we ship.
+
+  **Why this is worse than a syntax error, which is the part worth keeping:** a query that fails to run gets fixed. A query that runs and returns good news when the answer is wrong is read as an all-clear — in the security-relevant half of a security-relevant codemod.
+
+  `codemodSqlPortability.test.ts` now scans every codemod note for postgres-only spellings (`::text`, `ILIKE`, `table_schema = 'public'`). It distinguishes SQL a user would copy from prose ABOUT sql by the backtick, because the first version fired on the very sentence warning against the construct — and it carries a selftest, since a scan that silently stopped matching reads exactly like a clean tree.
+- **@voltro/cli** — **Outgoing webhooks never delivered on the cluster engine — i.e. in every deployment.**
+
+  `voltro.deliverWebhook` was provided per-emit: `execute(input).pipe(Effect.provide(deliverWebhookWorkflow.toLayer(…)))`, built fresh inside the emit callback. The in-memory engine tolerates that, because there the layer IS the registry. The **cluster** engine does not: a workflow must be registered as an entity type while the runtime is constructed, and an emit happens long afterwards. So every delivery died with
+
+  ```
+  Entity type 'Workflow/voltro.deliverWebhook' not registered
+  ```
+
+  **after** the mutation had already returned `200`. Zero deliveries, zero rows in `_voltro_webhook_deliveries`, nothing in the calling service's logs. Reported by a consumer on MariaDB + cluster-sql for whom the feature had never once delivered in any environment.
+
+  The layer is now built at boot and registered in `allWorkflowLayers` alongside the app's own workflows, in both boot paths; the emit closure runs on that runtime. An app with outgoing webhooks and no workflows of its own now builds the workflow runtime too — otherwise the fix becomes a different silent failure.
+
+  **The axis is the part worth keeping.** Both boot paths carried the *identical* construction, so no dev/serve parity check could see it — those compare the two paths to each other, and here they agreed. The difference was IN-MEMORY vs CLUSTER, and it looked like dev-vs-serve only because `voltro dev` defaults to the in-memory engine while a deployment uses the cluster one. **A difference between two configurations of ONE path is invisible to every guard that compares paths.**
+
+  `deliverWebhookRegistration.test.ts` pins the boot registration across both paths (red-verified by removing it from one). It is the source half; the behavioural half needs a real SQL cluster engine and is not something a fake engine could stand in for.
+- **@voltro/cli** — **`voltro serve` warned that framework-provided tables "are not a declared table".**
+
+  The stale-`source` audit is called by both boot paths. `voltro dev` passed `allRegisteredTables()` — the process registry, which includes framework- and plugin-provided tables. `voltro serve` passed `discovered.tables`, which is only what the APP declares. So a query naming `_voltro_agent_messages` (or the audit trail, or the notification inbox) was reported as naming a table that does not exist — about a table that does.
+
+  Same codebase, same version, two boots: dev silent, serve warning. It is the false positive fixed for dev in 0.27.0, still live on the serve path — now only where nobody is watching a terminal.
+
+  **Why no existing guard saw it.** It is not a ctx field and not a missing call, so neither the derived boot-path audit nor its ctx-key axis applies: both paths call the *same* function and hand it *different sets*. That is the same variant as the schedule-subject divergence — each call site internally consistent, the difference visible only by comparing them. Reported by a consumer who noticed the two boots disagreeing on identical source.
+
+  Both paths read the process registry now, pinned by a guard that fails if either reverts to the app-declared set.
+- **@voltro/cli** — `.serverOnly()` columns are now stripped from a `publicApi` query's buffered REST GET response. The runtime dispatcher already strips every WS / `POST /rpc` snapshot (which is what the SSR web-router loaders and `usePreloadedSubscription` seeds fetch through, so the `__voltro_state__` hydration payload was already safe), but a query projected to a public REST endpoint has no subscription to drive it — it read the store directly and shipped the raw row, including any `.serverOnly()` credential column (e.g. `keyHash`), to the caller. Both boot paths (`voltro dev`, `voltro serve`) now route the one-shot public read through the same `stripServerOnlyForWire` choke point. codemod: none.
+- **@voltro/runtime** — `.serverOnly()` columns are now stripped from ALL query + subscription OUTPUT at the Dispatcher's read boundary (initial snapshot + every reactive delta), not just `crud.*` echoes + the boot audit — so a hand-written query/subscription returning a raw row no longer leaks a server-only column to the wire. Server-internal reads (`ctx.store.query`) still see the column; the strip is wire-only and subject-independent, so it shares the read memo. codemod: none.
+- **@voltro/cli, @voltro/i18n** — **`voltro dev` server-renders WITHOUT `<I18nProvider>`, so SSR could not be developed at all for a translated app.**
+
+  There are three server renderers and each arranged the i18n wrapper for itself: `voltro build`'s prerender picked a wrap per locale, `voltro start` called the `i18n.resolve` baked into the generated `ssrEntry.ts`, and `voltro dev` — which loads `@voltro/web/ssr` directly and therefore has no generated entry to call — passed **no `outerWrap` at all**. Any component calling `useT()` / `<T>` rendered fine under `voltro start` and threw on the server under `voltro dev`:
+
+  ```
+  Error: [React Intl] Could not find required `intl` object.
+         <IntlProvider> needs to exist in the component ancestry.
+  ```
+
+  Reported by a consumer whose 51 `renderMode: 'ssr'` pages were every one of them serving a spinner — and two further defects sat behind this one, because nobody could get a page far enough to see them.
+
+  `@voltro/i18n/server` gains **`makeSsrI18nResolver`** (cookie `voltro:lang` > `Accept-Language` > default → the matching wrapper), and both the generated entry and the dev server now call it. The dev copy and the generated copy were going to be two hand-written versions of the same five lines, which is how they diverged in the first place. It stays React-free so the CLI takes no React dependency; dev loads the React half through Vite's SSR loader, as the prerender already did.
+
+  Both dev render branches are covered — the page, and `prepareSpaLayoutShell`, which builds its own `renderInput` and matters because a translated ROOT LAYOUT above a client-only page hits `useT()` on the server exactly as a page does.
+
+  **And the dev SSR failure path no longer hands the raw error to the logger.** A React SSR error carries the element/props graph; formatting it through `util.inspect` can exceed V8's ~512 MB string cap, at which point `RangeError: Invalid string length` from `inspect` *becomes* the reported error and the real message is gone. The consumer had to monkey-patch `console.error` from application code to recover a one-line i18n error. `boundedErrorText` reads `stack`/`message` only, caps the result, names the truncation, and includes `cause` / `AggregateError` children.
+
+  Verified against a real `voltro dev` process rendering a fixture with two locales: the marker appears in the SERVER body, the `voltro:lang` cookie selects the German catalog (so the wrap is per-request, not a fixed default), and both branches were red-verified by removing their spread.
+
+  codemod: none — no user-authored code changes shape; a page that was crashing now renders.
+- **@voltro/cli** — **Every first visit to an SSR page hydration-mismatched, and `<html lang>` was a constant.**
+
+  Two defects on one surface, and the second is why the obvious fix for the first did not work.
+
+  **1. The halves disagreed on the no-cookie case.** The generated client entry resolved the locale from the cookie only — correctly refusing `navigator.languages`, which can diverge from what the server saw. But *dropping* the `Accept-Language` signal is not the same as *agreeing* with the server about it. With no `voltro:lang` cookie yet — every first visit — the server negotiated `Accept-Language` while the client fell through to `defaultLocale`. An English browser on a German-default app hydrated `de` over an `en` tree, so React discarded the whole server render: exactly what SSR was enabled to buy. It stopped the moment anything wrote the cookie, which is why one language switch made it un-reproducible for that developer.
+
+  The client now **adopts what the server resolved**, from `<html lang>`, before falling back to the cookie and the default. `navigator.languages` is still never read.
+
+  **2. `<html lang>` never carried the resolved locale.** `voltro dev` read a `voltro:locale` cookie. Nothing writes that name — `resolveLocale`, the generated entry, `@voltro/ui-shadcn`'s ProfileMenu and the docs all use `voltro:lang` — so the lookup always missed and the attribute was the literal `"en"` on every page of a German-default app. Measured by a consumer with three different `Accept-Language` values against `/login`: `<html lang="en">` all three times.
+
+  That is wrong on its own terms: `<html lang>` is what a screen reader pronounces in, what Chrome offers to translate *from*, and what hyphenation uses. It is now the locale THIS request resolved — the same value the `<I18nProvider>` renders with — falling back to `voltro:lang`, then the app's `defaultLocale`, never a hardcoded `'en'`.
+
+  **It also cost the reporter a wrong fix**, which is the part worth keeping: they shipped "adopt `<html lang>` as the client fallback" with green tests, because the tests asserted their belief about what the attribute contained. A `curl` is what caught it. Both halves are now asserted against a running `voltro dev`, red-verified by restoring the old cookie name.
+
+  The docs said the client "mirrors cookie and default for hydration safety" — a sentence that reads as a guarantee and described the opposite of what happened. Corrected in both languages.
+
+  Still open, narrower: `voltro start`'s `<html lang>` prefers the resolved locale but falls back to `'en'` rather than `defaultLocale` when an app configures a locale whose catalog file is missing.
+- **@voltro/runtime** — **An undeclared throw reached the client as a ~2 KB decode tree instead of its message.**
+
+  An executor threw a plain `TypeError`. The server logged it correctly. What the client got was the entire `ExitEncoded<…>` transformation — every member of the descriptor's `error:` union, the full type, and the actual cause on the *last* line. One consumer's account page rendered that verbatim where a reason belonged, and every app otherwise has to condense it heuristically to avoid putting a schema on screen.
+
+  **The channel is the part worth keeping, and only a deployed process settled it.** The first attempt guarded the DEFECT channel — reasonable, and inert: an executor that throws is settled as a FAILURE by the async wrapper, so the encoded cause reads `_tag: "Fail"` and a defect-channel catch never fires. The existing `isInfraError` guard missed it too, because a plain `TypeError` has no `_tag`.
+
+  So the rule is on the failure channel and is not a heuristic: **every error an app DECLARES carries a `_tag`** — that is the wire contract the client pattern-matches on — so an `Error` without one is exactly the set the descriptor's `error:` union cannot contain. A tagged error passes through untouched.
+
+  An undeclared defect now collapses to the same small tagged `InternalError` the infra path already produced, carrying the message the server just logged. `message` only: no stack, no `cause` chain, no own fields — the same reasoning as `wireErrorFromCause`, where a nested object can hold a DSN or a token. Bounded at 500 chars with the truncation marked.
+
+  **Measured against `voltro serve`**, an action doing `undefined.runWithEager()`, from the published fixture bundle:
+
+  | | response | |---|---| | before | **543 bytes** of `ExitEncoded<…>` decode tree | | after | **185 bytes** — `{"_tag":"InternalError","message":"Cannot read properties of undefined (reading 'runWithEager')","traceId":…}` |
+
+  The server log line and the client message are now identical, which was the ask. The unit test was green through BOTH states, because it exercised the pure function and not the channel it hangs on.
+
+  **The asymmetry with `isInfraError` is deliberate.** A `SqlError` still collapses to the generic `'internal server error'`, because its message names internal `table.column` detail. An arbitrary app defect has no such known shape, and withholding its text too would leave the app exactly where it started — with a reason it cannot show.
+- **@voltro/plugin-webhooks** — **The scope lookups read one page of the target table and answered confidently from it.**
+
+  `scope` is an app-defined JSON blob, so matching it cannot be a SQL predicate — a JSON comparison is dialect-divergent, and on MariaDB a `json()` column carries `utf8mb4_bin`, which has already produced a case-sensitive `LIKE` that reported a clean `0` over 141 dirty rows. Filtering in JS is the right call. Reading only the first 1000 rows to filter was not.
+
+  Past that many target rows, both callers returned a wrong answer rather than an error:
+
+  - **`subscribe` minted a fresh secret for a LIVE endpoint.** Growing an endpoint inherits its secret precisely because the receiver verifies one signature for one URL. Not seeing the endpoint's rows meant inventing a new key, so half its rows then sign with a key the receiver does not hold — and the "these are not one endpoint" refusal never fires, because it only inspects what was fetched. - **`resolveTargets` threw `no target matches scope … the operation would have silently done nothing`** for a scope that does match. That message sits three lines under a comment about exactly this failure shape.
+
+  Both now page until the table is exhausted, ordered by `id` (unique — `OFFSET` over a non-unique order can repeat or skip rows between pages, and mssql refuses `OFFSET` without an `ORDER BY`). Past 100k rows the scan THROWS: a scan that gives up quietly is the thing being fixed.
+
+  `emit`'s fan-out pages too. Its cap was per-event (it has a real `event` predicate) and carried the comment *"sane bound — 1000 targets per event is plenty"* — but a bound whose overflow is a silent non-delivery is not a bound, it is a data-loss ceiling nobody is told about. Paging costs nothing in the normal case: one page, one round trip.
+
+  **Why nothing caught it.** Every test harness in the package returns its whole row array from `query()` and ignores `take`/`skip` — which is precisely what a paging bug looks like from the inside. `targetScan.test.ts` uses a harness that honours them, and that is the only reason its assertions mean anything.
+
+### Internal (no consumer-facing effect)
+
+- **@voltro/plugin-ai-flows** — **`FlowStep` / `RunStep` are declared interfaces, so the api report stops churning.**
+
+  `type FlowStep = typeof FlowStep.Type` is an alias to a mapped type, and TypeScript's declaration emit expands such an alias structurally rather than printing its name. Both types are reached from an exported table (`aiFlows.steps: json<ReadonlyArray<FlowStep>>()`), so a ~60-line expansion sat inline in `etc/plugin-ai-flows.api.md` — and its member order depends on which other packages were built in the same turbo run. Measured: a full-monorepo build and a single-package `--force` build emit `params` and `schema` (structurally identical, both `Schema.optional(Json)`) in different positions, so the pre-push drift gate rejected whichever order was committed. CI does not build the scope a dev machine does.
+
+  An `interface` is a real declaration TypeScript prints by name. Both are pinned to their schemas by an `Equals` check that fails to compile on divergence, so the hand-written shape cannot drift from the runtime one.
+
+  **`apiSurface: compatible`, and the reason matters more than the label:** the 36 removed golden lines are the collapsed expansion, not a removed capability. The type is structurally identical — the `Equals` pin proves exactness in both directions — so no consumer expression changes meaning. What changed is how the report SPELLS the same type.
+
+  Verified byte-identical across exactly the two build scopes that disagreed before.
+- **@voltro/cli** — boot-validate (sharpened): a `pnpm boot-validate:sqlite` lane (driver-gated, degraded-boot: probes the sqlite driver chain, DEGRADED+exit-0 when absent, else a real embedded-sqlite durable-CRUD round-trip incl. reopen) with a `--self-test`; plus completing the internal `ApiAppConfig.store` union with `'sqlite'` (the resolver already supported it). The Tier-B service lanes (mysql/mssql/clickhouse/redis + a boot-validate compose) are the remainder. Ships with a new `api-backend-sqlite` template.
+- **@voltro/plugin-webhooks, @voltro/workflow** — **The delivery workflow is now covered against a REAL SQL cluster engine, not only the in-memory one.**
+
+  `deliverWorkflow.integration.test.ts` runs the delivery workflow against every dialect with the workflow ENGINE in `memory` — a documented, defensible trade (a cluster cold start made it slow and flaky under CI contention). It is also why a cluster-only defect shipped: a suite named "deliverWorkflow end-to-end per dialect" reads like coverage and was structurally blind to entity registration.
+
+  `deliverWorkflowTwoRunners.integration.test.ts` stands up a real SQL-backed cluster engine on MariaDB and asserts the workflow resolves AND its body runs. `purgeClusterState` is exported from `@voltro/workflow/cluster-suite` so a suite outside the dialect packages can use it. It is ONE file on purpose: two suites purging the same `cluster_*` tables wipe each other's runners mid-run, which fails as something that looks nothing like shared state.
+
+  **Two things measured on the way, both worth more than the test itself:**
+
+  - The old per-emit shape is what the shared cluster suite itself uses (`Effect.provide(handler.pipe(Layer.provideMerge(engine)))`) and it works *there* — because there is exactly one runner. In a deployment the boot runner owns the shard, and an ad-hoc participant registering the entity does not change where the message routes. That is the mechanism behind `Entity type 'Workflow/voltro.deliverWebhook' not registered`, and it is why no single-runner test could have caught it. - **A cluster test that hangs is usually not the cluster.** A stub handler returning `void` against a `success` schema of `{ finalStatus, attempts }` cannot be encoded, so the message is redelivered forever and `execute` never resolves — a 120s timeout with the row still in `cluster_messages`. Accumulated cluster state was blamed first, the purge added, and it still hung; counting the rows settled it. Look at the handler's return type before the cluster.
+
+  **And the two-runner case IS covered now** — `deliverWorkflowTwoRunners.integration.test.ts` stands up a boot runner and a dispatcher against one live MariaDB and asserts BOTH directions:
+
+  | boot runner A | dispatch | result | |---|---|---| | built WITHOUT the workflow's layer | B provides it at dispatch (the shipped shape) | **`not registered`**, body never ran | | built WITH it (what both boot paths do now) | same B | run completes, body executed |
+
+  The negative control is the point: a test that can only pass cannot tell a registered entity from an unregistered one, and every single-runner test in this repo passes on the broken code. The defect case costs ~60s — the ENGINE retries an unroutable message before the failure surfaces — against ~3s for the fix. That is the price of having a reproduction at all; do not lower the timeout to tidy it.
+- **@voltro/cli** — dev.ts refactor (dev-ts-decomposition Step 1+3): the SSE subscription-snapshot push now reuses the shared `buildSubscriptionsInspect` builder instead of an inlined byte-identical copy; the `_voltro_workflow_runs` refetch-and-emit shared by redrive + resume-from-step is one helper; and a live-span-leak GATE test asserts the inspect door gate sits above every ungated live-data branch. Pure refactor, zero behaviour change.
+- **@voltro/cli** — **The message-API check called a real chainable member non-existent.**
+
+  `.index()` is a genuine member of the table builder with two overloads. api-extractor prints an overloaded member as a call-signature *object*:
+
+  ```
+      index: {
+          <const F extends readonly [...]>(fields: F, options?: …): Table<…>;
+          <const IxName extends string, …>(name: IxName, …): Table<…>;
+      }
+  ```
+
+  which matches neither of the check's line-shaped rules (`foo(` / `foo: (…) =>`). So a correct comment naming it was reported as naming something that does not exist, and the static check went red on `main`.
+
+  **A false alarm is not the harmless direction here.** This check exists to be believed — its own failure text says "fix the message, or build the thing it promises". One that cries wolf gets its finding argued with instead of read.
+
+  The lookahead is the part worth recording: matching the generic precisely does **not** work, because `<const F extends … Array<…>>` nests `>`, so a `<[^>]*>` character class stops inside it. The first version of the branch therefore matched nothing and looked like a fix. A call signature simply *starts* with `<` or `(` once trimmed; a data member starts with an identifier or `readonly` — which is what keeps `index?: { readonly where: string }` out, and with it the data-property bug the original rules exist to reject.
+
+  Both directions are now selftest cases, since a rule that quietly stops matching prints exactly like a clean tree.
+
+---
+
+## [0.28.0] — 2026-08-06
+
+### ⚠ BREAKING
+
+- **@voltro/plugin-atlassian** — `credentialsResolver` receives `{ subject, store }` instead of a bare `Subject`.
+
+  The Subject was the only input, so an app doing per-user Atlassian auth had nowhere to keep the caller's PAT except `subject.metadata` — from where it travelled with the identity into everything that persists a Subject. That is the other half of the credential leak a reporter found in their audit table, and the half that actually closes it: with a store handle, the credential never has to enter the Subject at all.
+
+  **Worth saying plainly, because it corrects the ask:** the seam for keeping a token out of the Subject already existed. `connectionCredentials({ connectionId, baseUrl })` puts it in the framework's vault, and it is the right answer for most apps. What did not exist was a way for an app with its OWN token table to read it here — the doc comment said such an app "keeps working exactly as before", which was true and meant "keeps the token in the Subject".
+
+  **Migration:** `(subject) => …` becomes `({ subject }) => …`. `store` is optional — absent when the app bound no data store — and the type forces a resolver that needs it to say what happens then. The codemod lists the three options in order of preference rather than rewriting the destructure, because the mechanical fix silently blesses the shape that caused the leak.
+
+  Measured while fixing it, and worth knowing: the leak was ONE surface. Traces carry only `subject.type`, `@voltro/plugin-sentry` sends only `type` and `tenantId`, and the console sink prints `type:id`. Only the durable audit column held the whole Subject.
+- **@voltro/plugin-audit** — `auditPlugin` redacts `subject.metadata` by default (`redactSubject`), and `resolveScope` now receives the call's `input`.
+
+  **A reporter found a working Jira Personal Access Token in plaintext in 12 of 23 rows of their `_voltro_audit_log`.** Neither plugin involved was wrong on its own: `@voltro/plugin-atlassian`'s `credentialsResolver` took a `Subject` and nothing else, so a per-user PAT had nowhere to live but `subject.metadata`; this plugin serialised the Subject verbatim into a json column. Two correct contracts disagreeing about what a Subject IS — an identity, or a credential envelope — with nothing reconciling them.
+
+  The reasoning is `redactInput`'s, word for word, applied to the field it did not cover: `metadata` is not a table column either, so no schema marker protects it, it is app-controlled so its contents cannot be reasoned about here, and the framework's own per-user-credential mechanism puts a credential in it. **No configuration avoided this** — `redactInput` covers the wrong field, `record: 'errors'` reduces the count rather than the leak, and a function `sink` means giving up the table, its retention sweep and its query helpers.
+
+  **Migration:** none required — `type`, `id`, `tenantId` and `scopes` still land in the row. Opt back in with `redactSubject: 'none'` or, better, a function that names the keys you meant. **Rows you already have are not fixed by a safer default: purge and rotate.** The codemod carries the query.
+
+  `resolveScope` also gains `input`, because the subject-only version covered the wrong half: a reporter's users belong to many teams, so their session carries no "current team", while their API-key subjects DO carry a `teamId` — which made subject-only worse than nothing for them, populating for key-authenticated calls and null for every human one, so a filtered view would have looked like it worked. The input is RAW, before `redactInput`; return the dimension, never the payload, because `scope` is not redacted.
+
+  It is also resolved ONCE per event now. The `...(x !== undefined ? { scope: x } : {})` spread evaluated the resolver twice — invisible, because both calls return the same thing, until a resolver reads a store or counts.
+- **@voltro/plugin-notifications** — `resolveSubjectId` may now return `string | undefined` **or a promise of one**, and the exported `makeSubjectId` helper returns `Promise<string>`.
+
+  The seam exists for an app whose addressing unit is its own — an employee, a member, a contact. Every one of those is a ROW, so resolving one is a store read, so it returns a promise. The sync-only signature meant the call written in the option's own docstring (`resolveSubjectId: (ctx) => resolveCallerEmployeeId(ctx)`) did not typecheck for the only apps the option was built for. Reported by a consumer whose resolver reads `employees`.
+
+  **Migration:** plugin configuration needs no change — a resolver returning a plain string still satisfies the widened type. If you call `makeSubjectId` directly, `await` its result. It is deliberately NOT cached: a per-connection cache would let the first call decide the answer for the life of the connection, and only the app knows its own invalidation.
+- **@voltro/cli, @voltro/runtime** — `pluginRef` orphan rules now run under `voltro serve`. They were wired into `voltro dev` and nowhere else.
+
+  The rule shipped inert (the collector read a builder `table()` had already consumed, so it produced zero rules for everyone), was fixed — and was still bound in exactly one of the two boot paths. So the behaviour a consumer would have lived through is: a row pointing at a deleted plugin row is cleaned up while you develop and left behind forever once you deploy. Nothing crashes; the two paths simply do different things.
+
+  The wiring is a shared builder both paths call (`wirePluginRefRules`), not an inline block mirrored by hand, and the guard now asserts a SET of boot paths rather than reading `dev.ts` alone — the previous version passed every one of its assertions while production was unwired, because it never asked whether a second boot path existed.
+
+  **Migration:** `PluginRefChange` is deleted — `isSoftDelete` and `applyPluginRefRules` take the change channel's own `ChangeEvent`. Its `rowId` / `tenantId` fields are gone; the id and the tenant are derived from the row, so put the row in `old`. In tests, reach for `@voltro/testing`'s `changeDelete` / `changeSoftDelete` instead of a literal.
+
+  The copy is what made this feature fail twice. A second, hand-written shape is what let the original `onSoftDelete` tests assert against `{ op: 'delete', softDeleted: true }` — a combination the channel cannot emit — and stay green while the option could never fire.
+- **@voltro/plugin-webhooks, @voltro/cli** — The outgoing fan-out is tenant-scoped, `ctx.webhooks.emit` is post-commit, and a target's routing filter has a real type.
+
+  Four findings from a consumer building a real outgoing-webhook feature — 29 declared events, one URL per endpoint, third-party receivers.
+
+  **Tenant confinement was the app's job and nothing said so.** `_voltro_webhook_targets` carries `.with(tenant())`, but the service is built once at boot with the app-level store and no subject, so the mixin had nothing to scope by: the target lookup was `eq('event', name)` and nothing else. Confinement rested entirely on each target's own `filter`. It looked safe because filters usually predicate on a globally unique app id — a cross-tenant match was impossible *by accident*, and stopped being so the moment they introduced a value deliberately equal across teams. `ctx.webhooks` now binds the acting subject's tenant onto every emit; a system emit (no tenant) stays unscoped, and an explicit `{ tenantId }` at the call site still wins.
+
+  **`emit` dispatched before commit.** A mutation that emitted and then threw rolled its rows back while the POST went out. `ctx.workflows.start` is post-commit safe and documented as such; this was the one place the rule did not apply to itself. Inside a mutation the dispatch rides `afterCommit` now and the result carries `deferred: true` rather than an unmarked empty delivery list — which would read as "no endpoint wanted it".
+
+  **`filter?: Readonly<Record<string, unknown>>` cost them a feature for a year.** They wrote in a comment that the filter was key-path equality and could not express "id is one of these", refused the capability in their own API with a typed error, and shipped that — while `in` had been supported the whole time. `WebhookFilter` now names all six operators. It is the one place where being wrong is silent in both directions: a predicate matching nothing reads as "no endpoint wanted it", one matching everything reads as working.
+
+  **`subscribe({ scope, events })` inherits the endpoint's secret** — the last reason to read a plugin column. It refuses a scope whose rows do not all share one secret: that is not one endpoint, and signing it as one would re-sign half a group with a key the receiver does not hold.
+
+  `codemod: none` — no user-authored code changes shape. The tenant scope and the commit ordering are behaviour, and both make a previously-possible wrong outcome impossible.
+
+### Added
+
+- **@voltro/cli** — `voltro serve` prints the connection-pool arithmetic at boot:
+
+  ```
+  db pool: max=10 per replica (DB_MAX_CONNECTIONS) × 4 replicas = up to 40 connections.
+  ```
+
+  Reported by an operator whose SECOND pod died on `Connection timed out`. The cause is arithmetic, not a bug — the framework opens one pool per process, so a fleet opens `pool × replicas` against a database limit that does not move with `replicaCount` — but nothing in the boot said what the pool size was, so the multiplication was invisible until the moment it failed. It failed on the second pod, which is the worst place to learn it: the first one proved the configuration "works".
+
+  Set `REPLICA_COUNT` (Helm: `{{ .Values.replicaCount }}`) and the line does the multiplication; without it the line still names the formula. When `DB_MAX_CONNECTIONS` is unset it says UNSET rather than guessing a driver default — a wrong number from us is worse than an omission the operator can look up.
+
+  `voltro dev` deliberately does NOT print it: one process, no replicas, no arithmetic. That exception is asserted by a test so a later parity fix has to argue with it rather than silently undo it.
+- **@voltro/cli** — Webhook management and a MASKED data browser answer in production.
+
+  **`webhookActions`** — subscribe / pause / resume / delete / rotateSecret / replay / repin. Without them the Webhooks panel, now visible in production, renders every target and answers 404 to every button: a read-only page over a management surface, which is the shape that makes an operator distrust all of it. Read lazily off the serve handle, because `serveApi` builds the service (it needs the delivery workflow's trigger) after the inspect manifest exists.
+
+  **`inspectTables` / `inspectRows`, masked.** The browser reads arbitrary rows from arbitrary tables; the deciding question was never whether operators should see production data but WHICH. The schema already answers it — `.sensitive()`, `.encrypted()` and `.serverOnly()` are the three exposure axes this repo already maintains — so production shows the shape of every row and the value of everything unmarked. Inventing a fourth "do not browse" axis is precisely what the note governing those three warns against.
+
+  **Masked, not omitted.** A dropped column reads as "this row has no email", which is a different and wrong fact; the cell says which marker hid it. A `null` stays `null`, because an empty optional column is not a secret and masking it would turn a half-filled table into a wall of markers.
+
+  `voltro dev` deliberately does NOT mask: a developer owns their local database and the overlay's editor writes to it, so masking there would hide a secret the developer put in themselves. The asymmetry is asserted with that reason, and both paths go through one builder so the masking cannot exist in one and rot in the other.
+
+  The eight workflow WRITE actions are decided and not yet built — they need the workflow runtime, proxy, run-recorder and definitions exposed on the serve handle, and threading them means either exporting four inferred types or casting at the seam. A context object reaching a boot path through a cast is the defect this repo has three write-ups about, so it gets the plumbing or it waits.
+- **@voltro/testing, @voltro/database** — `makeSubscribeContext` plus `changeInsert` / `changeUpdate` / `changeDelete` / `changeSoftDelete` — test doubles for the OTHER context a user writes handlers against.
+
+  `makeTestContext` covers `AppContext`. A `*.subscribe.ts` handler receives a change EVENT and a `SubscribeContext`, and there was no constructor for either, so every subscriber test hand-built both.
+
+  Suggested by a consumer, after they named the failure class about their own contract test: *ein Harness, der die falsche Annahme des Codes teilt, prüft nichts.* Six instances turned up in one session, four theirs and two ours, and both of ours were in this gap — including `onSoftDelete` tests built on `{ op: 'delete', softDeleted: true }`, a combination the change channel cannot emit. The flag "worked" against a shape that does not exist while the feature could never fire in production.
+
+  `changeSoftDelete` is the whole argument: there is no `op: 'softDelete'` and there never will be — a soft delete is an ordinary update that sets `deletedAt` — so an author who does not know that writes a delete. The knowledge now lives in a function name rather than in each author's head.
+
+  `makeSubscribeContext().store` has no default and **throws naming itself** when touched. A silent empty store would let a subscriber reading the wrong table pass its test, which is the same silent-nothing the constructors remove.
+- **@voltro/cli** — The eight workflow write actions answer in production: start, cancel, suspend, resume, discard, retry, signal, update.
+
+  `inspectRedriveWorkflowRun` was already wired into serve on the reasoning that dead-letter recovery happens where the incident is. The rest of the family was dev-only, which made the redrive an odd exception rather than a policy — an operator could revive a terminally-failed run and could not retry, discard or cancel one.
+
+  **The first attempt at this took the deps as `unknown` and cast at each use.** It compiled. It was also the wrong answer: a context object reaching a boot path through a cast is the defect this repo has three separate write-ups about, and the entire point of extracting these is that the two paths cannot drift — a cast is the hole a drift walks through. It was deleted rather than shipped.
+
+  They are typed structurally now, by what the bodies actually use: a runtime that can run an Effect, a recorder that can record an event, a definition that can be interrupted or resumed. The engine ENVIRONMENT is a type parameter, because `interrupt`/`resume` are `Effect<void, never, WorkflowEngine>` and pinning `R` to `never` would have forced back exactly the cast being removed. The compiler found two real shape differences on the way — the event-type union and that environment — which is the property `unknown` throws away.
+
+  Built inside `serveApi`, where the runtime lives, and delegated from `serveCommand`'s manifest — the same seam as the redrive and the scheduler's `fireNow`. An app with no workflows gets a refusal naming itself rather than a `TypeError` on undefined.
+
+  The parity guard needed a correction of its own: entries that move into a shared spread leave the key scan's view, so a builder is now asserted against the serve PATH (both `serveCommand` and `serveApi`) rather than one file. Asserting `serveCommand` alone failed a correct wiring — the check was measuring the wrong thing, which is what it exists to catch elsewhere.
+
+### Fixed
+
+- **@voltro/cli** — `*.startup.tsx` and `*.email.tsx` run in production. And every dev/serve difference is now derived and enforced rather than remembered.
+
+  **The two gaps.** A startup is documented as a boot hook and ran under `voltro dev` only — so an app that opens a connection there, warms a cache or starts an SSE bridge got none of it where it is deployed, with no error, because nothing was asked to happen. Declared mail templates were registered in dev only, so `ctx.mail.send({ template })` resolved locally and could not resolve in production. Both go through one shared runner now, proven by boot: `startup ran` appears once in each path.
+
+  **The audit is the real change.** Three defects of this class shipped in a single day — `pluginRef` orphan rules, the inspect router, and plugin RPC interceptors (which meant `plugin-audit` recorded nothing in production). Each was found by accident, each after the rule against it had been written down twice, and each while the existing parity guard was green — because that guard compares the things somebody thought to compare.
+
+  `devServeSurfaceAudit.test.ts` asks the general question instead: which boot symbols does `dev.ts` call that the serve path never reaches? Every answer is wired, justified in writing, or counted as backlog, so a new one is a red test rather than a discovery six months later.
+
+  Two refinements it took three wrong answers to find, both making the check WEAKER on purpose — a guard that cries wolf is one the next reader switches off:
+
+  - `dev.ts` EXPORTS the builders serve imports, so anything called inside `buildStore` / `loadDiscovered` / `buildResolveSubject` is reached. Ignoring that reported read replicas, relations registration and auth composition as production gaps. None of them are. - a symbol absent from serve's source may still be reached — through a namespace, or through shared runtime code (write attribution is stamped in `bindMutation`, so both transports have it).
+
+  **Backlog: three entries, counted.** Boot SEEDS still run in dev only. Whether production should auto-seed on every pod start is a real question — a rolling deploy would run it once per replica — so it is recorded with that reasoning rather than decided in a sweep. Plugin services are still provided to workflow STEPS in dev only.
+- **@voltro/cli** — The declared-event consumer scan resolves IMPORTS instead of guessing from the event's name, and stops walking once no further file can change the answer.
+
+  Two defects, one report. A consumer had ten events consumed in one sibling file and got one `no-consumer` warning for a **live** subscription: the scan matched the wire name's last segment as a substring of the file, nine matched by accident because the import identifier happened to contain it, and the tenth did not — `import employeeAttendance from '…/employeeAttendance.event'` carries the FILE name, while the event is `employee.attendanceChanged`. The rule was comparing a name to a name and calling agreement evidence. It now also credits a binding imported from the event's own module and used outside the import, which is additive: it can only turn a "no" into a "yes", never invent an orphan.
+
+  Their workspace also tripped the sibling-file bound (`stopped after 4000`). The scan is a fold now, settling once every event is both published and consumed, so the walk ends at the file that answers the last question — for them, inside the first sibling app. The bound is raised to 20000 for the genuinely-orphaned case that does read the whole tree, and a walk that STOPPED no longer reports truncation: that scan was complete.
+- **@voltro/cli** — The declared-event wiring check knows about the webhook audience.
+
+  A consumer declared 29 events for outbound delivery and got 58 warning lines on every boot — 29 "never published" and 29 "no `useEvent` consumer" — all wrong. They publish through `ctx.webhooks.emit`, which the producer scan did not look for, and their consumers are rows in someone else's deployment, which no `useEvent` scan can ever see.
+
+  An event declaring `webhook:` now counts an `emit(` as publishing, and is not reported as missing a `useEvent` consumer. Both halves are qualified: the emit must appear in a file that reaches the webhooks service (`emit` is far too common a method name to accept bare), and an event WITHOUT a webhook audience is unaffected — which keeps the finding that mattered. The same reporter had seven of eleven advertised events with no emit call site at all; ticking one returned 200, showed the endpoint healthy, and delivered nothing forever. That case is still reported.
+
+  The warning's own reasoning is right and unchanged — a consumer with no producer waits forever and looks exactly like a quiet channel. A check that is wrong 58 times is one nobody reads the 59th.
+- **@voltro/cli** — `plugins`, `env`, `dataCache` and `subscriptions` answer in production. The "unaudited" inspect backlog is audited.
+
+  Each was carried as an entry nobody had looked at, and the audit found the same thing four times: nothing dev-specific, the inputs already present in `serveCommand`, and the entry simply never moved. Which is how a backlog like that forms — an omission is invisible from the manifest, so it survives every reading of the file.
+
+  **`metrics` is the one that did not resolve that way, and it is a bigger finding.** serve builds a metrics collector, hands it to a single consumer, and never wraps its interceptors with it. Production is therefore not COLLECTING the numbers the endpoint would report — wiring the entry alone would have shipped an honest-looking zero, which is worse than the 404 it shows today. It stays listed, with that reason, because fixing it is a behaviour change rather than a manifest line.
+
+  `subscriptions` reads the dispatcher lazily off the serve handle, the same way `events` and `members` already do — serveApi owns it and is built after the manifest object exists.
+
+  Backlog: three entries left (`inspectTables`, `inspectRows`, `cluster`), down from eight, and the count is asserted so it cannot grow quietly.
+- **@voltro/cli** — Schedules and the workflow read endpoints answer in production. They were wired into `voltro dev` and nowhere else.
+
+  **The written reason for the schedules omission was wrong**, and a reader asking the obvious question — why would schedules be missing when they run in the core? — is what exposed it. The comment said dev computes `nextFiringAt` and the EFFECTIVE coordination from values in its own boot closure. Neither holds: `nextFiring` is a pure function exported from `@voltro/runtime`, and serve already computes the coordination itself as `effectiveScheduleCoordination`, with the same cluster→advisoryLock→single degradations, twenty lines above the manifest it never handed it to.
+
+  The incoherence that gives it away is in the same object: serve wires `inspectFireSchedule`, so an operator could **run** a schedule they could not **list** — while `voltro inspect schedules --failing` is documented as a post-deploy gate, against the deployment, which was the one place it did not answer.
+
+  The six workflow READ endpoints are the same shape, next to the same tell: `inspectRedriveWorkflowRun` is wired in serve on purpose ("dead-letter recovery happens where the incident is"), which is an argument for looking at a run before it is an argument for reviving one. All six are plain queries of `_voltro_workflow_*` tables.
+
+  **The guard that was supposed to report this was itself under-reporting.** It brace-counted to find the manifest's keys, a `{` inside a string literal truncated the walk, and it found 8 dev-only entries where there are 34 — while its own non-vacuity check (`> 5`) passed the whole time. A guard that finds a third of the truth reads exactly like one that found all of it. It is indent-anchored now, with a floor near the real number.
+
+  What remains dev-only is the WRITE surface — arbitrary row edits, seeds, a migration rollback, and the eight workflow control actions — each named with its reason, plus eight read endpoints carried as an explicit, counted backlog. The `webhookActions` entry says plainly that it is a decision nobody has taken rather than a surface anyone rejected.
+- **@voltro/cli** — The inspect ROUTER is shared. Every endpoint wired into `voltro serve` this week was answering 404.
+
+  `voltro dev` dispatched through twenty-one handlers before reaching `handleInspectRequest`; serve called only the last one. So schedules, webhooks, the workflow reads and writes, the data browser and cluster all had their manifest entries in production and no URL that reached them. **The data was wired and the door was not.**
+
+  The parity guard was green throughout, and correctly so by its own definition: it compares which keys a manifest CONTAINS, and this is a missing router CALL. Same shape as every guard in this repo that has needed correcting, one layer further out — a source rule is a map, and this was territory. It was found by booting a fixture and curling it, ninety seconds of work that no amount of reading would have replaced.
+
+  The shared branches are one function both paths call, in one order. `voltro dev` keeps its own overlay-only chain (client-log ingest, the trace ring, the timeline, dashboard mounts) — those answer questions a production process has no data for.
+
+  **And `cluster` nearly got certified wrong by the same smoke.** With no manifest entry, `handleInspectCluster` answers **200** with a hardcoded single-process memory shape: `dialect: 'memory'`, `runnerHost: 'localhost'`, `runnerStorage: 'none'`. On a postgres deployment that is a confidently wrong answer to "is my cluster healthy" — worse than the 404 it replaced. The fixture is a memory app, so the fallback and the truth agreed and the endpoint looked fine. Wired properly now, from the same builder both paths call.
+
+  Guard additions: both paths must call the shared handler, and neither may dispatch a shared handler on its own — two copies of a router is the same defect as two copies of a wiring.
+- **@voltro/runtime, @voltro/cli** — `makeQueryFinalizer` — the tenant + soft-delete scoping composition now exists once, and both boot paths call it.
+
+  `applyTenantScope` and `applySoftDeleteScope` were extracted so that "there is no second copy that could drift" — the words are in that file's own header. Then the COMPOSITION became the second copy: `voltro dev` wrapped the pair in a local helper, `serveApi` inlined the same pair in the other spelling.
+
+  They agreed, which is the dangerous state rather than the safe one. Nothing kept them agreeing, and a third scoping concern would have landed in whichever file the author had open — producing a live query that filters one way in development and another in production, with no error on either side.
+
+  This is the variant a source-reading parity guard cannot catch: both paths supply something, both are right at their own call site, and they disagree about CONTENT. Detection does not help; one function does, because the disagreement then has nowhere to live. `bootPathParity.test.ts` additionally refuses a direct call to either primitive from a boot path, with a non-vacuity check so deleting the finalisation entirely cannot satisfy the rule.
+
+  Where the paths are genuinely allowed to differ is an `observe` hook: `voltro dev` warns about an org-less subject, an empty tenant scope and a non-indexed predicate; production pays for none of that. The observer receives a COPY — the first version handed it the live descriptor, so a warning could have rewritten the query, reintroducing divergence through the seam built to stop it. Its own test caught that.
+- **@voltro/cli** — **Plugin RPC interceptors did not run under `voltro serve`.** `plugin-audit` recorded nothing in production, `plugin-sentry` reported nothing from it, and `plugin-rbac` published no scopes there.
+
+  `wrapInterceptorsForKind` was called in `dev.ts` and in no other file, so every plugin's `interceptMutation` / `interceptAction` / `interceptQuery` was dead on the production wire.
+
+  Measured, not inferred: with `auditPlugin({ sink: 'console' })` installed and one action invoked over the wire, `voltro dev` logs the audit line and `voltro serve` logs nothing. After the fix both do.
+
+  It is the worst instance of the dev/serve class this repo has found, and it hid in the shape that makes the class hard. Nothing crashed. Nothing warned. The plugin manifest reported `interceptMutation: true` for each plugin — accurately, since the plugin does declare the hook. A consumer reading their DEV database found audit rows exactly where they expected them. Nobody was lying anywhere; the wire simply never called the hook.
+
+  **`metrics` is fixed by the same change and was the sibling defect.** serve built a metrics collector, handed it to one consumer and never wrapped its interceptors with it — so the endpoint would have reported an honest-looking zero. There is one collector now, the interceptors feed it, and the inspect endpoint reads that one off the serve handle.
+
+  Both are shared builders called by both paths, and `bootPathParity.test.ts` refuses a path that composes interceptors itself.
+
+  **If you run `@voltro/plugin-audit` in production: your trail has a hole for every release before this one.** Nothing was written. The rows you have are the ones your dev and any `voltro dev` deployment produced.
+- **@voltro/cli** — Plugin services reach workflow STEPS in production; the seed policy is stated instead of silent; and two loaders that could only ever work under `tsx` are fixed.
+
+  **Workflow steps.** `makePluginWorkflowStepLayer` was provided in dev only, so a step that yields a plugin service worked locally and failed in production with `Service not found` — the plugin's `onWorkflowStep` had nothing to attach to. Same builder, same metrics collector, both paths.
+
+  **Seeds are a decision now, and it is written down.** Production does NOT auto-seed: a rolling deploy starts N replicas, so an auto-seed runs N times, and the idempotency that makes that safe belongs to the app. `voltro db seed` from a pre-deploy job is the deliberate step, where migrations already live. What was wrong was the SILENCE — an app with seeds booted in production and nothing said they had not run, which is indistinguishable from them running and finding nothing to do. `voltro serve` reports them now, by name, with what to run instead.
+
+  **And wiring seeds into production surfaced a crash on the first boot.** `seedRunner` and `emailDiscovery` loaded app modules with a raw `import(pathToFileURL(file))`, which resolves the `.ts` SOURCE. Plain node cannot load it — the framework's own `@voltro/*` sources use extensionless relative imports — so it works under `voltro dev` (tsx resolves them) and dies under `voltro serve` with `Cannot find module …/packages/database/src/columns`. Both go through `importAppModule` now, and a guard refuses a declaration loader that does not. They were invisible for exactly as long as their surface was dev-only.
+
+  **The dev/serve backlog is now ZERO.** Every difference is either wired or a written decision, and the audit asserts the count is zero rather than "small".
+- **@voltro/cli** — Production records per-rpc metrics, and its traces carry the app's name.
+
+  Both found by the second axis of the dev/serve audit — **the same function called with different arguments**, which is the variant that does not crash and the one a "does serve call this?" scan cannot see.
+
+  `makeMutationRunner` / `makeActionRunner` took a `recordMetric` in dev and not in serve, so the metrics endpoint in production reported plugin buckets and no rpc buckets: half an answer, which reads like a whole one. Proven by boot — one action now yields `rpc action.people.add` alongside the plugin bucket, where before there was only the plugin one.
+
+  `buildTracingLayer` took a `serviceName` in dev and not in serve, so the same service appeared in a collector under its app name from development and as `voltro-app` from production. It stayed invisible because the runtime reads `OTEL_SERVICE_NAME` itself — so the production-hardening docs' instruction did work, and only an operator who had NOT followed it would have seen the difference.
+
+  Neither is dramatic. They are recorded in this shape because the class is: a difference in an argument, in code that runs on both paths, with nothing failing.
+- **@voltro/cli, @voltro/devtools-ui** — The Webhooks panel answers in production, and its Events tab shows **"subscribed, never emitted"**.
+
+  The inspect entry was wired into `voltro dev` and nowhere else, so the panel read a dev database — where nobody has real third-party subscribers — and replied "not configured" against the deployment that has them. All three layers it shows are plain reads of the app's own tables; nothing about them is dev-specific. It is the shared builder both boot paths call now.
+
+  That omission is worth separating from a deliberate one. `inspectSchedules` is absent from serve on purpose, with a written reason (dev computes `nextFiringAt` from values in its own boot closure, and reporting a guess to a post-deploy gate is worse than reporting nothing). Webhooks had no such reason — **and from the manifest the two read identically.** `bootPathParity.test.ts` now requires every dev-only inspect entry to be named with its justification, and carries the other eight as an explicit, counted backlog rather than as silence.
+
+  The new column comes from a consumer's suggestion. They shipped a create dialog offering eleven event checkboxes of which four were wired: ticking `team.updated` returned 200, showed the endpoint enabled and healthy, and delivered nothing, forever. Nothing in the framework could catch that inside their code — but the deployment knows which events have targets and which have ever produced a delivery, and the difference is the defect.
+
+  `everDelivered` is **not** derived from the deliveries list. That list is the most recent 200 rows, so an event delivered steadily but long ago would have read as never delivered — the exact false positive the column exists to avoid producing. It is its own bounded query, one per distinct subscribed event. The cell reports facts (`N subscribed · never emitted`), never a verdict: a target subscribed a minute ago is not a fault, and any threshold would be wrong for someone.
+
+### Internal (no consumer-facing effect)
+
+- **@voltro/cli** — `bootPathParity.test.ts` — dev/serve parity enforced from DERIVED sets rather than a curated list.
+
+  Seven capabilities have shipped wired into `voltro dev` and absent from `voltro serve`, each a silent production no-op, each found by a human noticing. The rule against it has been written in two `CLAUDE.md` files, with a checklist, since long before the seventh.
+
+  Every previous guard is per-feature and asks "does path X mention thing Y", so a NEW wiring is invisible to all of them — nobody remembered to add it. This one derives three sets from the source: modules that bind a change channel, imported symbols called inside an inline `onChange` body, and modules exporting a `wire*` / `attach*` boot builder. Each must be reached by both paths or appear in `DEV_ONLY` with a written reason. A new wiring is included automatically and fails until someone wires serve or says why not, which inverts the default.
+
+  Red-verified against the shipped `pluginRef` state: three failures, one from each rule. The inline rule is the one that matters — the module rule alone would not have caught it, because that wiring lived inside `dev.ts`.
+
+  Two entries currently justify themselves: the dev inspect CDC bus and the `VOLTRO_TIMELINE` recorder. A `DEV_ONLY` entry that is no longer asymmetric fails, so the exception list cannot decay back into a curated one.
+- **@voltro/cli** — The dev/serve audit gained its THIRD axis, for the one place it costs most.
+
+  The first two axes are "a call serve never makes" and "the same call with different arguments". The third — one value present in both paths and BUILT differently — has no general check, and it is the variant that costs the most while showing the least: both paths supply something, both are right at their own call site, and they disagree about content. Historically that was a cron reading one tenant in dev and every tenant in production, silently, because `tenantId == null` means "system".
+
+  What is checkable is the one constructor where it would hurt most. Every field a handler can reach comes from `makeAppContextBuilder`, so its input key set is the closest thing to an enumeration of the context surface — and the two paths are compared key for key, in both directions.
+
+  They currently agree, with one justified exception (`onEventEmit`, the dev overlay's SSE tap). Red-verified by dropping `store` from serve's call.
+- **@voltro/cli** — The `memory-api` e2e fixture grew the declarations its smokes were pretending to cover.
+
+  Every gap here was found by booting, not by reading:
+
+  - **no marked column**, so `GET /_voltro/inspect/data/rows` returned 200 and proved the endpoint answers — nothing about what it withholds. It now carries `.sensitive()` and `.serverOnly()` columns and an action that writes them over the real wire, so the production masking is asserted against a running server: `email` and `internalNote` come back `{ "__masked": … }` from `voltro serve` and in plaintext from `voltro dev`, with zero occurrences of the protected values anywhere in the response. - **no schedule**, so `inspectSchedules` and its FALLBACK both answered `{ schedules: [], coordination: 'single' }` — indistinguishable. One schedule makes the two answers different. - **no webhook-audience event**, so `inspect/webhooks` was empty either way.
+
+  Two things the fixture cannot prove, said here rather than implied:
+
+  - **`.encrypted()` is absent on purpose.** One encrypted column makes the whole table unwritable without a registered field cipher — the insert fails even when that column is left unset — and this fixture is also the driverless, plugin-light serve smoke. That axis is asserted in `inspectDataBrowser.test.ts`. - **`voltro serve` runs neither boot SEEDS nor `*.startup.tsx`.** A seeded row appeared in dev and never in production, which is why the fixture inserts through an action instead. Whether that is deliberate is a separate question and not answered here — it is recorded because it was discovered, and because an app with a `*.startup.tsx` gets it in development and not where it runs.
+
+---
+
 ## [0.27.0] — 2026-08-05
 
 ### Added

package/dist/index.d.ts

@@ -139,8 +139,26 @@ export declare interface AuditPluginOptions {
      * Derive the app's own scoping dimension for each recorded call.
      *
      * The framework cannot guess this: it does not know what a team, a project or
-     * a workspace is, which is exactly why the column is opaque. The app knows,
-     * and usually from the subject — `(ctx) => ({ teamId: ctx.subject.metadata?.teamId })`.
+     * a workspace is, which is exactly why the column is opaque. The app knows —
+     * from the subject, or from the call's INPUT:
+     *
+     *   (ctx) => ({ teamId: ctx.subject.metadata?.teamId })   // subject-shaped app
+     *   (ctx) => typeof ctx.input?.teamId === 'string'        // most apps
+     *     ? { teamId: ctx.input.teamId } : undefined
+     *
+     * **`input` is here because the subject-only version covered the wrong half.**
+     * A reporter's users belong to MANY teams, so their session carries no
+     * "current team" and cannot without inventing a concept their product does not
+     * have. A mutation's team comes from its input or from the row it loads. Their
+     * API-key subjects DO carry a `teamId` — which made the subject-only resolver
+     * worse than useless for them: it would have populated for key-authenticated
+     * calls and been null for every human one, so a filtered view would look like
+     * it worked.
+     *
+     * **The input here is RAW — it is not what `redactInput` will store.** That is
+     * required (a scope derived from a redacted payload is not derivable at all)
+     * and it is a hazard worth stating: whatever you return lands in `scope`,
+     * which is NOT redacted. Return the dimension, never the payload.
      *
      * Absent ⇒ `scope` stays null and the column costs nothing. Present ⇒ it is
      * written verbatim and can be filtered on equality, which is the difference
@@ -153,6 +171,8 @@ export declare interface AuditPluginOptions {
     readonly resolveScope?: (ctx: {
         readonly subject: Subject;
         readonly tag: string;
+        /** The call's raw input — before `redactInput`. */
+        readonly input?: unknown;
     }) => unknown;
     /**
      * Record QUERIES too.
@@ -221,6 +241,41 @@ export declare interface AuditPluginOptions {
      * function once you know your own inputs.
      */
     readonly redactInput?: 'all' | 'none' | ((event: AuditEvent) => unknown);
+    /**
+     * What happens to `AuditEvent.subject` before it is handed to the sink.
+     *
+     *   - `'metadata'` (DEFAULT) — `subject.metadata` is replaced by
+     *     `{ __redacted: 'all' }`. `type`, `id`, `tenantId` and `scopes` survive,
+     *     which is everything the trail is actually read for.
+     *   - `'none'` — the subject verbatim. What every sink did before this option
+     *     existed.
+     *   - a function — `(subject) => unknown`, for field-level control.
+     *
+     * **This exists because the durable sink wrote a live credential.** A reporter
+     * found a working Jira Personal Access Token in plaintext in 12 of 23 rows of
+     * their `_voltro_audit_log`, and neither plugin involved was wrong on its own:
+     *
+     *   - `@voltro/plugin-atlassian`'s `credentialsResolver` takes a `Subject` and
+     *     NOTHING else, so an app doing per-user Atlassian auth has no place to
+     *     put the caller's PAT except `subject.metadata`;
+     *   - this plugin serialised the subject verbatim into a json column.
+     *
+     * Two correct contracts that disagree about what a Subject IS — an identity,
+     * or a credential envelope — with nothing reconciling them.
+     *
+     * **The reasoning is `redactInput`'s, word for word, applied to the field it
+     * did not cover.** `metadata` is not a table column either, so no schema
+     * marker protects it; it is app-controlled, so its contents cannot be reasoned
+     * about here; and the framework's own per-user-credential mechanism puts a
+     * credential in it. The choice is between recording credentials by default and
+     * recording an app-controlled bag by default. Losing that bag is visible the
+     * first time you read a row; leaking a credential is not visible at all.
+     *
+     * `resolveScope` still sees the LIVE subject, so a scope derived from
+     * `metadata` keeps working — redaction applies to what is STORED, not to what
+     * the plugin can compute.
+     */
+    readonly redactSubject?: 'metadata' | 'none' | ((subject: Subject) => unknown);
 }
 
 /** The narrow read surface the entry points need. */

package/dist/index.js

@@ -136,19 +136,36 @@ var m = "_voltro_audit_log", h = d(m, {
 			...t,
 			input: n === "all" ? l : n(t)
 		};
-	}, f = (e) => s(e) ? a(d(e)) : t.void, p = (t) => {
+	}, f = (t) => {
+		let n = e.redactSubject ?? "metadata";
+		if (n === "none") return t;
+		if (typeof n == "function") return {
+			...t,
+			subject: n(t.subject)
+		};
+		let r = t.subject;
+		if (r.metadata === void 0) return t;
+		let { metadata: i, ...a } = r;
+		return {
+			...t,
+			subject: {
+				...a,
+				metadata: l
+			}
+		};
+	}, p = (e) => s(e) ? a(f(d(e))) : t.void, h = (t) => {
 		if (e.resolveScope !== void 0) try {
 			return e.resolveScope(t);
 		} catch {
 			return;
 		}
-	}, h = (e, n) => o(n.tag) ? t.suspend(() => {
-		let r = Date.now();
-		return e.pipe(t.tap((e) => f({
+	}, _ = (e, n) => o(n.tag) ? t.suspend(() => {
+		let r = Date.now(), i = h(n);
+		return e.pipe(t.tap((e) => p({
 			ts: r,
 			tag: n.tag,
 			subject: n.subject,
-			...p(n) === void 0 ? {} : { scope: p(n) },
+			...i === void 0 ? {} : { scope: i },
 			traceId: n.traceId,
 			input: n.input,
 			outcome: {
@@ -156,11 +173,11 @@ var m = "_voltro_audit_log", h = d(m, {
 				value: e,
 				durationMs: Date.now() - r
 			}
-		}).pipe(t.catchAllCause(() => t.void))), t.tapErrorCause((e) => f({
+		}).pipe(t.catchAllCause(() => t.void))), t.tapErrorCause((e) => p({
 			ts: r,
 			tag: n.tag,
 			subject: n.subject,
-			...p(n) === void 0 ? {} : { scope: p(n) },
+			...i === void 0 ? {} : { scope: i },
 			traceId: n.traceId,
 			input: n.input,
 			outcome: {
@@ -169,7 +186,7 @@ var m = "_voltro_audit_log", h = d(m, {
 				durationMs: Date.now() - r
 			}
 		}).pipe(t.catchAllCause(() => t.void))));
-	}) : e, _ = h, v = h, y = h;
+	}) : e, v = _, y = _, b = _;
 	return n({
 		name: "@voltro/plugin-audit",
 		description: "Records every mutation invocation; ships an audit() schema mixin for row-level metadata.",
@@ -185,9 +202,9 @@ var m = "_voltro_audit_log", h = d(m, {
 				i = x(e);
 			}
 		} : {},
-		interceptMutation: _,
-		interceptAction: v,
-		...e.recordQueries === !0 ? { interceptQuery: y } : {}
+		interceptMutation: v,
+		interceptAction: y,
+		...e.recordQueries === !0 ? { interceptQuery: b } : {}
 	});
 };
 //#endregion

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/plugin-audit",
-  "version": "0.27.0",
+  "version": "0.29.0",
   "description": "Audit plugin — ships the `audit()` schema mixin (createdAt/updatedAt/createdBy/updatedBy → Actor) plus an optional mutation interceptor that records every call to a configurable sink (console / memory / custom function).",
   "keywords": [
     "voltro",
@@ -37,9 +37,9 @@
     "node": ">=24.0.0"
   },
   "dependencies": {
-    "@voltro/database": "0.27.0",
-    "@voltro/logger": "0.27.0",
-    "@voltro/protocol": "0.27.0"
+    "@voltro/database": "0.29.0",
+    "@voltro/logger": "0.29.0",
+    "@voltro/protocol": "0.29.0"
   },
   "peerDependencies": {
     "effect": "^3.22.0"