@voltro/ui-shadcn 0.74.0 → 0.75.0

package/CHANGELOG.md

@@ -39,6 +39,325 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [0.75.0] — 2026-09-19
+
+### ⚠ BREAKING
+
+- **A storage object shared through an `operationId` is held by per-caller claims** — `@voltro/plugin-storage`
+
+  Two callers completing the same `operationId` share one ref, and a caller that failed later and removed what it put deleted the file the other caller had already kept — while skipping cleanup left a file behind for every job that finally failed. `put({ operationId, claim })` now registers the caller's own claim when it receives the ref, `delete(id, { claim })` releases only that claim, and the object goes with the last one. A delete that names no claim is still the whole object. A claim without an operation is refused (`'claim-without-operation'`), and a claim released on a ref that holds none is a 409 that deletes nothing. Claims live in `_voltro_storage_object_claims`, migrated like the other framework tables.
+
+  `put` also reports what it did: it returns `StoredRef`, a `StorageRef` plus an `outcome` of `'created'`, `'resumed'` or `'joined'` — a fact about the call, never stored. Migration: code that reads the result compiles unchanged; a hand-written `StorageServiceShape` implementation answers `{ ...ref, outcome: 'created' }`, and a direct reader of `makeStorageObjectMetadata(...).beginDelete` narrows its result with `'operation' in result`.
+
+  **`voltro update` carries you across this** — codemod `0.75.0/02_storage-put-reports-its-outcome`. 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.75.0).
+- **A workflow declares who may drive a run — `controls:`** — `@voltro/protocol`, `@voltro/cli`
+
+  A `workflow()` said who may START it (`guards:` / `openAccess:` / `internal: true`) and nothing about who may DRIVE one of its runs. The built-ins behind `useWorkflow(...)` — `cancel`, `signal`, `update`, `resume` — admitted any caller in the run's tenant. So an app that guarded its approval surface
+
+  ```ts
+  defineAction({ name: 'orders.approve', guards: [{ scope: 'orders:approve' }], … })
+  ```
+
+  had a second way in that it never wrote: a colleague the mutation refused could send the same `approval` signal through `__voltro.workflow.signal` and release the order. Measured through a real server, with both callers on real sockets.
+
+  Driving a run is now its own declaration, in the same vocabulary:
+
+  ```ts
+  export default workflow({
+    name: 'orders.fulfil',
+    internal: true,
+    controls: { guards: [{ scope: 'orders:approve' }] },
+    payload: { orderId: Schema.String },
+    success: Schema.String,
+  })
+  ```
+
+  `controls: { openAccess: '<why>' }` says anyone who may see the run may drive it. A resource-scoped guard reads its id from the run's start payload, so one `resource:` function serves the start and the controls.
+
+  **A workflow that declares no `controls:` cannot be driven over the wire** — a system subject and a caller holding `admin:full` aside — and the refusal names the missing declaration. Starting and driving are different authorities: the customer who starts an order must not signal its own approval, so inheriting the start decision would have been wrong in both directions.
+
+  Unchanged: reading. The run feeds stay scoped by tenant, so a caller may watch a run it may not drive. Server-side control (`ctx.workflows.signal`, a schedule, a parent workflow) is unaffected. Cancelling a start that has not run yet (`cancelQueued`) is still authorised by the receipt id the start returned plus the tenant — there is no run and no payload for a resource guard to read.
+
+  **`voltro update` carries you across this** — codemod `0.75.0/03_workflow-controls-decision`. 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.75.0).
+- **A usage receipt recorded twice with different values is a typed conflict** — `@voltro/ai`, `@voltro/voltro`
+
+  `recordAiUsage` answered `replayed` for any second recording of a receipt, even with different values, and returned the values it was handed — so the caller saw a charge that was never booked and no sign of the disagreement. It now fails with `AiUsageReceiptConflict` (the `recorded` and the `attempted` values), and a genuine replay returns the booked row's breakdown. A failed ledger write is `AiUsageLedgerError` in the error channel instead of a defect.
+
+  For a call that is already paid for, `recordAiUsageBestEffort` never fails and logs both errors with what is needed to reconcile them. The framework's own recording paths use it; they used to discard a failed write without a trace.
+
+  **`voltro update` carries you across this** — codemod `0.75.0/01_ai-usage-receipt-conflict`. 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.75.0).
+- **Preserve workflow bulk cancellation receipts through the dashboard** — `@voltro/cli`, `@voltro/devtools-ui`
+
+  Bulk cancellation returns resident control receipts instead of reporting accepted requests as failures. Both dashboard bulk surfaces persist per-run identities before dispatch and restore receipt observation after reload or a lost response. Cancellation reasons are retained; producer sweeps still require confirmed termination.
+
+  Custom bulk providers must forward request `controls` and response `targets`/`controls`. Standalone `BulkRunActionsPanel` and `SelectionBar` integrations supply `prepareControls` and `observeControl`; `WorkflowsPage` connects its existing journal. Count only confirmed cancellation as success and use the control reader for pending or uncertain outcomes.
+
+  **`voltro update` carries you across this** — codemod `0.75.0/01_workflow-bulk-control-receipts`. 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.75.0).
+
+### Added
+
+- **A paid media step keeps its usage and its charge, even when it fails after** — `@voltro/plugin-ai-flows`
+
+  A media step's result carries `usage` — the quantity it consumed, in the provider's unit (tokens, characters or seconds), with `status: 'reported'` or `'unreported'` — and the run step records it. A step priced `unpriced` used to read the same whether the provider had reported a tally or nothing at all.
+
+  `FlowCapabilityMissing` can carry a `receipt` (cost, cost source, request id, usage) for a failure that happened AFTER a billed generation, typically when the artifact could not be stored. The engine writes it onto the failed step and adds the charge to the run, and `costCompleteness` counts a failed step that carries one — a run that paid for a generation and then failed to store it reads `incomplete`, not `unknown`. The built-in media adapter fills both. A failed sequential step also updates the run's `costCompleteness` now; it used to keep the verdict of the last step that succeeded.
+- **Inspect individual outcomes of stored schedule backfills** — `@voltro/devtools-ui`
+
+  Schedule backfills expose paginated recorded outcomes with status, scheduled time and complete run identity, including read-only access and results older than the recent firing history.
+
+  Each outcome opens its original firing details on demand, including error, timing and replica information. Both dashboard hosts query the exact upstream run independently of recent-history limits. Shared hosts provide useScheduleRun for the detail read.
+- **Generated media is stored with the owner, visibility and tags you give it** — `@voltro/ai`, `@voltro/protocol`, `@voltro/plugin-storage`, `@voltro/voltro`
+
+  `mediaStep({ persist: { ownerId, visibility, tags } })` hands all three through the queue and the dispatcher to the storage plugin's `mediaPersist`, which stores the artifact with them. Every generated artifact used to land owner-less, private and untagged, although the store takes all three — so deletion, restore and listing by owner or tag did not reach generated media.
+
+  The capability's `put` and `ingestUrl` gain three OPTIONAL fields. A `mediaPersist` implementation that ignores them stays assignable, and a caller that does not pass them compiles unchanged — which is why the surface change is marked compatible.
+- **Read individual schedule firings by identity** — `@voltro/cli`
+
+  The schedule firing Inspect endpoint accepts a runId filter combined with the schedule name, so older run details remain queryable outside the recent-history page. Missing or mismatched identities return an empty result.
+- **Stream storage uploads through the local dashboard** — `@voltro/cli`
+
+  Local dashboard servers can prepare session-bound, one-use storage upload handoffs and stream exact file bytes to the issuing app. Read/write credentials authorize preparation; binary transfers carry only the signed storage capability, enforce the admitted size, reject cross-site requests and redirects, and support named storage instances.
+- **`registerMediaTaskProvider` — media jobs through a provider with a task handle** — `@voltro/ai`
+
+  A hosted media queue answers a submission with a task handle and is asked for the result later; `mediaStep` had no way to reach one. `registerMediaTaskProvider(name, { submit, poll })` registers the contract, and `mediaStep({ provider: { name } })` routes through it. The dispatcher writes the handle onto the queue row before anything else, polls once per claim without holding the lease across the job, persists the artifacts under the same `<row>#<attempt>#<index>` identity and records usage in the provider's unit.
+
+  A job whose worker was lost after the handle was written is polled by the next claim — never submitted again and never reported `unknown`. The remaining window is a worker lost between the provider accepting the job and the handle reaching the row: such a row still resumes its run with `outcome: 'unknown'`. `submit` receives an idempotency key derived from the row and the attempt; a registration that declares `idempotentSubmit: true` closes that window too. A `failed` status is terminal unless the provider marks it `retryable`; a task still pending after `taskTimeoutMs` is failed with the reason.
+
+  `_voltro_ai_inferences` gains the nullable `taskHandle` and `taskSubmittedAt` columns; the declarative differ adds them on the next boot or `db apply`.
+- **`tx.savepoint()` works on every dialect and on the store a handler holds** — `@voltro/database`, `@voltro/runtime`, `@voltro/sql-postgres`, `@voltro/sql-mysql`, `@voltro/sql-mssql`, `@voltro/sql-sqlite`
+
+  Inside a transaction, `tx.savepoint(fn)` runs `fn` so that a failure undoes all of `fn` — and only `fn` — while the transaction goes on. It existed on Postgres alone and was not passed through to `ctx.store`, so in a handler it was `undefined`; the in-memory store every app test runs on had none either. It is now on Postgres, MySQL, MariaDB, SQL Server, SQLite and Turso, on the in-memory store, and on the store a handler holds.
+
+  This is the way to skip a failing row and keep the rest: catching the failure without a savepoint ends the transaction on Postgres, and `transactional()` then fails with `TransactionAbortedError` rather than committing nothing.
+
+  ```ts
+  await ctx.store.transactional(async (tx) => {
+    for (const row of rows) {
+      await tx.savepoint!(() => tx.insert('imports', row)).catch(() => skipped.push(row.id))
+    }
+  })
+  ```
+- **Upload files from the shared storage inspector** — `@voltro/devtools-ui`
+
+  The shared storage inspector supports file uploads through a host-provided mutation. It requires explicit tenant and owner attribution, defaults to private visibility, prevents duplicate submissions, preserves inputs on failure, and refreshes inventory after success. Read-only hosts do not show upload controls.
+
+### Fixed
+
+- **A payload the client refuses to encode is printed with the field it names** — `@voltro/client`
+
+  A payload with a field the procedure does not declare fails its schema before it is sent, so the server never sees the request and no server log has it. The error the caller receives names the field, but an app that logs the object rather than its message saw only an opaque `ParseError`. The client now prints the full message to the console once when a value fails its schema on the client — on every path that reduces a failed call, reads and writes alike. A declared failure from a handler is not printed; that one is the app's to handle.
+- **VOLTRO_DESTRUCTIVE_OK no longer takes credit for drops it never covered** — `@voltro/cli`
+
+  A `db apply` whose lossy operations were all `dropped()` columns printed, with `VOLTRO_DESTRUCTIVE_OK` set,
+
+  ```text
+  db apply --plan: proceeding with acknowledged lossy operation(s) (VOLTRO_DESTRUCTIVE_OK)
+  ```
+
+  and then refused for want of `--yes`. Neither was true of those operations. A `dropped()` marker is the acknowledgement of its drop — the planner never blocks it — so the variable had nothing to relax, and the same plan applies with `--yes` alone. Read together, the two lines taught the opposite: that `--yes` acknowledges data loss, and that a variable kept "for this release" stops mattering once a pipeline passes `--yes`.
+
+  - The acknowledgement line appears only when the variable actually unblocked something. When it is set and the plan has nothing blocked, the apply says that instead — `VOLTRO_DESTRUCTIVE_OK is set but this plan has no blocked operation — it changed nothing in this run` — so a variable left in a deploy's configuration is noticed before it covers the next release's undeclared drop. - The `--yes` question on MySQL, MariaDB, SQLite and Turso now says what `--yes` does not answer: the lossy operations were authorised where they are declared, and a drop the schema does not declare stays blocked with or without it. - A refused first run ended with `nothing of this run remains … there was nothing to undo` while the deploy journal that run had created stood in the database. The journal is the runner's own and stays, hidden from every plan; the line now says what it is about and names the table it keeps.
+- **A table whose key is spelled `(id)` can be written by id again** — `@voltro/runtime`
+
+  `update(table, '<id>', …)` and `delete(table, '<id>')` were refused on any table with an explicit `.primaryKey([...])`, including `.primaryKey(['id'])` — whose key IS the `id` column. The refusal's own message read "has no `id` column — its primary key is (id)". It exists for keys a string cannot name, `(userId, orgId)` or a single column shared with a parent, and those are still refused.
+
+  Framework tables declare their key this way, so the store a handler holds could not write them by id: `storage.put({ operationId })` failed at its reservation, and clearing a tenant selection threw, turning a revoked membership into `Unauthenticated` instead of a return to the home tenant. The raw store wrote all of them fine, which is why suites built on it stayed green.
+- **`voltro doctor` no longer calls a retry loop an N+1** — `@voltro/cli`
+
+  `n-plus-one` already ignored reads inside `while` and `do` loops — they advance a cursor or retry, which proves no read per row. `for (;;)` is `while (true)` spelled differently and was reported: a handler that rolls a random code until one is free, one read per attempt over no collection, came back as an N+1. A `for` with no condition is now treated like the `while` it is; a counted `for` over input is still reported.
+- **A failed AI call says why — the driver code joins the message** — `@voltro/ai`
+
+  A provider failure became an `AiError` carrying only the top-level message, so a dead upstream read `fetch failed` with nothing under it. The error now keeps the raw failure as `cause`, and the codes of its chain (`ECONNREFUSED`, `CERT_HAS_EXPIRED`, …) join the message — including through the SDK's retry wrapper, where the chain continues under `lastError`. Structured calls that used to report only `structured provider call failed` now carry the provider's message as well.
+
+  `cause` is not enumerable and not a schema field, so it stays on the server: the request body, headers and socket address it can hold never reach an encoded error.
+- **Prepare a new backfill without submitting it** — `@voltro/devtools-ui`
+
+  Preparing a new schedule backfill now only clears the previous request. The click cannot also submit the newly rendered start control; operators explicitly start and, when required, confirm the new range.
+- **Preserve timestamp precision in the data editor** — `@voltro/devtools-ui`
+
+  Cell and record timestamp editors preserve milliseconds. Saving an unchanged inline draft issues no write, including during repeated daylight-saving hours. Date validation rejects impossible calendar days instead of silently normalizing them into another month.
+- **Keep record edits isolated from incoming live snapshots** — `@voltro/devtools-ui`
+
+  Record editors retain their opening snapshot when live rows change. Untouched fields no longer become stale patches that overwrite external changes. Open drafts remain available when their row leaves the current page.
+- **A first production deploy no longer refuses over a table the apply created** — `@voltro/database`, `@voltro/cli`
+
+  `voltro db apply --plan` refused on its FIRST run against any database that predates the deploy journal, with a drift nobody caused:
+
+  ```text
+  db apply --plan: refusing — the live schema has drifted since this plan was generated.
+    planFrom=bfff4758e04fee2f  live=d3d95a02dc514886
+  ```
+
+  Nothing had touched the database between the two commands. The drift came from the refusing run itself: `db apply` creates its own deploy journal (`_voltro_deploys`) before it holds the live fingerprint against the saved plan's, so it introspected a schema that now contained a table its own plan had listed as work still to do.
+
+  **It hit the only route production allows.** A bare `voltro db apply` is refused there, so `db plan --json` → `db apply --plan` is the prescribed path — and it could not complete on its first run. For a pre-upgrade job without retries that is a stopped rollout. The second run succeeds (the table exists by then), which is why this read like a fluke on a concurrency path rather than like something every first deploy meets.
+
+  **The fix is two halves, and either one alone is wrong.** The journal is no longer DECLARED in the framework table set, and it is hidden from the introspection snapshot — exactly how `_voltro_migration_ops`, the applier's other bookkeeping table created in the same run for the same reason, has always been treated.
+
+  - Hiding it while still declaring it is **worse than the original defect**: the planner then proposes `create-table _voltro_deploys` on every run, and `applyPlan`'s convergence proof refuses to record a fingerprint — every apply dies, not just the first. Measured, not reasoned: an integration test on a virgin database caught it. - Undeclaring it without hiding it leaves the fingerprint moving between plan and apply, which is the reported bug unchanged.
+
+  The cost is the one the bootstrap path already states for the other ledger: the journal's shape cannot evolve through the declarative differ. Affordable for the same reason — it records in-flight deploys, not history anyone rebuilds a schema from. An existing database keeps its journal: an undeclared `_voltro_*` table is never planned for a drop.
+
+  There was no workaround. No read-only command creates the table, so nothing could be run ahead of the plan; `|| (db plan; db apply)` would swallow a REAL drift just as thoroughly; and creating a framework-internal table by hand in a production database is not something a user should be asked to do.
+- **The bulk-write rule sees the typed write helpers, which are now documented** — `@voltro/cli`
+
+  `voltro doctor`'s `bulk-write-in-loop` matched `store.insert(` and nothing else. Converting a loop to the typed helper made the finding disappear — and with it the reviewed decision attached to that finding, which the next run then reported as a `Stale review`.
+
+  A deployment that moved 107 write sites to the typed helpers hit exactly that on one loop and rolled the conversion BACK, with the right reasoning: trading a working rule for a typed check on four scalar fields is the wrong way round. Nobody should have to choose between our type safety and our linting.
+
+  The rule now matches the typed forms as well — `insertRow`, `insertRowEffect`, `upsertRowEffect`, `upsertRowOutcomeEffect`, `insertIgnoreRowOutcomeEffect` — and maps each onto the store verb it wraps, so the advice stays the one that fits (`insertMany` for a plain insert; one transaction around a conflict verb, which has no set-based form).
+
+  **The Effect helpers were documented nowhere, and that is fixed in the same change.** The two families live in different packages: the Promise forms `insertRow` / `upsertRow` are `@voltro/database`'s and were documented; the five Effect variants are `@voltro/runtime`'s and appeared on no page in either language. Knowing one family therefore sent readers looking for the other in the wrong package. The mutations page now carries both, with the split stated plainly, the typed error channel that a `Effect.promise` thunk throws away, and the `outcome` value — reading only the row and then recording a `created` event writes an audit entry for a write a conflict skipped.
+
+  That page already warned that adopting the typed form can blind tooling matching the old spelling. The warning was right and this rule was one of its victims.
+- **A project with a file migration can be applied to an empty database** — `@voltro/database`
+
+  `voltro db apply` could not create the schema of a project carrying even ONE file under `migrations/`, against a database that did not have `_voltro_migration_plans` yet — every new environment, every reset local database, every hermetic test stack. On postgres it ended like this, and nothing was applied:
+
+  ```text
+  INFO  file-based migration applying  id=20260918_040000_example
+  ERROR db apply: a file-based migration FAILED — the schema diff was NOT run
+  ERROR db apply: rolled back — postgres applies a deploy as one transaction, so
+        nothing changed
+  ```
+
+  Two halves of one cause, and the file pass runs BEFORE the planner that would create the table both of them want.
+
+  **Reading it.** The discovery step asks the ledger which migrations already ran, as a plain `SELECT` with a catch beside it that read an absent table as "nothing applied". That is correct outside a transaction and wrong inside one: postgres and SQL Server apply a whole deploy as a single transaction, and a failed statement aborts it, so every later statement of the deploy died — starting with the migration's own savepoint. The catch turned an error the database does not forget into one only the runner had forgotten. The question is asked of the catalog now, which answers on an empty database instead of failing.
+
+  **Writing it.** Recording a migration inserts into that same table, so on an empty database `up()` succeeded and the row could not be written — the one outcome whose message tells you not to re-run. The runner creates the ledger itself when something is pending, the way the resume ledger has always been created: a run needs it before any schema work of its own has happened. Nothing is created for a project with no pending file migration.
+
+  This was not confined to the dialects that hold a deploy in one transaction. On MySQL, MariaDB, Turso and SQLite the same recording insert failed, without a poisoned transaction to make it loud. Measured on all six dialects, red before the fix and green after it.
+
+  **A `voltro dev` boot was never affected, and that is measured rather than reasoned:** it creates the bookkeeping tables BEFORE the file pass, so the ledger is already there, and it holds no deploy transaction for a failed statement to poison. A real boot against a virgin schema with a file migration present, on the unfixed code, applies the migration and comes up. So the command to re-run after upgrading is `voltro db apply` — a development boot will not have told you anything was wrong.
+
+  **The two ledger readers now declare the failure they always had.** `appliedFileMigrationIds` and `appliedFileMigrations` (from `@voltro/database/sql`) were typed `Effect<…, never>` while the read could fail — the catch beside them was exactly the bug above. Their error channel is `SqlError` now. This is filed `apiSurface: compatible` rather than breaking: the old `never` was unsound, no documented path, guide or example reaches either symbol, and inside the framework only `deployCompensation` calls them. A consumer who nonetheless annotated one of them `never` widens that annotation to `SqlError`; nothing else changes, and the runtime behaviour is the one the type now admits.
+- **Two processes no longer run the same file migration** — `@voltro/database`
+
+  The runner read the pending file migrations before taking the migration lock and never again. A second replica that booted beside the first waited for the lock and then ran the list it had read while the first was still applying it: the body ran twice, and the second replica's boot died on the ledger row the first had written. It now re-reads the ledger under the lock, the same way schema migrations re-plan under theirs. A rollback of one migration from two places no longer runs its `down` twice either.
+
+  When a ledger row cannot be written because the row already exists, the message now says so — the migration IS recorded, by another process, and the body has run twice. It used to say the row was missing and that the next run would apply the migration again, which invited deleting a correct row.
+- **Delete inspected rows atomically against their selected snapshots** — `@voltro/cli`, `@voltro/devtools-ui`
+
+  Single and bulk deletion now use one conditional batch request with complete selected-row snapshots. A changed or missing row refuses the entire transaction without partial deletion. Live updates preserve the selection baseline, errors retain the selection or dialog, and duplicate confirmation clicks cannot dispatch another request. Both dashboard hosts use the same batch contract; the sequential single-delete fallback is removed.
+- **Reject stale data editor updates atomically** — `@voltro/cli`, `@voltro/devtools-ui`
+
+  Data editor updates carry the opening values of edited fields as required `expected` preconditions. Inspection compares them inside the write transaction, returning HTTP 409 for changed or deleted rows instead of overwriting concurrent changes. Cell editors retain their opening value during live refresh, and rejected writes retain the draft. Verified with Memory, Postgres, MySQL, MariaDB, SQL Server, SQLite and Turso. Deletion preconditions are not included.
+
+  Conditional reads reuse the framework row-lock query so namespace-bound stores lock the same physical table they update or delete.
+- **The migration pool refusal names the variable it actually reads** — `@voltro/cli`, `@voltro/database`
+
+  A migration needs two connections — one holds the lock, the other runs the statements — and a pool of one is refused up front. The refusal then told you to fix it with a variable nothing reads:
+
+  ```text
+  migrate needs ≥ 2 connections, the pool has 1 (DB_POOL_MAX=1) …
+  Set DB_POOL_MAX to at least 2 for the migrating process.
+  ```
+
+  `DB_POOL_MAX` is read nowhere in the framework. The pool size comes from `DB_MAX_CONNECTIONS` (or `PG_MAX_CONNECTIONS`). Following the instruction literally set a variable with no effect, produced the identical refusal, and left no next step — the worst shape a fix line can take, because it looks like the answer while it moves nothing. Both messages name the real variable now, and the one at the failure adds the driver's own `maxConnections` for a pool sized in code rather than in the environment.
+
+  **The check that exists to catch exactly this could not see it.** The message-API guard verifies that a variable a message tells you to SET is read somewhere — but it matched `VOLTRO_*` only, so every `DB_*` and `PG_*` instruction was outside its reach. The pattern now covers the framework's database variables too, which is what makes this class of defect detectable rather than merely fixed once.
+- **Offloaded calls carry their provider name to the dispatcher** — `@voltro/ai`
+
+  Every queued call on `_voltro_ai_inferences` stored `provider: 'unknown'`: the step read a key no provider config has. The dispatcher rebuilt the config from that column, so a real dispatcher resolved no model for any offloaded text, object, transcription or media call and gave up after its retries. The row and the step input now carry the config's `name`, and the dispatcher resolves the provider that was declared.
+- **Keep Radix primitives on the web dev server React instance** — `@voltro/cli`
+
+  The web dev server processes Radix packages through Vite so workspace dependencies share its deduplicated React instance during SSR, preventing invalid hook calls in dashboard navigation.
+- **Storage object claims are not carried between environments** — `@voltro/data-transfer`
+
+  The per-caller claims that hold a shared storage object were not classified for cross-environment transfer, so `voltro data` carried them by default. A claim names a physical key in one deployment's provider and a caller of that deployment; imported elsewhere, it kept the target retaining a key for a claimant it never had. The table is environment-local now, beside the storage operation and object-head tables it belongs with.
+- **No production warning about anonymous tenants when one is configured** — `@voltro/cli`
+
+  With `auth.anonymousTenantId` set, every production boot warned that anonymous callers resolve to the tenant their own `x-tenant` header names. A configured anonymous tenant is the server's choice and ignores that header, so the warning stated the opposite of what the server does. It now appears only when the header really decides.
+- **The junction-FK check no longer asks a dropped column for a reference** — `@voltro/cli`
+
+  `voltro doctor`'s junction-FK audit reported id-shaped columns that are plain scalars and asked for a `reference()`. It reported `dropped()` columns too:
+
+  ```text
+  ✗  junction FKs: 12 junction tables with an id column that is a plain text()
+     'apiKeys': 'keyId' (sits beside a wired reference() on this table)
+  ```
+
+  where the declaration is `keyId: dropped().safe()`. A tombstone cannot carry a `reference()` — the marker exists so the column disappears — so the finding was unresolvable by construction. Two of twelve entries in that list could never be acted on, and a list with unresolvable entries gets read less as a whole. That argument came from the deployment that reported it and it is the reason this is worth fixing rather than documenting.
+
+  The information was already there and thrown away: `dropped()` builds a `text` column carrying `dropped: true`, and the mapping into the audit lifted only the name, the type and the external-id marker. It carries the tombstone flag now, and the audit skips those columns.
+- **The pre-apply question no longer promises a rollback the dialect cannot do** — `@voltro/cli`
+
+  On the dialects that apply a plan one statement at a time, the confirmation you answer before a deploy said:
+
+  ```text
+  … if one fails, this run undoes what it applied (the schema back to its
+  pre-deploy shape, file migrations by their down) and stops.
+  ```
+
+  and the failure message in the SAME run said the opposite:
+
+  ```text
+  This dialect does NOT apply a plan atomically: those 20 are COMMITTED and
+  there is no rollback.
+  ```
+
+  The second one is right. The first is not occasionally wrong — the question is asked only where a plan is applied statement by statement, so the promise was wrong at every site it could ever be printed. Someone reading it went into the deploy believing a failure was free.
+
+  It now says what actually happens: the statements before the failure are COMMITTED, and the runner then ATTEMPTS a compensation. The attempt and its limits are stated together rather than one before the deploy and the other after the failure.
+
+  The `down` clause needed the same treatment. A migration declared `irreversible()` has no `down`, so for a project whose file migrations are all irreversible the sentence promised something that could not happen in any case. What no undo can reach — the rows a lossy operation removed, and every irreversible migration's effect — is named in the same breath.
+- **`transactional()` no longer resolves over a transaction the database ended** — `@voltro/database`, `@voltro/sql-postgres`, `@voltro/sql-mysql`, `@voltro/sql-mssql`, `@voltro/sql-sqlite`
+
+  A work callback that caught a failed statement and carried on made `transactional()` resolve — and on Postgres nothing was committed: the failed statement aborts the transaction, every later one is refused, and COMMIT runs as ROLLBACK without raising. The rows that had succeeded were lost too, and the caller was told they were written.
+
+  It now fails with `TransactionAbortedError`, which names the caught failure and the working form. To skip a failing statement and keep the rest, run it inside `tx.savepoint(() => …)`: only that statement is rolled back. Code that catches store failures inside a transaction without a savepoint will now see this error where it used to see a silent loss.
+
+  The same guard runs on MySQL, MariaDB, SQL Server and SQLite, where it closes a different hole: a deadlock rolls the WHOLE transaction back and the session leaves it, so a caller that caught the deadlock and kept writing wrote in autocommit — durable at once, and out of reach of any later rollback. After such a failure no further statement is sent, and because a deadlock is retryable the work runs again from the start in a fresh transaction.
+- **An app whose workflows are all internal no longer reports a false mismatch** — `@voltro/cli`
+
+  An app that declares at least one workflow and marks every one of them `internal: true` logged this on every page load:
+
+  ```text
+  [voltro] the api client this page loaded does not match what the 'app' server
+  binds: __voltro.workflow.cancel, __voltro.workflow.control,
+  __voltro.workflow.domainEvents and 10 more. Responses for those procedures may
+  decode against the wrong schema …
+  ```
+
+  Nothing was wrong with the schemas, and the advice the message gives — reload, delete `.framework/.vite` — could not help, because the two sides were answering different questions. Both boot paths bind the 13 workflow built-ins for **any** discovered workflow; the codegen emitted them only when one was reachable over the wire. An internal-only app therefore ran a server binding 13 procedures its generated client had never been given.
+
+  `internal: true` answers *who may start this workflow over the wire* — it is a start decision. The built-ins start nothing: they read and steer runs that already exist, which is why an internal workflow's runs stay inspectable. So the server was right, and the codegen now follows it.
+
+  The two questions are separate in the generator now rather than one flag doing both, and the narrower one still decides what it should: an app with no wire-exposed workflow gets no start lift and no unused import for one. An app with no workflow at all is unchanged — emitting the built-ins there would be the same mismatch in the mirror image.
+- **Bind dashboard bulk actions to previewed workflow runs** — `@voltro/devtools-ui`
+
+  Bulk workflow actions use the eligible run IDs from their preview instead of selecting newly matching runs. Pending requests lock filters and block duplicate submissions; failures discard the preview while retaining the operator's inputs.
+- **Report declined bulk workflow recovery actions accurately** — `@voltro/cli`
+
+  Bulk replay reports declined redrives with their original reason instead of counting them as successful. Retry requires an execution identity; a missing workflow runtime cannot produce a successful no-op. Accepted recovery actions do not imply completed workflow executions.
+- **Refuse false recovery success for an unchanged retry identity** — `@voltro/cli`, `@voltro/devtools-ui`
+
+  Bulk retry reports an unchanged execution identity instead of claiming successful recovery of the original failed run. Dashboard retry guidance explains payload resubmission and idempotency rather than promising a fresh execution or empty journal.
+- **Retain operator cancellation causes in control receipts** — `@voltro/cli`
+
+  Shared cancellation helpers persist the supplied reason and details even when generating a request ID. Repeating an explicit intent preserves its original cause; producer sweeps still require confirmed cancellation rather than mere acceptance.
+- **Workflow controls ask the same access question as the workflow read feeds** — `@voltro/runtime`, `@voltro/cli`
+
+  The workflow built-ins decided access twice, in two places. The read feeds behind `useWorkflowRuns`, `useWorkflowRun`, `useWorkflowRunSteps` and `useWorkflowRunEvents` let a subject holding `admin:full` see every run; the control actions — `cancel`, `signal`, `update`, `resume` — compared tenants only, so the same subject could see a schedule's run in the list and was refused when it tried to cancel it.
+
+  Both halves now ask one function. What a caller may drive is what it may read:
+
+  - a system subject or one holding `admin:full` reads and drives every run; - a run the system started — a schedule's, say, or one of an `internal: true` workflow started from server code — belongs to the operator, and no user reaches it; - a run with a tenant is shared by that tenant's users.
+
+  Every signed-in subject carries a tenant, so an app that does not use tenants is one whose users share one: they see and drive each other's runs, and none of them reaches a system-started run.
+- **Show complete bulk workflow recovery failures** — `@voltro/devtools-ui`
+
+  Both workflow bulk-action surfaces expose every per-run failure with its full identity and reason in paginated details. Recovery acceptance is labelled separately from successful workflow completion.
+- **Resolve workflow retry through the original run owner** — `@voltro/cli`
+
+  Development and production workflow retry resolve the original run’s physical store before reading its payload, matching the Inspect path. Missing or ambiguous ownership refuses dispatch instead of searching the primary store.
+- **Keep workflow selection confirmation bound to reviewed runs** — `@voltro/devtools-ui`
+
+  Changing checked workflow runs resets their bulk-action preview, including delayed responses for a previous selection. Apply targets only previewed eligible IDs. Pending actions lock controls and reject duplicate submissions; changed reasons and failed requests require a new preview.
+
+---
+
 ## [0.74.0] — 2026-09-18
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/ui-shadcn",
-  "version": "0.74.0",
+  "version": "0.75.0",
   "description": "Voltro's first-party shadcn/ui kit: Tailwind v4 design tokens (light + dark), 30+ primitives, layout compositions, styled widgets for the @voltro/ui seam, and the canonical theme/language preference-cookie helpers.",
   "keywords": [
     "voltro",
@@ -52,7 +52,7 @@
     "@radix-ui/react-toggle-group": "^1.1.19",
     "@shikijs/langs": "^4.4.3",
     "@shikijs/themes": "^4.4.3",
-    "@voltro/ui": "0.74.0",
+    "@voltro/ui": "0.75.0",
     "class-variance-authority": "^0.7.1",
     "clsx": "^2.1.1",
     "shiki": "^4.4.3",