@voltro/plugin-flags 0.56.0 → 0.57.0

package/CHANGELOG.md

@@ -39,6 +39,200 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [0.57.0] — 2026-08-30
+
+### Added
+
+- **@voltro/client, @voltro/web** — <!-- `apiSurface: compatible` rather than `additive`: the golden line for `useFormBinding` CHANGED rather than being added, because the second parameter WIDENED from `string` to `string | ((values) => string)`. A widened parameter cannot turn a call site that compiled into one that does not — every existing `useFormBinding('app', 'todos.create', …)` still satisfies the union. The `@voltro/web` aggregate re-exports it, which is why it is listed: its golden describes a surface defined in `@voltro/client`, and regenerating the source package's golden does not regenerate the aggregate's. -->
+
+  **`useFormBinding`'s mutation may now be a FUNCTION of the current values.**
+
+  ```tsx
+  useFormBinding('app', (v) => (v.repeats ? 'calendarRecurringEvent.create' : 'calendarEntries.create'), { defaults })
+  ```
+
+  Some forms only learn their target from what the user does: a calendar entry becomes a recurring series the moment "repeats" is ticked, and the series mutation takes eleven more fields. Neither way out worked. Deriving the tag outside the binding is not available — the values belong to the binding and do not exist before it — and re-mounting with a different tag resets the engine, throwing away everything the user typed.
+
+  The schema in force follows the tag, so `fields` and validation always match what will actually be submitted, and the values survive the switch because the engine is constructed once and never rebuilt.
+
+  Two details that are decisions, not accidents. On the first render there are no values yet, so the function is called with the raw `defaults` — not the SEEDED ones, because seeding reads the schema and the schema comes from the tag being resolved. And the accessibility ids are pinned to the first resolved tag: they are DOM ids, and letting them move on the keystroke that flips the branch would remount every field, taking the focus and the caret with it — the opposite of what "switch the tag without losing the values" is for.
+
+  **Also: every hand-made `errorBus` in the client's own tests now uses the real `RpcErrorBus`.** Seven of them were `{ emit: () => {} }`, and they all broke the moment the bus grew a second channel — which is the cheap version of the failure a paraphrasing fake produces. A fake standing in for a seam that has a shared implementation should import it.
+- **@voltro/plugin-audit** — **`redact*: 'shape'` now buckets a string's length below a floor: `string(<16)` rather than `string(6)`.**
+
+  The mode exists so an audit row can end a diagnosis the payload itself cannot be shown for — the motivating case is a 113-character value where 44 were due, and the length IS the whole finding. A length is a small disclosure at that size and not a small one at six: a TOTP reported as `string(6)`, or a four-digit PIN as `string(4)`, tells a reader with log access exactly what shape to try.
+
+  The floor is where the two stop overlapping. Nothing this mode is FOR lives under it, so the default costs no diagnostic value. `auditPlugin({ redactionLengthFloor })` moves it — `0` for a deployment whose audited payloads are ids and tokens and every character of length is worth having, higher for one holding short human-entered secrets.
+
+  Two details that are decisions. **An empty string stays exact** (`string(0)`): "the field arrived empty" is a real diagnosis, an empty string is not a secret, and collapsing it would hide the one short length worth seeing. And the floor applies to described KEYS as well as values — a key that failed the declared-field test is a key carrying data, so its length is the same disclosure.
+- **@voltro/cli** — **`voltro logs --url` and `voltro traces --url` can read a deployed app now — and when they cannot, they say so instead of blaming your filters.**
+
+  Two defects, and the second is the cheap one that costs the most time.
+
+  **The flag existed for the case it could not serve.** `--url` addresses a deployed app; a deployed app runs `voltro serve`, which mounted neither `/_voltro/inspect/logs` nor `/_voltro/inspect/traces`. Our own docs name both commands as the way to debug a running app. A reader with cluster access can route around it by reading pod stdout — a customer on a hosted Voltro cannot, because inspect *is* the access.
+
+  `inspect: { logs, traces }` in `app.config.ts` arms a bounded in-process ring (`VOLTRO_INSPECT_LOGS` / `VOLTRO_INSPECT_TRACES` override per deployment, taking a size or `on`/`off`). **Off by default**, because a ring is memory on every replica for data most deployments already collect from stdout — the argument against a second span sink was an argument for a default, not for an absence. The endpoint handlers are the ones `voltro dev` already calls, and the span FILTER that decides what reaches the ring is now shared rather than copied: `traceRingSink.ts`, because a copied filter is a second definition nothing keeps in step, and this one is what stops `_voltro_traces` from recording its own INSERTs.
+
+  **"Found nothing" and "looked nowhere" read the same.** An empty result printed `no records matched the given filters.` — a claim that your filters were too narrow — with the truth in a `#` comment line below it, which is the first thing a pipe or a `| grep` drops. The invited reaction is to widen `--tail`, drop `--level`, extend `--since`, and get the identical sentence every time. When every target failed, the headline now says `NOTHING WAS SEARCHED` and carries the reason the endpoint gave — which the CLI was collapsing to `HTTP 404` and throwing away.
+
+  The 404 for these two also stopped saying "this endpoint is served by `voltro dev`". That was true and is now false in the one direction that matters: it tells a reader to stop looking when one config field stands between them and the answer. It names the switch.
+- **@voltro/cli** — **Two `voltro doctor` rules for defects that are completely decidable from the source — and were reported because nothing decided them.**
+
+  **`executor-builds-an-undeclared-field`.** Since 0.37 a descriptor's `output` IS the serializer, so a key the struct does not declare is stripped on the way out. Nothing errors and nothing warns: every reader downstream gets `undefined` and renders a blank. A deployment hit it twice in one session — a list executor built two fields, declared neither, and every picker showed empty options.
+
+  **`nullable-column-a-mutation-cannot-clear`.** A nullable column written through an input field that does not accept `null` can be set once and never emptied. The mutation succeeds, the column keeps its old value, and the user's second attempt looks like a UI bug. A deployment found five real cases only after a formatter happened to wrap one of their own line-based checks — which is the argument for doing it here: their rule was blind to exactly the inputs small enough to fit on one line, and stayed blind silently.
+
+  Both are ADVISORY, like everything in that scan, and both REFUSE rather than guess. The refusals are where the work went:
+
+  - A spread on either side of the output comparison means the key set is not knowable; reporting the visible half would name the field the author can already see and miss the ones they cannot. - An `output` that is a named schema rather than a literal struct is UNJUDGEABLE, not empty — the second reading makes every field a finding. - Declared names are flattened across nesting, because a literal inside `versions: Schema.Array(Schema.Struct({ version, op }))` builds names the contract declares one level in. - A literal that shares NO name with the declared output is not the output: a declarative query executor returns `{ descriptor: { table, order, take } }`, which the framework runs. - A table declaration the scan cannot find produces no finding, because "this table has no nullable columns" and "I could not look" lead to opposite conclusions.
+
+  The last two exist because the first version of the output rule was measured against four real apps and flagged two files, both wrong — one query descriptor and one nested row. Both are pinned as regression cases, each beside a falsification proving the fix did not turn into accepting anything. After them: 156 real files, zero findings; and injecting an undeclared field into a real fixture makes the rule name exactly that file.
+
+### Fixed
+
+- **@voltro/runtime, @voltro/cli** — **A schedule run whose process died suppressed every later firing of that schedule for six hours, on every replica, and logged `overlap skip` while doing it.**
+
+  The cross-instance overlap guard asks whether an occurrence is already running anywhere in the cluster. Its only evidence was the run row's `firedAt` against a constant, because that is all a row carried — and a constant that must never cut off a live run has to be longer than the longest one. So a pod killed mid-run left a `running` row that read as a live occurrence until the window expired. Against a half-hourly cron that is twelve missed occurrences from one restart.
+
+  `_voltro_schedule_runs` now carries **`heartbeatAt`**, bumped while the handler is in flight, and liveness is measured rather than assumed: silent for three beats is dead. A row with no beat — one written by a process still on the previous version during a rolling deploy — is dated by `firedAt` and bounded by the schedule's own `maxRuntimeMs`, because the watchdog records anything past it as `failed`. Same field and the same three cases as `_voltro_replace_in_progress.heartbeatAt`; it is deliberately not a lease, and nothing takes ownership of the run.
+
+  **The log line now carries what it measured.** `schedule: overlap skip` with `scope: 'cluster'` described two states — a peer genuinely working, and a corpse holding the schedule shut — while the word "overlap" asserted the first, and telling them apart meant reading the scheduler's source. It reports `heldBy` and `lastSeenMs` now.
+
+  **Two more defects found in the same function.** The query took the 200 most recent `running` rows across EVERY schedule and matched the name in JavaScript, so past 200 concurrent rows a live run falls out of the page and the guard silently stops guarding; the name is in the predicate now. And a `finishRun` whose update matched nothing returned in silence — the row stays `running`, which is exactly the state that suppresses the schedule, so the one write whose absence stops a cron had no failure signal at all.
+
+  `scheduling.scheduleHeartbeatMs` (env `VOLTRO_SCHEDULE_HEARTBEAT_MS`, default 30 s) is the cadence. Both boot paths pass the resolved value; a run shorter than one interval writes no beat and costs nothing.
+- **@voltro/cli** — **`voltro dev` crashed on boot for every API-only app.**
+
+  `tryRunWebDev` asks `loadConfig` for the app's WEB config and gets `null` whenever there isn't one — which is every `type:'api'` project, and any config that fails to import. That null is expected and handled: the function returns `{ ran: false }` and the caller boots the api alone.
+
+  The `health` block's resolution was inserted ABOVE that guard, so the first thing the function did was read a field off the null:
+
+  ```
+  TypeError: Cannot read properties of null (reading 'health')
+  ```
+
+  Two things about how it stayed invisible are worth more than the one-line fix.
+
+  **`tsc` had no chance.** The read is written `(config as { health?: … }).health`, and a cast on a maybe-null value erases exactly the nullability the compiler would have refused. The guard has no type-level protection, so it needed a behavioural one — `webDevNoWebConfig.test.ts` asserts the CONTRACT (`{ ran: false, exitCode: 0 }`, no throw) rather than the line order, and fails with the production error when the guard is moved back.
+
+  **And every symptom pointed somewhere else.** Eight integration files went red together, and all of them reported a TIMEOUT — `both replicas must boot`, at 300 s — because what a fixture observes is a process that never starts listening. A crash at boot and a slow machine are the same observation from outside, and the second is the expensive diagnosis to start with.
+- **@voltro/plugin-billing** — **A production boot with no `STRIPE_SECRET_KEY` silently selected the MOCK billing provider. It says so now.**
+
+  `resolveProvider` picks `stripe` when the key is present and `mock` when it is not. The zero-config default is right — add the plugin, see checkout flows, no account needed. What was wrong is how it failed later.
+
+  `STRIPE_SECRET_KEY` is a deployment variable, and one that silently stops being set is a routine event: a rotated secret, a typo in a values file, a CI variable nobody ever created. When that happens, an app that has been charging customers keeps answering every charge, subscription and invoice call SUCCESSFULLY, reaches nobody, and leaves nothing in the log to find afterwards.
+
+  A mock chosen by ABSENCE, under `NODE_ENV=production`, now warns — naming the consequence rather than the selection, and both ways out (set the key, or declare `provider: 'mock'` so the reader knows it was a decision). An explicitly declared mock stays silent: warning about a choice somebody made trains the reader to ignore the line that matters.
+
+  `NODE_ENV` decides only whether it is worth SAYING, never what is selected. Both environments resolve the same provider — an env-conditional behaviour is the shape a staging box sails past, and it is pinned as its own case.
+- **@voltro/cli, @voltro/protocol** — **A plugin's `declaredEnv: [{ required: true }]` now ABORTS THE BOOT when the value does not resolve. Nothing checked it before.**
+
+  The field has existed for a long time and ten-odd plugins fill it in. Three consumers read it — the env manifest, `voltro env`, and the secret MINT (which only handles `generate`, a secret that is OURS to invent). None validated `required`. Its own doc said "declaration only — metadata, not a read path", while `PluginEnvVar.generate`'s said "in production a missing secret refuses the boot": true for the minted kind, false for the one that matters — a third-party credential nobody can invent.
+
+  Declared, documented, read by three consumers, enforced by none. Every surface read as wired.
+
+  Every required entry now resolves before any plugin activates, on BOTH api boot paths, and a failure names the PLUGIN — the variable name alone appears in no file the reader owns, so without the attribution the next step is a grep through `node_modules`.
+
+  **A `secret: true` variable resolves through the configured secrets backend**, not just `process.env`, because that is where its value lives when one exists. A backend that cannot answer therefore fails the boot too — reported as `unreadable` rather than as an absent variable, because those are different facts and one of them sends the reader to the wrong file. A non-secret variable never touches the backend, so a misconfigured vault cannot fail variables that never used it.
+
+  Merging, when two plugins declare the same variable: `required` takes the stricter (a plugin that can live without the value must not weaken one that cannot), `secret` takes `true` (over-classifying hides something that did not need hiding; under-classifying prints somebody's credential into a dashboard — it is the only direction with a failure mode on one side). An app that declares the variable in `app.config.ts` overrides the plugin entirely.
+
+  **Upgrade note.** One first-party declaration is affected: `plugin-notifications`' `VOLTRO_VAPID_PRIVATE_KEY`, declared `required: true` and reachable only when web push is enabled. `voltro dev` mints it, as before; a production `voltro serve` with web push and no key now refuses to start, which is what that declaration has always said.
+- **@voltro/client** — **A consecutive-failure ceiling was counting a tab's LIFETIME, and the screen it stranded had nothing left to move it.**
+
+  `wireAuthRefresh` rebuilds the transport when a call comes back `Unauthenticated`, and `maxConsecutive` bounds it: after that many refreshes *with no successful call in between*, it stops, because at that point the credential is not stale — it is refused. "With no successful call in between" was carried by `AuthRefreshHandle.noteSuccess()`, a method the HOST had to call, and the only host never called it.
+
+  The consequence is not the loop the ceiling guards against. It is the opposite: three token rotations over an afternoon exhaust the budget, and from then on the tab never refreshes again. Every later expiry rejects every subscription the page opens, a rejected entry is terminal for its transport by design, so the screen waits on a spinner with nothing left to wait for.
+
+  `RpcErrorBus` has a SUCCESS channel now (`onSuccess` / `emitSuccess`), emitted by the same pipeline that emits the errors — a snapshot in the subscription cache, a settled mutation, a settled action. `wireAuthRefresh` subscribes to it itself, so no host has to remember anything; `noteSuccess()` stays for a host with a better signal of its own and is no longer what the policy depends on.
+
+  **`useSubscriptionHealth(apiName)` is new**, and it exists because the state it reports cannot be derived from any single hook. A refused subscription never retries, so there is no second error to react to, and `SubscriptionFailed` presents `data: undefined` — the value every reading layer derives `loading` from. A wrapper hook passing `{ data, loading }` through therefore turns a refusal into a permanent skeleton, and passing those two through is the natural shape to write.
+
+  const { healthy, failed } = useSubscriptionHealth('app') if (!healthy) return <Banner tags={failed.map((f) => f.tag)} />
+
+  Keyed by TAG, not counted — two failures of one call are one broken thing — and scoped to the api's runtime, reset when that runtime is rebuilt: carrying a failure across a transport swap would report a call as broken that has not been tried since.
+- **@voltro/plugin-notifications, @voltro/cli** — **About one generated VAPID key in 256 was 31 bytes, and a 31-byte key can never send a push.**
+
+  `createECDH('prime256v1').getPrivateKey()` returns the private scalar the way OpenSSL stores a BIGNUM — minimal length, leading zero bytes stripped. A P-256 scalar is a fixed-width field element, so a draw whose high byte is zero comes back 31 bytes (measured: 82 in 20 000), and two zero bytes gives 30 (1 in 20 000). Both generators had it: the plugin's `generateVapidPrivateKey`, and the `p256` branch of `voltro dev`'s secret mint.
+
+  The consumers were already right, which is what made this survivable and also what hid it. `vapidPublicKeyFor` REFUSES a non-32-byte scalar — a wrong VAPID key must fail loudly rather than at the first delivery. But the refusal happens inside `sendWebPush`'s `try`, so it came back as `{ kind: 'failed', status: 0 }`: the same outcome as the push service being unreachable. Nothing named the key. And the minted value is written to `.env.local` and stays, so an affected project's push sending is broken permanently and looks like a network problem forever.
+
+  Both generators left-pad now, and both packages assert the width on their OWN generator — deliberately not one reading the other's source, because a cross-package guard does not run when the suite is filtered to a single package.
+
+  **Worth recording is how nearly it was written off.** It surfaced as a single test failing in a full run and passing alone, roughly 1.6 % of the time — the exact signature of a saturated machine. Isolation "cleared" it twice. What settled it was not another isolated run but generating 20 000 keys and counting the widths: 0.41 % at 31 bytes is not noise, it is 1/256, and that number names its own cause.
+- **@voltro/runtime, @voltro/cli, @voltro/client, @voltro/kv, @voltro/plugin-broadcast** — **Seven reported points, all from one round. Every one of them is information the process already had, not reaching the person who needed it.**
+
+  **A `SqlError` reaching the client as a Defect carried no detail.** The log line said `Failed to execute statement` — no table, no column, no operation — while the trace exporter had written `db.query.text` for the same statement. The handler-failure logger has walked the driver cause for a long time; the DEFECT frame did not, so a failure that reaches the client without passing through that logger left an operator with nothing. It leads with the driver's own message now and points at `_voltro_traces`.
+
+  **A defect that repeats IDENTICALLY ends the resumable stream.** The reconnect loop is built for a transport drop, and a transport drop does not repeat itself verbatim; a broken statement does. So one broken query spent the whole `maxReconnects` budget, and the user watched a spinner and then read "connection lost" — describing the opposite of what happened. TWICE, not once: the first failure is genuinely ambiguous, the second identical one is not. Also documented: `reconnects` is the RUN TOTAL and `maxReconnects` bounds CONSECUTIVE reconnects without progress, so "attempt {reconnects} of {maxReconnects}" renders `5/2`.
+
+  **`voltro build` reported a config that failed to LOAD as "no web app found".** It used the wrapper that discards the import error, so an `app.config.ts` that IS an api and simply threw came out as a claim about the app's TYPE. The message now distinguishes the two, prints the error, and names both types.
+
+  **The `subscriber-effect-without-once` rule found one of four.** The helper name matched by EQUALITY, so `notifyAbsenceRequested` fell through while `notify` reported — a prefix now. And it read only the handler body, so a write one call level down inside the same file was invisible; the file is already parsed. What it still cannot see (a write in another module) is SAID: the report prints how many subscribers declare no `once:` against how many the rule found an effect in, because "1 file(s)" read as an inventory.
+
+  **`voltro dev` had no probe surface on a web app**, and `/internal/*` did not 404 — it fell into the page router. An SPA shell answered 200 with HTML, a loader redirect answered 303, an auth guard answered 303 to `/login`; a kubelet reads all three as PASS. One of those pages had a loader calling the api, so the WEB pod's readiness hung on the API's reachability once per probe interval. All three boot paths now answer through one matcher, before routing — and `health: { path, liveness, readiness }` in `app.config.ts` makes the paths and the answers the app's, for both app types. "Ready" is a dependency ping for an api and its opposite for a screen that must keep showing its last frame.
+
+  **Every hot reload ended as a crash.** ioredis emits `error` on an EventEmitter, and node turns an unhandled `error` event into an uncaught exception — so a client with no listener made every close with commands in flight a process crash. Functionally harmless (the supervisor restarts) and every reload read as a crash loop in Kubernetes. Both `@voltro/kv` and `@voltro/plugin-broadcast` register one on every client. The watcher also ignores a tool's scratch file (`vitest.config.ts.timestamp-…mjs`), which was restarting the app twice per test run.
+
+  **A row filter's resolution is now reported.** Between "refuses everything" (which an older version did, loudly) and "applies nothing" there was nothing to see: every read would widen and no log, test or `doctor` would say so. The framework says so the FIRST time a filter resolves on a live read path — a fact from the running system rather than an echo of the declaration. And a new advisory `doctor` rule reports a handler that hand-writes a predicate on a table the registered filter already covers: never a leak (two identical predicates ANDed are as tight as one), but an authorization rule maintained in places the framework already knew about.
+- **@voltro/client** — **A mutation, workflow start or upload fired from a mount effect hit the client boot window and failed with the stub's message. Only `useAction` waited it out.**
+
+  Between the first client commit — children render against the loading stub so `hydrateRoot` can adopt the SSR DOM — and the moment the supervisor resolves the real rpc client, `handle.client` is a proxy that throws on any access. Measured in real chromium at ~15–30 ms, and wider in an app that mints a token in `authHeaders` before connecting. `useEffect(() => { mutate(...) }, [])` is the ordinary shape that lands inside it.
+
+  `useAction.run` was fixed for exactly this, with a unit test and a browser measurement. `useMutation.mutate`, `useWorkflow`'s five callbacks and `useUpload.upload` had the identical defect for as long, and the failure was worse than a delay: the stub's `not-yet-resolved api` DISPLACED whatever the real outcome would have been, so the message a developer read described our plumbing rather than their call.
+
+  All four seams go through one `awaitResolvedApi` now, and each reads the handle from a ref at CALL time. A `useCallback` dep list cannot solve this however correct it is — the callback a mount effect fires was built on the first render, before the re-render that would rebuild it.
+
+  `useMutation` waits BEFORE staging optimistic patches, not just before the network call: the stub carries a different `cache` instance, so patches staged against it would land in a cache no live subscription reads and then be reverted against the wrong one.
+
+  **The rule is asserted over the SET** (`bootWindowSeams.test.ts`), because a per-hook test can only demonstrate one member. A fifth imperative hook inherits it by being written rather than by being remembered — which is precisely what did not happen the first time.
+- **@voltro/cli** — **The boot's `reactivity:` line reported what the dialect COULD run, not what was running — so the deployment with no cross-replica fan-out was the one told it had none missing.**
+
+  `wireBroadcastBus` derived it as `postgres || mysql || mariadb`. A dialect is capable of a native transport; that is not the same as one being started. With `CDC=0` — which any deployment whose database grants no REPLICATION privilege has to set — the change reader never runs, and the boot still announced
+
+  reactivity: cross-instance via native binlog CDC (mariadb)
+
+  The crooked sentence is the smaller half. Without a broadcast plugin this line is the ONLY thing said about cross-replica reactivity, and the branch it displaced is the WARNING that there is none. It is also the line our own guidance names as the check for whether the native-CDC amplification applies to you, and there it answered yes where the truth was no.
+
+  It reads `store.changeScope` now — `'fleet'` exactly when change capture is running, and the same value `remoteChangesVisible` takes two calls later, so the honest signal was already in scope. Derived rather than enumerated: a sixth dialect with a native transport joins by itself, and an app that turned capture off because every table is `.nonReactive()` is covered without anyone remembering that path exists.
+
+  The enumeration was also wrong in the other direction — **mssql (Change Tracking) was absent**, so a deployment running a real cross-instance transport was being warned it had none.
+
+  And the warning that fires in the CDC-off case names the cause instead of the dialect. The old fallback told a mariadb operator to "use ... mariadb (binlog CDC)", which reads as boilerplate to the one person who needed to act on it.
+- **@voltro/runtime** — **A row-filtered table reached through `.with(...)` is narrowed now, where it used to be refused — and before that, served unfiltered.**
+
+  An eager load resolves BELOW the seam that AND-merges the filter onto a read's base table: the stores expand the eager tree themselves, the memory store by recursing through its own raw read and the SQL stores by folding the relation into one join or JSON aggregate. Measured when it was found: a filter restricting a relation target to the caller returned exactly the caller's row on a direct read and BOTH rows through `.with()` on the same data.
+
+  That shipped as a refusal, on the reasoning that the real fix meant applying the filter inside eager compilation across four dialect stores. **It is not that change.** Every eager branch already accepts a `where`, and both resolvers already honour it — the walker ANDs it into the relation's lookup descriptor, the JSON compiler emits it into the correlated subquery on all five dialects. So the middleware writes the filter where a caller could have written it, and every resolver applies it without knowing a row filter exists. One rewrite, six execution paths, no dialect emitter touched.
+
+  A caller's own `where` is kept and the filter goes UNDER it: a branch you narrowed stays narrower, and nothing a caller writes can widen the filter. Nested `.with(...)` is narrowed at every level.
+
+  **One case still refuses: a row-filtered `manyToMany` JUNCTION.** A branch `where` is a predicate on the relation's TARGET, so a filter narrowing the junction has nowhere to be expressed. Narrow and honest beats a rewrite that looks complete.
+
+  Verified on the walker (unit, in-memory store) AND on the JSON-aggregation path against a real postgres, because those are two separate implementations and the suites that cover them each mock the other's half.
+- **@voltro/client** — **Two dev-time messages said something the code had not measured.**
+
+  **The store's equals-footgun warning blamed the selector.** It read *"the selector returns a NEW object each call"* — and the site cannot observe that: an identical state returns from the cache before the selector runs, so everything reaching the warning arrives with a CHANGED state. Shallow-equal-but-not- identical there has two producers, and the message asserted one of them:
+
+  - the selector BUILDS (`s => ({ a: s.a })`), or - the STORE wrote an equivalent new value — `set({ crumbs: [] })` on leaving a page and again on entering the next is two different empty arrays.
+
+  Both waste the render and both are fixed by `{ equals: shallow }`, so the advice was right while the diagnosis pointed at the wrong half — and a deployment reading the second case went looking at a selector that had been returning the same reference all along. The warning now MEASURES which one it is: it re-runs the selector on the previous state (dev only, at most once per store, on a selector required to be pure anyway) and says either "the selector builds" or "the store is writing an equal value".
+
+  **And a validation template rendered its own placeholder.** `interpolate` left an unfilled `{param}` in place, so a template whose parameter was missing put a literal `Mindestens {min}` into the interface. It reports the hole now and the caller falls through to the issue's own rendered sentence, which is complete by construction. The reported route is closed twice over: counting rules supply BOTH `count` (the name an i18n layer pluralises on) and `min` (the built-in template's), so a framework-derived issue cannot reach it; a hand-written annotation still can, and a raw placeholder is never the right answer.
+- **@voltro/cli, @voltro/ai** — **`@voltro/ai`'s resumable-stream tables were declared, bounded, documented — and never added to the migration set.**
+
+  `dataStoreResumableStreamStore` writes to `_voltro_stream_events` and `_voltro_stream_state`. `frameworkTableAssembly.ts` imports six `@voltro/ai` tables and did not import these two, so `voltro db plan` answered *schema is up to date* while both were absent, and the first user's turn died inside the store rather than at boot.
+
+  They are assembled now for any app that DEPENDS on `@voltro/ai`, so all four schema-declaring paths plan them.
+
+  **The gate is the dependency, not a file convention, and that is the half worth knowing.** Every other flag in `FeatureMix` reads a filename — `*.agent.tsx`, `*.connection.ts` — and `dataStoreResumableStreamStore(ctx.store)` has none: it is an ordinary call, reachable from an action, a query, a workflow step. Gating on `agents` is the obvious guess and it is wrong, because an app can stream without declaring a single agent file. The manifest is the superset that CAN reach the store, it comes from the source tree, and every process in one deployment computes it identically — the constraint the declared set is under.
+
+  `loadDiscovered` now REQUIRES a `root` for the same reason: the flag is read from a manifest, so it cannot be derived from the file list, and a mix that quietly answered `false` because nobody passed a root would declare a smaller schema than the same tree declares elsewhere. An optional root would read exactly like one that was supplied.
+
+  **And the documentation said to do something that does not work.** The JSDoc and the docs page both instructed *"add them to the database barrel (or they ride along with a `*.agent.tsx` app)"* — both halves wrong, since discovery is file-based (`*.entity.ts`) and the store is not agent-only. That sentence had reached the shipped agent guide, so it was teaching every downstream coding agent a remedy with no effect on the plan. Corrected in the JSDoc, in both languages of the docs site, and regenerated.
+
+---
+
 ## [0.56.0] — 2026-08-29
 
 ### ⚠ BREAKING

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/plugin-flags",
-  "version": "0.56.0",
+  "version": "0.57.0",
   "description": "Feature flags — per-subject / per-tenant targeting, deterministic % rollouts, kill-switch. Gate mutations/queries/actions declaratively or guard in-handler; evaluate flags client-side for UI gating. Config-as-code (memory) or runtime-toggleable (postgres).",
   "keywords": [
     "voltro",
@@ -48,10 +48,10 @@
     "node": ">=24.0.0"
   },
   "dependencies": {
-    "@voltro/client": "0.56.0",
-    "@voltro/database": "0.56.0",
-    "@voltro/logger": "0.56.0",
-    "@voltro/protocol": "0.56.0"
+    "@voltro/client": "0.57.0",
+    "@voltro/database": "0.57.0",
+    "@voltro/logger": "0.57.0",
+    "@voltro/protocol": "0.57.0"
   },
   "peerDependencies": {
     "effect": "^3.22.0"