@voltro/ui-shadcn 0.68.0 → 0.69.1

package/CHANGELOG.md

@@ -39,6 +39,316 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [0.69.1] — 2026-09-11
+
+### Added
+
+- **@voltro/cli** — `voltro dev` and `voltro build` refuse a published artefact. A publish step writes `.framework/dist/.voltro-artifact.json` into a package that ships its build and no source; both commands look for it before loading the config or booting anything and exit 1 with the reason. An image built without the dev toolchain is a hindrance; this is the rule — a toolchain installed by hand into that image still cannot develop or rebuild the package. A developer's own tree never carries the marker, built or not, so nothing changes there.
+- **@voltro/database, @voltro/cli** — `voltro db plan` names the tables on which the live and the declared fingerprint part — in the JSON record, and on a TTY for an empty plan.
+
+  `fingerprintLive` hashes the whole live introspection, every table included; `fingerprintDeclared` hashes the declaration. A plan of zero operations says the schemas agree, and the two hashes can still differ — over a table the diff never compares (`cluster_*`, an undeclared `_voltro_*`, a soft-drop snapshot, a name in `VOLTRO_DB_IGNORE_TABLES`), or over a detail the diff calls equal that introspection reports differently from how it was declared. The TTY printed a caveat under the two; the JSON record a migrate job writes carried none, so `0 operations` under two different hashes read as a contradiction and raised the question whether the computation had changed.
+
+  The plan carries `fingerprintDivergence: { outsideDiff, diffEquivalent }` now, both lists of table names, and the record carries it with a one-line `fingerprintNote`. On a TTY the fingerprint line lists them, and an empty plan prints it only when the two part somewhere, so a clean schema stays a one-liner. The earlier wording — "a live hash never equals a declared one" — was wrong as a rule: a schema whose every detail introspects back as declared hashes the same on both sides, and does.
+
+  `voltro serve` is not part of this: its boot check compares the declared fingerprint against the one the last `voltro db apply` RECORDED, never the live hash.
+- **@voltro/client, @voltro/web** — The client diagnostics snapshot carries `runtime` — per api, what the runtime resolved to (`scheduler`, `generation`) — outside the event ring.
+
+  `runtime.resolved` is recorded when the runtime is built, which makes it one of the first events of a session, and the first events are exactly what a `clear()` before a measurement or the ring's eviction removes. An export taken after either carried every reconnect event and no statement about which scheduler produced them; a reader checking whether the yield channel was in use had to inspect the bundle by hand. The snapshot keeps the last resolved record per api in its own field now, and `clear()` leaves it in place — it describes the runtime, not the timeline.
+- **@voltro/plugin-openapi, @voltro/protocol, @voltro/cli** — `openapiPlugin` documents the app's own REST surface as the framework mounts it — every `restRoutes` descriptor and every `publicApi` projection — without the app listing them (`includeAppRoutes`, default `true`). A plugin can implement the new `onRestSurface(routes)` hook and is told the mounted routes on both boot paths once they exist. Importing descriptor modules into `app.config.ts` to build that list is no longer needed, which is the path on which a boot had hung.
+- **@voltro/workflow, @voltro/cli** — A `run-stalled` report on the durable engine carries the engine's view of the run — its journal messages, whether each was processed and last read, and who holds the lock on its shard — and the staleness tick warns about unprocessed messages no runner has read for the engine's own re-read window.
+
+  The engine's recovery for a run whose process died is real and silent: a runner that acquires a shard re-delivers the shard's unprocessed messages, and re-reads any whose `last_read` is older than ten minutes. The state with no symptom is the one where no runner acquires the shard — a postgres advisory lock held by a session that is not a live runner (a backend the server has not reaped, a pooled connection that outlived its client) — and the run then sits `running` with nothing moving while every process reports healthy. `ClusterDiagnostics` (provided by `workflowEngineLayer`) reads that state: `messagesFor(executionId)`, `unreadMessages()`, `shardLockHolders(shardIds)` (postgres advisory holders from `pg_locks` + `pg_stat_activity`, row leases from `cluster_locks`), `runners()`. Both boot paths attach it to the stall report as `cluster` and log `workflow.cluster: unprocessed messages no runner has read for the re-read window` with the holders, so the report names the pid to terminate — or the lease mode (`VOLTRO_WORKFLOW_SHARD_LOCK=row`) that bounds the wait.
+- **@voltro/runtime, @voltro/voltro** — `EffectStoreOps.upsertWithOutcome` — the Effect form of `upsertRowOutcome`, on `yield* EffectStore` and on the `tx` view `transactional` hands out.
+
+  `upsertRowOutcome` required `store.upsertWithOutcome`, which `ctx.store` provides and `EffectStoreOps` did not declare, so an Effect handler running its ingest inside `transactional` — the place the outcome was built for — kept a pre-read to report `created`. The operation answers `{ row, outcome: 'inserted' | 'updated' }` on the `StoreError` channel like every other op; a hand-written `DataStore` without it is refused with the same message the typed helper gives.
+
+### Changed
+
+- **@voltro/cli** — `voltro test` exits 1 when it executed no test, on every invocation — a bare `voltro test` included.
+
+  A filter that matched nothing and an explicitly named directory with no tests already failed. The bare command was the exception, kept as "a fresh app with no tests yet shouldn't fail its pipeline" — and that is the one exception a CI cannot see: a tree whose tests were all misnamed, moved or deleted printed green forever, with `if voltro test` seeing nothing. Every scaffold ships tests, so nothing needs the exception. The refusal for a stale `rpcGroup.generated.ts` already exited 1; this closes the remaining route to a green line over zero tests.
+
+  vitest's own `--passWithNoTests` is honoured verbatim when a green run over nothing is what you want; it used to be overridden.
+- **@voltro/runtime, @voltro/voltro, @voltro/cli** — `ApiKeyStore.ensureActor` receives the `issue()` input, and the built-in `apiKeys:` wiring takes an `ensureActor` of your own.
+
+  0.69.0 made issuing a key plant its `actors` row through a required `ensureActor({ id, displayName })`, and its note said the framework stores need nothing from you. Both were written for the BUILT-IN `actors`. An app may declare its own — it takes precedence over the built-in table — and that table need not carry `kind` or `displayName` at all and may require columns the hook never saw: which kind of key this is, whom it belongs to, which team it acts for. All of that is in the `issue()` input (`metadata`, `onBehalfOf`) and nowhere else, so the only complete row was one written AFTER `issue()` returned — and a hook that wrote a minimal row first collided with it on the table's own unique keys.
+
+  The hook receives `input` now — verbatim, and on a rotation the input the rotation rebuilt from the old row, so ownership survives rotation there too. The two framework stores read `id` and `displayName` and ignore the rest; a hand-written store can build the complete row before the key exists. Additive for an implementor: a function taking the narrower object is still assignable.
+
+  For an app that declares its own `actors` and uses the built-in wiring, the 0.69.0 write (`{ id, kind: 'apiKey', displayName }`) does not fit that table, and since 0.69.0 that meant `issue()` failed at the actor write. `apiKeys: { ensureActor }` in the config replaces exactly that write, on both boot paths.
+
+  A note under an already-crossed version is never seen again, so the corrected guidance is re-issued as codemod `0.69.1/01_ensure-actor-receives-the-issue-input`, gated on a hand-written `ApiKeyStore` OR an app-declared `actors` — the second group is affected without ever having written the first, and the 0.69.0 gate did not reach it.
+- **@voltro/protocol** — A `GET` projection coerces the query string toward the descriptor's input before decoding: `?limit=5` reaches a `Schema.Number` as `5`, `?archived=true` a `Schema.Boolean` as `true`, and a repeated parameter a `Schema.Array` as its elements; a value that does not read as the target is left for the schema's own `400`. A projection of a procedure without an `openAccess` decision now carries `requireAuthenticated()` — an anonymous caller answers `401` before the handler runs, where it used to reach the handler and surface that refusal as a `500`. A typed error the handler fails with, one of the descriptor's declared `error:` variants, answers with its tag and fields as the body under the status `publicApi.errorStatus` assigns it (`422` when unlisted); an undeclared error stays a `500`.
+- **@voltro/cli** — `voltro dashboard` has no dev fallback any more. A dashboard tree without a build used to be served by `voltro dev` — right for the monorepo source layout, and exactly the mode a deployed dashboard must never enter: a package that lacked its build would have booted a Vite dev server with a freshly minted inspect token on a public hostname, with a `mode: 'dev'` log line as the only sign. The command now refuses a tree without a build in every environment and says where a source tree is served from (`voltro dev <path>`, which the auto-launcher already picks on its own). Removed rather than gated: a gate is one environment variable away from open. The dashboard image is built to have no such door at all — installed without optional dependencies, so the build and dev toolchain is absent, and started through the bin's in-process start path.
+- **@voltro/database, @voltro/cli** — A declared snapshot and the live snapshot of a database the planner has converged on hash the SAME — the fingerprint canonicalises by the planner's own equivalence rules, and the declared snapshot carries the widths the emitter renders.
+
+  `fingerprint.ts` promised that two snapshots of identical observable shape produce identical fingerprints. Measured on a MariaDB: a plan of zero operations under two different hashes, and practically every table hashing apart from its own declaration. The planner decided "nothing to do" through helpers the fingerprint never saw — `restrict` folded into `noAction` on every foreign key (MySQL reports RESTRICT, SQL Server NO ACTION), `now` against `current_timestamp(6)` on every timestamp, a boolean default against the engine's `0`/`1`, `oneOf` compared as a set — and hashed the raw fields instead. And the emitter renders widths the declaration never spells out: `VARCHAR(255)` for a `oneOf` text, `VARCHAR(64)` for a typeid `id()`, a bounded key on mssql for indexed text; introspection reports them as `maxLength`, the declared snapshot carried nothing.
+
+  Those rules live in one module now (`columnEquivalence.ts`), imported by the planner and the fingerprint alike — a second copy is how the two disagreed. The fingerprint hashes the canonical column: references through `normRef`, defaults as the comparable token, `oneOf` sorted, a postgres BIGSERIAL's implicit sequence as the no-default it is to a numeric id, a soft-drop snapshot column left out as the planner leaves it out. `declaredSnapshot(tables, dialect)` materialises the width `sqlType` renders — the same function that renders CREATE TABLE, so the DDL is byte-for-byte what it was; an explicit `.maxLength(n)` is never touched, and a `text()` that renders unbounded stays unbounded. Verified against the database that showed it: the six remaining `diffEquivalent` tables after the first pass were all boolean defaults, and none remain.
+
+  **What this changes for a running deployment: the declared fingerprint of every schema with a foreign key, a default or a `oneOf` moves once.** A `voltro dev` boot runs the plan, finds nothing, and records the new value on its own. `voltro serve` compares the declared fingerprint against the last one `voltro db apply` recorded, so the pre-deploy `voltro db apply` your pipeline already runs is what records it — an apply that finds nothing to do records exactly for this case. `voltro db drift` reports the live side moved once too, until that apply re-baselines it.
+
+  `voltro db squash` now passes the dialect to the declared snapshot it fingerprints; it was the one caller that did not, and its hash disagreed with the boot's.
+- **@voltro/cli** — A production `voltro start` no longer reads `src/`. `voltro build` writes the route tree beside the SSR bundle (`dist/server/pagesTree.json`, the same walk the bundle's lazy page loaders were generated from), and `start` boots from it; the font head was already baked into the built shell. So a deployed web app is `.framework/` plus `app.config.ts` and its `node_modules` — the TypeScript source can stay out of the image and out of a published app package. Only an unbuilt tree (the Vite middleware fallback that is not a production path) still walks `src/pages`. A production start that finds an SSR bundle without the tree beside it refuses with the instruction to rebuild, rather than quietly falling back to the source.
+- **@voltro/cli** — `voltro start` drains on SIGTERM the way `voltro serve` does: readiness flips to `503`, the long-lived inspect streams are ended (their client reconnects), the listener closes and in-flight requests finish inside 60% of `VOLTRO_SHUTDOWN_GRACE_MS`, then the SSR loader, cache backend and registry entry close and the process exits `0` with a `drained in <ms>` line. Before this the web path closed its listener and exited: a render in flight when the signal landed was cut, and the docs described a drain with an env var (`SHUTDOWN_GRACE_MS`) that nothing read. The docs now name the real variable and the real order.
+
+### Fixed
+
+- **@voltro/cli** — `voltro agents-md` finds the project's `@voltro/cli` under the app it was run from, not only at the workspace root.
+
+  Its provenance line looked in `<root>/node_modules/@voltro/cli` alone, so a pnpm-strict install (`apps/<name>/node_modules/@voltro/cli`) reported `project has no resolvable @voltro/cli … installed: null` — from a command that was running that very cli. The candidates are now the directory the command started in and every directory up to the root, the root, then every discovered app, in that order.
+- **@voltro/cli** — `voltro update` prints the backfill for API keys issued before 0.69.0 to the apps that have them.
+
+  The 0.69.0 note `05_api-key-store-plants-its-actor` carried the instruction — one `actors` row per existing key — in its last paragraph, and gated the whole note on a hand-written `ApiKeyStore`. An app on the framework store, which is the app that holds such keys, saw `1 skipped (own check found nothing)`. A note under an already-crossed version is never printed again, so the paragraph is re-issued under `0.69.1/02_existing-api-keys-get-their-actors-row`, gated on using api keys at all (`apiKeys:` in the config, `apiKeyStrategy`, or an `ApiKeyStore`), with the loop that plants the rows idempotently through `insertIgnore`.
+- **@voltro/workflow, @voltro/cli** — `onFailure` fires for a run whose body failed — the route the documentation listed first and the one that was not wired.
+
+  The three flow-control routes into the failure signal (an expired `timeouts.start`, a `timeouts.finish` cancellation, a dead-lettered intent) reached the handler through the drainer's `onAbandoned`; the run recorder's terminal hook only released the admission lease. So a deployment saw its `onFailure` workflow run for a finish-timeout cancellation and stay silent for the runs that had actually failed. The recorder's `onTerminal` now carries the payload and the error on `failed`, and both boot paths build their hook with `makeWorkflowTerminalHook`: release the lease, then — for a workflow that declares `onFailure` — start it with the same `WorkflowFailureReport` the other routes send (`reason: 'the run failed with <errorTag>'`, `runId`, `executionId`, the payload). A workflow that declares nothing stays exactly as loud as before.
+- **@voltro/cli, @voltro/protocol** — A `publicApi` projection — and every hand-written `restRoutes` entry — now runs under the app's row filter. Both boot paths built the REST request's context from the subject alone, so for an app that registered `setRowFilter` the context builder's unfiltered-read guard refused every REST request before its handler ran: `500` on every route, in development and production alike. The shared REST surface now resolves the row filter for each request (`withRowFilter`, the same spine the rpc runners walk) before the context exists, and the context builder runs inside the route's failure mapping rather than escaping it as a transport defect.
+
+  Behind that refusal sat a second defect the refusal had been hiding: the one-shot read of a projected query went through the raw store, so once the request had a row filter it still returned every row of the table — the filter was resolved and never applied to the read. The one-shot runner now reads through the request-scoped store the context builder wraps (row filter and tenant scope applied), the store the handler itself would read from. The subscription and socket arms were already filtered.
+
+  The REST failure mapping is one function for every place a route can fail: `RestRouteError` and `{ status }` errors keep their status; the framework's `ScopeError` answers `403`, or `401` for an anonymous caller; `Unauthenticated` answers `401`; everything else is the reported `500`. A repeated query parameter (`?tag=a&tag=b`) reaches the input as an array of every value instead of the last one.
+- **@voltro/workflow, @voltro/cli** — `timeouts.finish` cancels at the deadline plus at most one drain tick — not at whatever start next happened to wake an idle drainer.
+
+  The bound is enforced by the admission drainer's tick, and the drainer disarms when nothing is pending. A run admitted straight through writes nothing to the queue, so with an empty queue the drainer slept while the run passed its bound and cancelled it only when an unrelated arrival woke it — measured as cancellations landing tens of minutes late by amounts that depended on traffic. Two changes: the finish sweep reports the earliest deadline among the running runs it saw, and `drainTick` folds it into `nextDueAt`, the instant the drainer arms for; and a run STARTING wakes the drainer in an app that declares a finish bound, so the tick that follows reads the new deadline. Both boot paths, through the shared wiring.
+- **@voltro/cli** — The `helm` baseline (`voltro baseline set helm`) probed `/healthz` on the api and `/` on the web — the first answers 404 on every Voltro boot path, so an api pod could never become ready; the second is answered by the SPA shell with 200 for anything, so a web pod could never become unready. Both deployments now probe what the framework answers before routing — `<path>/startup`, `<path>/readiness`, `<path>/liveness` — with a `probes` block per app (path, periods, thresholds) and a `shutdown` block that renders the `preStop` sleep, `terminationGracePeriodSeconds` and `VOLTRO_SHUTDOWN_GRACE_MS` together, since they are one budget. `PORT` is set from the chart's port so the Service and the listener agree.
+- **@voltro/cli** — `/_voltro/inspect/stream` under `voltro serve` no longer refuses a non-loopback `Host`. The DNS-rebinding host guard is a `voltro dev` measure — the dev api binds every interface and has no hostname of its own — and the JSON inspect door has only ever applied it there. The live stream's shared wiring applied it on every boot path, so behind a Kubernetes Service, a docker network name or an ingress host every JSON endpoint answered the dashboard's bearer with 200 while the stream answered the same bearer with `401 forbidden host` — a refusal that reads as a token problem and is not one. The stream now takes the guard from its door: on in dev, off in serve, where the surface is fail-closed on the token alone.
+- **@voltro/cli** — `voltro dev` stops, with exit code `3`, when the project's installed `@voltro/cli` is no longer the one it is running — instead of restarting on the old one and reporting it as complete.
+
+  The supervisor respawns the api child from its own entry, resolved once at boot. Swap `node_modules` under a running `voltro dev` (a `voltro update`, an install that bumps the cli, a volume replaced under a pod) and every restart after that booted the cli the supervisor started from, printing `restart complete — api ready` for an api composed by code the disk no longer had; nothing in the log said which cli built it. The supervisor cannot re-exec itself, so on the next file change it compares what the root installs with its own version and stops on a difference, naming both and the path — under a restart policy the process comes back on the installed version, in a terminal `voltro dev` is started again. The ready line now carries `cli=<version>`, and a first boot on a cli the project does not install is warned about rather than stopped, because a workspace binary against a checkout is legitimate.
+- **@voltro/cli** — `voltro update` puts every `package.json` it bumped back, byte for byte, when the install fails without ever fetching the target version.
+
+  The bump is written before the install runs — that is what the install resolves against — and an install can fail for a reason the tree had no part in. A lockstep release lands on the registry one package at a time, so the moment the FIRST `@voltro/*` package is there the latest version resolves to the new release; an update started in that minute bumped every manifest and then met `NO_MATCHING_VERSION` on a sibling that was seconds from landing. What it left behind was the worst of the three states: manifests saying the new version, lockfile and `node_modules` saying the old one, and `voltro update` itself reading the manifests as "already there".
+
+  Which state a failure leaves is now measured off the tree, not read off the exit code. A bumped package present in `node_modules` at the target version means the install fetched the release and failed after — a postinstall, a peer — so the bump stands and the message names the codemods as the missing half, as before. Nothing at the target version means the install never got that far, and the originals go back. The message says which of the two happened, and for the first names the publish window as the likely cause: wait a minute, re-run.
+
+  Nothing here reaches `--no-install`, which writes the bump on purpose and says what is left.
+- **@voltro/cli** — `voltro logs` and the dev log buffer keep the error a record was written with. `log.error(message, fields, err)` under `voltro serve` printed `cause` on stdout; the dev capture dropped it, so a route that threw showed `… threw path=/v1/x` and nothing else on any level. The record now carries the error's message and first stack frames, and the text renderer prints them under the line. `voltro dev` also warns when `VOLTRO_SESSION_SECRET` is shorter than the floor `voltro serve` refuses, instead of accepting in silence what production will reject.
+
+---
+
+## [0.69.0] — 2026-09-10
+
+### ⚠ BREAKING
+
+- **@voltro/runtime** — A typed store error now reaches the caller as itself instead of being re-wrapped as `StoreOperationFailed`.
+
+  The Effect store's catch boundary passed two of the six `StoreError` variants through by name and wrapped everything else. The wrapper builds `cause` with `wireSafeCause`, which reads DRIVER fields — and a typed error carries none, so it landed on its own class name. A consumer's postgres answered `23503` with `ai_generation_requests_createdBy_fkey`; the store classified it into a `ConstraintViolation` carrying that name, and the client received `StoreOperationFailed { cause: "ConstraintViolation" }`. The constraint name was extracted correctly and then discarded by re-wrapping — the half that turns a half-hour search into a one-line diagnosis, and the half `cause` promises in its own doc comment.
+
+  `ConstraintViolation`, `TableValidationFailed` and `ServerOnlyColumnWrite` now arrive typed, with their constraint, issues and columns intact. The rule is over the SET — every `StoreError` variant — because naming variants individually is what produced this.
+
+  **Check your descriptors' `error:` unions.** A handler that declared only `StoreOperationFailed` to catch constraint failures will now see a `ConstraintViolation` it does not declare, which reaches the client as an untagged internal error instead. Declare the variant you actually want to catch, or `StoreError` for all of them.
+
+  **`voltro update` carries you across this** — codemod `0.69.0/06_typed-store-errors-are-not-rewrapped`. If you pin versions by hand and never run it, print the notes without changing anything: `voltro update --codemods-only --from <your current version> --dry-run` (this one ships in 0.69.0).
+- **@voltro/runtime, @voltro/voltro** — Issuing an API key now plants its `actors` row, and `ApiKeyStore` gained a required `ensureActor`.
+
+  `actors.kind` is declared by the framework as `'user' | 'serviceAccount' | 'apiKey' | 'system'` and `audit()` makes every `createdBy` a foreign key onto that table — so an API key is explicitly an audit subject. `issue()` wrote only `_voltro_api_keys`, so the row never existed: measured in a consumer's database, `actors with kind='apiKey'` came back 0, and the first audit-stamped insert by a key-authenticated caller died on the foreign key. `apiKeys:` and `audit()` are both on by default and were not combinable.
+
+  The row is planted BEFORE the key row, so a failure leaves no usable key rather than one that authenticates and then dies on its first audited write. Its id equals the key id, which is what `apiKeyStrategy` presents as `subject.id` — the `actors.id == subject.id` convention the core table documents. Revoking leaves the row: it is the author of everything that key wrote.
+
+  `@voltro/voltro` is named too because it re-exports the runtime surface, so the break reaches an app importing from the aggregate exactly as it reaches one importing from `@voltro/runtime`. (`memoryApiKeyStore`'s return type also widened to expose the planted rows for tests — an intersection, still assignable to `ApiKeyStore`, so that half breaks nobody.)
+
+  `ensureActor` is REQUIRED rather than optional. An optional hook would be the same defect with a nicer name — the mistake was omission, and an optional field is omissible. Both framework stores implement it; only an app with its own `ApiKeyStore` has anything to do.
+
+  **`voltro update` carries you across this** — codemod `0.69.0/05_api-key-store-plants-its-actor`. If you pin versions by hand and never run it, print the notes without changing anything: `voltro update --codemods-only --from <your current version> --dry-run` (this one ships in 0.69.0).
+- **@voltro/ai, @voltro/plugin-billing, @voltro/plugin-comments** — `ai`, `@ai-sdk/provider`, `@ai-sdk/gateway` and `stripe` are peer dependencies now — and `@voltro/plugin-comments` stops shipping its own `effect`.
+
+  `@voltro/ai` declared `ai: ^7.0.92` under `dependencies`. An app that configures a provider directly declares `ai` itself, and one that pinned it below our floor got a SECOND physical copy — with it a second `@ai-sdk/provider-utils`. Those types are branded with a symbol, so two structurally identical copies are not assignable to each other:
+
+  Argument of type '…provider-utils@5.0.39/…ToolSet | undefined' is not assignable to parameter of type '…provider-utils@5.0.33/…ToolSet | undefined'
+
+  Nothing fails at install and nothing fails at runtime. It surfaces as a typecheck error, only at the seams where an SDK type crosses the package boundary — which for `@voltro/ai` is thirteen types in its own api golden, `ToolSet` among them. `effect` has been a peer from the start for exactly this argument; it had never been applied to the SDKs whose types cross the same line.
+
+  **The criterion is narrower than "the type crosses the boundary", and the difference is what keeps this from becoming churn.** Counted over the repo, 21 packages have a third-party dependency whose types appear in their api golden. A second copy needs a second DECLARER, so the question is whether the APP is expected to declare the package too. It is for `effect` (every handler imports it), for `ai` / `@ai-sdk/*` (you declare them to configure a provider) and for `stripe` (`normalizeStripeEvent` takes an event built by the app's own SDK instance). It is not for `@effect/sql`, the dialect drivers, `ioredis`, `@opentelemetry/*` or `@radix-ui/*` — one range is declared in one place and one copy resolves.
+
+  `scripts/check-boundary-peers.mjs` (CI + `pnpm check:boundary-peers`) asserts that rule and PRINTS the judged-invisible set on every run, because a check that has quietly narrowed reads exactly like a clean one. It ships a `--selftest` that re-introduces `ai` as a dependency and requires the rule to fire.
+
+  `@voltro/plugin-comments` was the one package declaring `effect` under `dependencies` while every other peers it — the two-copies rule the repo already holds absolutely, with a single unapplied exception.
+
+  Most apps do nothing: the installer resolves a peer it can satisfy. An install that now warns about an unmet peer is the change working — it is saying that your pin and ours do not intersect, which is what silently produced the second copy before.
+
+  **`voltro update` carries you across this** — codemod `0.69.0/03_sdk-peers-are-declared-by-the-app`. If you pin versions by hand and never run it, print the notes without changing anything: `voltro update --codemods-only --from <your current version> --dry-run` (this one ships in 0.69.0).
+- **@voltro/plugin-storage** — The self-service upload routes refuse a caller with no identity, unless the app declares `storagePlugin({ anonymousUploads: true })`.
+
+  Those routes are `openAccess`, and each justified itself in source with "the ticket binds the calling subject + tenant, caps size, and the finalize path runs limits + scan". Every clause after the first depends on there BEING a calling subject, and `openAccess` does not establish one — an unauthenticated request resolves to an anonymous subject carrying `id: null`. So a visitor could mint a ticket with `sub: null, tenant: null`, and the object it finalized belonged to no owner and sat in no tenant: unreachable by every later owner check, tenant filter and quota, with a subject binding that compares `null` against `null` and therefore passes for every subsequent caller.
+
+  The framework already refuses exactly that comparison one level up — `defineMutation` rejects `requiresApproval` beside `openAccess` because "two anonymous callers both compare as `null`". Same shape, one layer down.
+
+  Whether a caller must be identified is not a wire question and the descriptor cannot answer it: only the app knows whether it wants a public intake. So the WIRE stays open — `openAccess` is unchanged and still means "anyone who can reach this may call it" — and the identity requirement lives in the plugin, where the app's own answer is in scope. `anonymousUploads` defaults to false; an app that turns it on is choosing ownerless objects deliberately, and should pair it with `limits` and a `scan`.
+
+  It is fixed over the SET rather than at the route that shows it best. Five handlers took the subject straight off the request — the ticket mint, the presigned mint, the resumable begin, the multipart begin and the direct upload — and `ctx.request.subject.id` reads as locally correct at every one of them; a sixth is one paste away. There is one resolver now, `ingestUrl` is routed through it too so write attribution has a single spelling in the file, and a test asserts over the source that no `sub:` or `ownerId:` takes its value from the request.
+
+  The finalize and multipart-completion comparisons said "the token is bound to the minting subject; a different caller can't finalize it", which is false for a ticket that was minted anonymously. That is one named function now, and it says what the binding actually is in that case: possession of the signed, short-lived token, and nothing else.
+
+  **`voltro update` carries you across this** — codemod `0.69.0/02_anonymous-uploads-must-be-declared`. If you pin versions by hand and never run it, print the notes without changing anything: `voltro update --codemods-only --from <your current version> --dry-run` (this one ships in 0.69.0).
+- **@voltro/database** — `releaseMigrationLock` is gone; `acquireMigrationLock` returns the release.
+
+  Because the MySQL migration lock was being released while the migration was still running.
+
+  Every dialect but sqlite implements it as a SESSION-scoped object — `GET_LOCK`, `pg_advisory_lock`, `sp_getapplock @LockOwner = 'Session'` — and all three die with the connection that took them. Taken through the pooled client, that stated an intent the plumbing did not keep. Measured on MySQL 8, with a second connection watching both the lock and the process list:
+
+  direkt nach acquire gehalten von conn 131 +500ms lock=FREI conn 131 lebt=false
+
+  The holder was gone inside half a second — closed, not returned to the pool — so the server dropped the lock and two `voltro db apply` runs against one server could both proceed past the thing that exists to stop exactly that. Postgres survived the same window, which is a driver's idle policy rather than a property: `@effect/sql-pg` keeps its connections and `@effect/sql-mysql2` does not. The lock now RESERVES its connection for as long as it is held, on every session-scoped dialect. sqlite is exempt and must stay exempt — its lock is a no-op and reserving its single connection would starve the work.
+
+  `acquireMigrationLock` returns the release instead of there being a free `releaseMigrationLock(sql, scope)`. A free release cannot know which connection took the lock, and on all three dialects a release on the wrong connection is a no-op that reports success — which is what it had been doing.
+
+  **Fixing that alone would have wedged every migration after a failed one**, and that is the more important half. `applyPlan` and the file-based runner released the lock from a `try/finally` inside `Effect.gen`, and a `finally` there does NOT run when a yielded effect FAILS: Effect short-circuits without resuming the generator. Measured — a deliberately failing operation reached neither the finalizer nor the release. The hole is as old as those functions and was invisible for as long as the release did nothing and the lock dissolved on its own. Two defects cancelling reads exactly like neither existing. Every acquisition is bracketed with `Effect.acquireUseRelease` now, which also covers defects and interruption, and a guard asserts it over the SET of call sites rather than the one that was found — three had the same shape, and the shape looks correct.
+
+  The fakes gained the `reserve` a `SqlClient` always owed, from one shared definition rather than six copies. It suspends: a real connection method BUILDS an effect rather than running the statement, and a fake that records on call instead of on run reports `RELEASE_LOCK` before the DDL it follows — a fake inventing an ordering violation, which reads exactly like a real one.
+
+  **`voltro update` carries you across this** — codemod `0.69.0/01_migration-lock-returns-its-release`. If you pin versions by hand and never run it, print the notes without changing anything: `voltro update --codemods-only --from <your current version> --dry-run` (this one ships in 0.69.0).
+- **@voltro/protocol** — `workflowToRpc` preserves the literal workflow name and the payload schema, so a workflow no longer widens the generated client.
+
+  It was typed `Rpc.Rpc<string, Schema.Schema.Any, …>`. A by-name lookup in an rpc group matches members by tag and every tag is assignable to `string`, so that one member joined the lookup for every OTHER procedure: a single workflow erased typed access to the entire group.
+
+  Filed BREAKING under this file's own "more precise is still BREAKING" rule — nothing was removed, the client simply gained the type information it should always have had, and that is strictly more ways to fail `tsc`. Apps without a workflow are unaffected.
+
+  Migration: run `voltro codegen` (or boot `voltro dev`), then typecheck. The new errors are real disagreements — a payload that never matched its schema and failed at runtime instead, a now-redundant cast, or a cast that refuses because the two shapes genuinely differ. Do not silence any of them with `as unknown as`; that restores exactly the blindness this removes.
+
+  **`voltro update` carries you across this** — codemod `0.69.0/04_workflow-rpc-types-are-precise`. If you pin versions by hand and never run it, print the notes without changing anything: `voltro update --codemods-only --from <your current version> --dry-run` (this one ships in 0.69.0).
+
+### Added
+
+- **@voltro/database, @voltro/runtime** — `upsertRowOutcome(store, table, row, options)` — the upsert, plus whether it INSERTED or UPDATED.
+
+  `upsert` returns the row and not what happened to it, so an app that has to report "created" reads first and then upserts. Measured on a real ingest: one extra query per row, purely to set a flag — and a window, because another writer between the read and the write makes the answer wrong.
+
+  It costs nothing to answer. The store wrapper mints the row's `id` before the statement, and on the conflict path every dialect hands back the EXISTING row's id — a fact `upsertBinding`'s header already relied on for the encrypted-column binding. Two ids that differ ARE the answer. No dialect implements anything: the outcome is decided from what the wrapper already had in hand.
+
+  **`'inserted'` is never a stand-in for "could not tell",** and that is the half worth reading. The free comparison needs an id the wrapper minted — a caller-supplied id is unchanged on both paths, and a database-assigned one does not exist yet — so in those two cases the destination is READ first and the answer stays exact. Only a call that asked for the outcome pays for it; plain `upsert` is byte-for-byte the call it was.
+
+  That required separating two facts `upsertDestinationId` had collapsed. It returns the OFFERED id both when nothing conflicts and when the conflicting row's id happens to BE the offered one — identical answers for binding a ciphertext, opposite answers for "what did this do". `upsertConflictId` reports existence; the destination is derived from it.
+
+  The helper is `async` so its refusal (a hand-written `DataStore` without the method) arrives as a rejection rather than a synchronous throw: a function whose type says `Promise` and which sometimes throws before returning one splits every caller's error handling in two.
+
+  **No `upsertMany`.** The batch form was asked for alongside this, and the reported batches are ~30 rows — at that size the round trips are not the cost, the missing `created` flag was, and it is now free. A conflict-write batch still belongs in ONE `store.transactional` with a capped input, which is what the `bulk-write-in-loop` advice says.
+- **@voltro/cli** — `VOLTRO_DASHBOARD=on` — the counterpart `off` never had.
+
+  The launcher skips the dashboard when stdout is not a TTY, which is a good stand-in for "nobody is watching": CI, a smoke run, a piped script. It stops being one the moment a task runner is in the way. `turbo run dev` — how a multi-app project is normally brought up — captures each task's output to prefix it (24 731 prefixed lines in one gate log), so `isTTY` is false for a developer sitting right in front of it, and the dashboard could not be turned on at all.
+
+  Measured on the same non-TTY boot, before and after:
+
+  without dashboard not launched: stdout is not a TTY (CI/smoke) with auto-launching dashboard at http://localhost:5179
+
+  It overrides only the guess. The recursion guard, the launch lock and the port-in-use check are measurements rather than proxies and still apply — so two apps started together still share one dashboard, and the second reports `already-running` instead of racing for the port.
+
+  The skip reason names the variable, because a guess you cannot overrule is a wall.
+- **@voltro/devtools-ui** — Show automatic data synchronization as a connection status, highlight changed cells and new visible rows, and briefly retain confirmed deleted rows in red. Query navigation stays quiet, active editors retain focus, and reduced motion uses a static tint. Local and Cloud providers carry CDC deletion identities.
+- **@voltro/ui-shadcn, @voltro/devtools-ui** — Cloud and local Devtools now share `SignalWorkspace`, `SignalWorkspaceHeader` and `AppInspectorHeader`: one masthead, background, heading rhythm and app identity. Local navigation and live charts keep their full functionality while using the shared workspace styling and semantic theme colors.
+- **@voltro/database** — `insertManyRows(store, table, rows)` — `insertRow`'s batch, typed on the element.
+
+  It forwards to `store.insertMany` unchanged, so the chunking, the dialect behaviour and the conflict semantics stay exactly what the string-keyed call already did. What it adds is the type link the string-keyed form cannot have: every element is checked against the table's insert row, so an element missing a required column, misspelling one, or passing a `number` where the column is a timestamp is a compile error at the call site rather than a dialect error somewhere inside the batch.
+
+  The batch needed its own helper rather than a loop over `insertRow` because of where the mismatches actually come from: a batch is usually MAPPED — from a parsed import, an API page — and the loop body's inferred element type is only as good as whatever produced the array. That is the shape a mapped `Date` versus `number` survives review in.
+
+  The set-based conflict forms (`insertManyIgnore`, `upsertMany`) remain unbuilt, for the reasons already recorded against them; this is a typing gap, not a conflict-handling one.
+
+### Fixed
+
+- **@voltro/protocol** — An auth strategy that declares a `claimsBearerPrefix` is now asked BEFORE strategies that declare none, for a token carrying that prefix.
+
+  Turning on `apiKeys:` made every API key unusable as soon as a JWT strategy sat in the chain. Two reasonable pieces produced a third thing nobody chose: `apiKeys:` appends the framework key strategy LAST, and `jwtBearerStrategy` — so all six catalog strategies (supabase, auth0, clerk, kinde, oidc, workos) — claims EVERY `Authorization: Bearer`. A token it cannot verify comes back `failed`, not `skip`, and a `failed` ends the chain by design, because a credential another IdP rejected could be an attack masquerading as ours. So a valid key was refused by the JWT verifier before the key strategy was ever asked. Nothing logged an error; the key simply never worked.
+
+  The boot check could not see it: it warns when TWO strategies declare the same prefix, and the JWT strategy declares none while claiming everything.
+
+  `failed` still ends the chain — that property is untouched. What changed is who is asked first: a declared prefix is a strategy saying "this token shape is mine", which is more specific than claiming everything by declaring nothing. A token matching no declared prefix leaves the chain in exactly the order the app wrote it, so a real JWT is still claimed, and still rejected, by its own verifier.
+- **@voltro/cli** — `voltro build` fails when the SSR bundle it just wrote cannot be imported — and `build: { ssrExternal: [...] }` is the exit that `ssr.noExternal: true` did not have.
+
+  The web SSR build bundles everything the graph reaches so a production image needs nothing from `node_modules`. A CommonJS dependency pulled into that ES module carries its `__dirname` / `__filename` along, and neither exists there. Measured against a real app: the build is GREEN, the bundle is written, and the artefact dies on its first import with `ReferenceError: __dirname is not defined in ES module scope`. The same dependency externalised: exit 0.
+
+  Two things were missing, and only fixing both helps. `noExternal: true` was hard-wired with no config evaluation beside it, so an app had no way to keep one package a runtime import — there was no app-side workaround at all. And the build reported success, so the failure arrived at deploy time as a boot crash three layers from its cause.
+
+  The externalisation is deliberately NOT automatic. Externalising on the framework's own initiative puts a package back among the image's runtime requirements; an image built on the promise that it needs nothing from `node_modules` would then fail to boot for a second reason, with nothing said about either.
+
+  **The detector reads the artefact, and it was wrong once before it was right.** Run over the 357 built ESM files in this repo it flagged exactly one — a false positive, in `@voltro/cli`'s own bundle, on the line
+
+  "import { join as __join, dirname as __dirname } from 'node:path'"
+
+  which is a string the build WRITES into a generated file. That is the same trap this repo already recorded once, for a different rule in the same package: a regex cannot tell a specifier from a specifier-shaped string. String literals are blanked before the scan and an import alias counts as a definition.
+
+  The correction had a second edge. A parameter arm added for the CommonJS wrapper (`function (…, __dirname)`) read `join(__dirname, 'assets')` as a declaration — a call argument and a parameter are the same characters — and silenced the exact reference the check exists for. It is gone; no shim of that shape appears in any of the 357 files, so it bought nothing and cost the rule. Both directions are asserted, and the false positive is kept as a fixture.
+- **@voltro/devtools-ui, @voltro/ui-shadcn** — Keep the dashboard masthead, tabs and inspector context compact so working tables start higher in the viewport. Group the app return link, identity, address and status in one responsive header shared by local and Cloud inspectors.
+- **@voltro/devtools-ui, @voltro/ui-shadcn** — Use the shared styled Checkbox for dashboard filters, workflow confirmations, inspect access and schema-driven checkbox forms, matching Cloud configuration controls while preserving native label, keyboard and form behavior. Checked and indeterminate fills now retain the primary color in dark mode.
+- **@voltro/cli** — The auto-launched dashboard died 85 ms after it was announced, silently.
+
+  `bin/voltro.mjs` is the only entry that registers the tsx ESM loader, and the CLI cannot run without it — it imports the app's own `app.config.ts` at runtime. The launcher derived the child's bin from `process.argv[1]` and handled ONE spelling: `<cli>/src/bin.ts` → `<cli>/bin/voltro.mjs`. Everything else fell through to argv[1] itself.
+
+  But `bin/voltro.mjs` re-execs, so inside the CLI argv[1] is the entry BEHIND it. Measured on a normal boot:
+
+  argv[1] = …/packages/cli/dist/bin.js bin = …/packages/cli/dist/bin.js
+
+  That is what every installed user runs, and every maintainer tree that has been built once. The child was handed the bundled entry with no loader and died on its first TypeScript import:
+
+  ERR_MODULE_NOT_FOUND: Cannot find module '…/packages/logger/src/logger' imported from '…/packages/logger/src/index.ts'
+
+  Nothing said so. The child is spawned with `stdio: 'ignore'` and nothing watched its exit, so the last word was the launcher's own `dashboard launched at http://localhost:5179` — a URL that answered nothing. The `/src/bin.ts` branch is why this was invisible from inside the framework repo: running unbuilt from source is the one case that worked.
+
+  The bin is resolved by walking up from the launcher's own module until `bin/voltro.mjs` is found, so `src/` and `dist/` reach the same answer — the point being that it must not depend on which of the two is running. Verified end to end from a `voltro dev` boot: `dashboard launched`, then HTTP 200 with the dashboard's own title.
+- **@voltro/cli** — The recommended dashboard install line contradicted the stability contract.
+
+  `pnpm add -D @voltro/dashboard` writes a caret range. The contract at the top of `CHANGELOG.md` tells users to pin exact versions and never `^`, and a project that follows it ends up with one dependency spelled differently from all the others — because we told it to. The message and both docs pages now say `--save-exact`.
+- **@voltro/cli** — An interrupted dashboard build made the launcher choose the one mode that cannot run in it — and then said nothing when the child died.
+
+  The mode was chosen by `existsSync(.framework/dist/index.html)`. A build writes that file EARLY and writes `dist/server/ssrEntry.js` LATE, so a build that dies in between — the prerender step is the one that does — leaves a tree that looks built. Measured on exactly such a tree:
+
+  serving the Voltro dashboard on :5199 … mode: start fatal: production `voltro start` requires a precompiled SSR bundle at …/.framework/dist/server/ssrEntry.js but it is missing
+
+  Keyed on the bundle instead, the same tree falls back to `dev`: vite ready in 169 ms, the port answers.
+
+  There were TWO deciders, spelled differently — the auto-launcher and the standalone `voltro dashboard` — and both were wrong the same way. One `dashboardIsPrebuilt` now, asserted over the set, because a third is one paste away.
+
+  **And the death was silent.** The launcher spawns with `stdio: 'ignore'`, which throws the child's own diagnosis away, and had no `exit` or `error` handler at all. So the last word on a dead dashboard was the parent's own `auto-launching dashboard at http://localhost:…` — a promise that was already false by the time anyone read it. A non-zero exit is reported now, and a signal stays quiet because that is how Ctrl-C reaches the whole process group.
+- **@voltro/devtools-ui** — Rework the shared data explorer around compact resizable columns, debounced search, explicit filter application, accessible record editing and searchable references. Preserve database defaults when creating rows, distinguish empty text from null, retain invalid drafts and write failures, confirm destructive actions and unsaved changes, and expose an optional host refresh callback for current snapshots.
+- **@voltro/devtools-ui** — Resize the data explorer's table list independently, read complete table names in delayed themed tooltips, and resize columns with visible pointer/keyboard handles. Double-click a divider to restore its default width.
+- **@voltro/cli** — Resolve local dashboard stream credentials for the inspected app in both dev and production, matching snapshot reads, and flush the development stream handshake immediately so live data updates can connect without repeated authorization failures.
+- **@voltro/devtools-ui** — Make inspector tasks directly discoverable through a grouped sidebar, replace flat route cards with a shared expandable route explorer, and keep Data explorer visible for frontend apps through an API data-source picker. Bound the mobile table list and support keyboard activation of editable cells and foreign-key navigation.
+- **@voltro/client** — A `title` annotation on a schema field now becomes the field's label — where the title is one somebody wrote.
+
+  `schemaToFields` / `schemaToColumns` derived every label from the humanised property name and ignored `title` entirely, so an app that had already annotated its schema (for OpenAPI output, say) had to say the same thing twice through `formField({ label })`, with the two free to drift.
+
+  `title` could not simply be read, and the reason is worth stating because the obvious rule is wrong. effect writes its OWN titles into that field, and it writes them INLINE on the property node — not only into a `$defs` entry behind a `$ref`. Measured:
+
+  Schema.NonEmptyString.annotations({ description: 'Der Kundenname' }) -> { title: 'nonEmptyString', description: 'Der Kundenname', … } Schema.String.pipe(Schema.minLength(2)) -> { title: 'minLength(2)', … }
+
+  So "use the title unless it arrived through a `$ref`" puts `minLength(2)` on a form field. What separates the two is the SHAPE of the name effect generates: a lowerCamel type name, optionally carrying the filter's arguments in parens. A title matching that is declined; everything else is the author's.
+
+  Two properties keep that honest. The failure direction is safe — a declined title falls back to the humanised name, which is what every field got before, so the rule can never do worse than the old behaviour. And it is not left as a claim about a dependency: the test regenerates the corpus through a live `JSONSchema.make` and fails if any generated title stops matching, so a change in effect goes red in the suite instead of wrong on somebody's form.
+
+  `formField({ label })` still wins over both — it is the one channel effect cannot write into.
+- **@voltro/cli** — `voltro update` no longer rewrites a package.json that does not consume the framework.
+
+  Reported after an upgrade changed `services/api/package.json` — an independent Strapi 4 backend with NO voltro dependency — from React 18 to 19. Nothing in the command's output named the file, and the app avoided it on the next round by setting versions by hand and running its own installer, which is a sidestep and not a fix.
+
+  The peer alignment already had three conditions, and all three are about the DEPENDENCY: only a peer the manifest already declares, only when its floor is below ours, only ranges both sides can parse. Every one of them was satisfied here — React was declared, 18 is below 19, both ranges parse. None of them asked whether the package was ours to edit.
+
+  It is not a new judgement, it is an unapplied one. `planWorkspaceBump` — the `@voltro/*` half of the same command — has always dropped manifests that declare no `@voltro/*` dep. The peer alignment was added later and did not inherit it. It does now: a manifest is in scope when it declares `voltro` or any `@voltro/*` in its dependencies, devDependencies or peerDependencies, and one package being out of scope does not take its siblings with it.
+
+  `consumesVoltro` is deliberately the whole test. A peer requirement comes FROM a `@voltro/*` package; a workspace member that declares none is not bound by it, however many packages it happens to share a name with.
+- **@voltro/cli** — `input/uncapped-array` is silent on `internal: true`, and `raw-fetch` is silent on a `fetch` an SDK asked for as an option.
+
+  Both rules were reporting a set their own sentence does not describe, and both were found by an app that read every remaining finding instead of filing them.
+
+  **`input/uncapped-array` says "the caller chooses how many".** `internal: true` takes a procedure off the wire, so there is no such caller — only the app's own code calling its own procedure. Measured on one codebase: after every wire procedure was bounded, 212 findings remained and ALL 212 were internal. So the rule spent its entire remaining output on the case its premise excludes, which is how a rule stops being read. `imperative-scope` has skipped `internal: true` for the same reason; this applies the existing decision rather than making a new one. A procedure on the wire is reported exactly as before, which is the half that keeps the exemption from being a hole.
+
+  **`raw-fetch` recommends `yield* HttpClient`.** Several provider factories take a `fetch`-shaped function as an option (`createGoogleGenerativeAI({ fetch })`). Inside it the URL is the SDK's, never a caller's, so the SSRF half has nothing to bite on — and the remedy is not available either: the seam requires a plain callback, so `yield* HttpClient` names an API that cannot be used at that call site. A rule whose only remedy does not apply teaches the reader to skim the line, which is the one place a genuinely caller-supplied URL would have been named.
+
+  The seam is SUBTRACTED, not exempted: only calls inside the function that is the value of a `fetch:` property are discounted, so a file that supplies such a seam AND calls `fetch` on its own account is still reported for the second one. Without that, adding one option object would switch the rule off for a file.
+
+### Internal (no consumer-facing effect)
+
+- **@voltro/database** — The migration lock is released by its bracket and nowhere else.
+
+  Correcting unreleased work in this same release, so no shipped behaviour changes: `applyPlan` gained an `Effect.acquireUseRelease` bracket and KEPT the `try { … } finally { yield* held.release }` it replaced. The overlap was documented as free — "releasing twice is harmless: the second `RELEASE_LOCK` finds nothing held on that connection".
+
+  That holds for `RELEASE_LOCK` and for `pg_advisory_unlock`. It is false for the third dialect: `sp_releaseapplock` RAISES on a lock the session does not hold, so every mssql apply died on the second release with `Cannot release the application lock … because it is not currently held`. A claim about three dialects, verified on two.
+
+  Removing it is also the better release POINT — the `finally` ran before the convergence proof, handing the lock back while the work it protects was still running. The bracket holds it to the end and covers failure, defect and interruption, which a `finally` inside `Effect.gen` does not.
+
+  `migrationLockIsBracketed.test.ts` asserted that an acquisition IS bracketed; it now also asserts there is exactly ONE release. Those are different claims and only the first was being made, which is how this rode through.
+
+---
+
 ## [0.68.0] — 2026-09-09
 
 ### ⚠ BREAKING

package/THIRD-PARTY-NOTICES.md

@@ -5,7 +5,7 @@ property of its respective copyright holders and is used under the terms of
 its license. This file is provided for attribution; it grants no rights in
 @voltro/ui-shadcn itself, which is proprietary (see LICENSE).
 
-Generated from the resolved runtime dependency closure (107 packages).
+Generated from the resolved runtime dependency closure (103 packages).
 
 ---
 
@@ -1160,34 +1160,6 @@ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
 ```
 
-## @standard-schema/spec@1.1.0
-
-License: MIT
-
-```
-MIT License
-
-Copyright (c) 2024 Colin McDonnell
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
-```
-
 ## @tanstack/devtools-event-client@0.4.4
 
 License: MIT
@@ -1876,62 +1848,6 @@ TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 ```
 
-## effect@3.22.1
-
-License: MIT
-
-```
-MIT License
-
-Copyright (c) 2023 Effectful Technologies Inc
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
-```
-
-## fast-check@3.23.2
-
-License: MIT
-
-```
-MIT License
-
-Copyright (c) 2017 Nicolas DUBIEN
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
-```
-
 ## get-nonce@1.0.1
 
 License: MIT
@@ -2362,34 +2278,6 @@ TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 ```
 
-## pure-rand@6.1.0
-
-License: MIT
-
-```
-MIT License
-
-Copyright (c) 2018 Nicolas DUBIEN
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
-```
-
 ## react-remove-scroll@2.7.2
 
 License: MIT

package/dist/index.d.ts

@@ -113,7 +113,7 @@ export declare interface ButtonProps extends ButtonHTMLAttributes<HTMLButtonElem
 }
 
 export declare const buttonVariants: (props?: ({
-    variant?: "default" | "link" | "destructive" | "outline" | "secondary" | "ghost" | null | undefined;
+    variant?: "link" | "default" | "destructive" | "outline" | "secondary" | "ghost" | null | undefined;
     size?: "default" | "sm" | "lg" | "icon" | null | undefined;
 } & ClassProp) | undefined) => string;
 
@@ -980,6 +980,39 @@ export declare interface SignalSearchProps {
     readonly className?: string;
 }
 
+/** Shared Cloud/local operating shell. Import `@voltro/ui-shadcn/signal.css`. */
+export declare function SignalWorkspace({ brand, header, children, className, field }: SignalWorkspaceProps): ReactNode;
+
+/** One heading, description and action rhythm for workspace pages in either host. */
+export declare function SignalWorkspaceHeader({ title, description, badge, action }: SignalWorkspaceHeaderProps): ReactNode;
+
+export declare interface SignalWorkspaceHeaderProps {
+    readonly title: ReactNode;
+    readonly description?: ReactNode;
+    readonly badge?: ReactNode;
+    readonly action?: ReactNode;
+}
+
+/** Open workspace row; the host supplies its typed link or selection button. */
+export declare function SignalWorkspaceItem({ title, description, detail, actionLabel, renderLink }: SignalWorkspaceItemProps): ReactNode;
+
+export declare interface SignalWorkspaceItemProps {
+    readonly title: string;
+    readonly description: ReactNode;
+    readonly detail?: ReactNode;
+    readonly actionLabel: string;
+    readonly renderLink: (className: string, children: ReactNode) => ReactNode;
+}
+
+export declare interface SignalWorkspaceProps {
+    readonly brand: ReactNode;
+    readonly header: ReactNode;
+    readonly children: ReactNode;
+    readonly className?: string;
+    /** Signed-out pages can supply their own full-height, animated field. */
+    readonly field?: boolean;
+}
+
 export declare const SiteFooter: ({ brand, tagline, social, columns, bottomLeft, bottomRight, copyrightHolder, socialLabel, LinkComponent, className, }: SiteFooterProps) => ReactNode;
 
 export declare interface SiteFooterColumn {