@voltro/plugin-audit 0.27.0 → 0.28.0

package/CHANGELOG.md

@@ -39,6 +39,241 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [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.28.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.28.0",
+    "@voltro/logger": "0.28.0",
+    "@voltro/protocol": "0.28.0"
   },
   "peerDependencies": {
     "effect": "^3.22.0"