@voltro/database 0.69.1 → 0.70.0

package/CHANGELOG.md

@@ -39,6 +39,86 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [0.70.0] — 2026-09-11
+
+### ⚠ BREAKING
+
+- **@voltro/cli** — The DevTools dashboard has a lock of its own: `VOLTRO_DASHBOARD_TOKEN`. A deployed dashboard that holds other apps' inspect tokens in `VOLTRO_DASHBOARD_APPS` refuses to boot in production without it, `/api/dashboard/config` no longer serves token values, and the proxy attaches a configured target's credentials itself.
+
+  Before this the dashboard had no door: whoever reached its URL got every configured app's inspect read AND write token from `/api/dashboard/config` in one request, and the proxy forwarded whatever bearer that browser then presented. The URL was the credential.
+
+  Three rules now, on both boot paths: the browser proves the dashboard token once (`POST /api/dashboard/login`) and gets an HttpOnly, SameSite=Strict session cookie derived from it by HMAC (12 h; a rotated lock invalidates every cookie); every other `/api/dashboard/*` route answers 401 without a session; the config route says where the targets are and whether the pod holds credentials (`hasToken`, `hasWriteToken`), never which. A dashboard with nothing to guard (no configured targets, a loopback dev registry) boots open as before — setting the token locks it anyway. `voltro secret generate dashboard` prints the variable paste-ready. `codemod: none`: no user code changes; the operator sets one variable, and the chart's `dashboardToken` renders it.
+
+  **No codemod** — this break touches no user-authored code.
+
+### Added
+
+- **@voltro/protocol, @voltro/plugin-openapi, @voltro/cli, @voltro/testing** — The `publicApi` surface speaks a REST profile, chosen once in the api's `app.config.ts` (`publicApi: { profile }`) and overridable per descriptor (`publicApi.format`): `'rpc'` — the default, today's wire — `'standard'`, `'jsonapi'`, or a `RestFormat` object of the app's own, with building blocks (`dates`, `errors`, `envelope`, `pagination`, `naming`, `etag`) that override the preset. `'standard'` is the Zalando / Google AIP / Microsoft intersection: `timestampMs` as RFC 3339 (accepted inbound too), every failure as RFC 9457 Problem Details — the transport's refusals included — no envelope, a `nextCursor` as a `Link: <…>; rel="next"` header, a weak `ETag` on GET with `If-None-Match` → 304. `'jsonapi'` answers `{ data, links }` as `application/vnd.api+json`. The spec follows the profile (`format: date-time`, the `ProblemDetails` component, `Link`/`ETag` headers, snake-case names). `makeTestApp({ publicApiProfile })` measures the same wire.
+
+  A path with `{teamId}` or `:teamId` binds that segment to the input field of the same name — always, under every profile — with the remaining fields from the query string (GET) or the body; the brace form used to be no route, the colon form a `400`, so `GET /v1/teams/{teamId}` was unreachable for a projection.
+- **@voltro/testing, @voltro/database** — `makeTestContext({ fieldEncryptionKey })` registers the field cipher for `.encrypted()` columns under test. Setting `VOLTRO_FIELD_ENCRYPTION_KEY` — in `process.env` or the context's `env` — did nothing here, because the harness runs no boot gate and the gate is what turns the variable into a cipher; the only working route was `setFieldCipher(makeFieldCipher(key))` from another package, which nothing pointed at. The refusal now names the option.
+- **@voltro/database, @voltro/runtime** — `insertIgnoreWithOutcome` on the framework store (and on `yield* EffectStore` plus the `tx` view), with the typed helper `insertIgnoreRowOutcome`: `{ row, outcome: 'inserted' | 'ignored' }`.
+
+  `insertIgnore` returns the existing row on the ignore path, and that row is indistinguishable from one it just wrote — so a loop that plants missing rows reported every row it visited as planted unless it read the destination first, per row. The answer is decided the way `upsertWithOutcome` decides it: the id the store minted before the statement is not the id the ignore path hands back; where the id cannot decide (caller-supplied, or database-assigned) the destination is read first and the answer stays exact. Plain `insertIgnore` never pays for that read.
+- **@voltro/protocol, @voltro/client, @voltro/web** — `defineMutation({ serialize: { key, maxPending? } })` — calls of one mutation to the SAME resource run in invocation order on the client, for every caller of the tag. A row lock serialises transactions, not the order a browser invoked them in: two quick saves of one snapshot could take the lock in reverse order and the older snapshot then overwrote the newer one; server-side idempotency does not see it, and `.version()` detects the conflict and replays the older write. `key` names the resource from the input; calls sharing it run one at a time, FIFO, per subject, the permit spanning connection setup, the request, replay and its acknowledgement — optimistic previews stay immediate, different keys run independently. An unknown outcome (a transport failure after the request started) blocks the key for that subject rather than let a later write pass it; a subject change drops the queue; admission beyond `maxPending` (default 32) rejects with `MutationSerialExecutionError`. `useMutation`'s `pending` now counts every concurrent call, not only the one that settled last.
+
+  Declared on the descriptor — where `concurrency` lives for workflows — rather than as a hook builder, because a hook-scoped queue orders one component's calls and lets a second component writing the same resource interleave. Not a durable outbox, a distributed lock or a cross-tab merge.
+- **@voltro/cli** — API `fonts:` declarations now package validated native-readable fonts and relocatable Fontconfig artifacts during build. Dev, serve and direct production entries activate them before startups and handlers; missing or corrupt artifacts refuse boot. Native renderers no longer depend on undeclared host fonts or original workspace font paths.
+- **@voltro/plugin-openapi** — Every mounted API version has an OpenAPI document of its own — `/openapi/v2.json` beside `/openapi.json`, or `?version=v2` — the same spec filtered to that version, every operation fact included; the unversioned URL keeps serving everything. With more than one version mounted the docs page shows Swagger UI's "Select a definition" dropdown: one entry per version, newest first and preselected, an expiring version named with its earliest `sunset` (`v1 — sunset 2027-03-01`), the whole document last.
+
+  Before this `v1` and `v2` shared one document and one viewer: a consumer integrating `v2` scrolled past every `v1` path, and a generator built both into one client.
+- **@voltro/protocol, @voltro/cli, @voltro/plugin-openapi** — `onProcedureSurface` — a plugin hook told the app's wire-reachable rpc procedures (every query, mutation, action and stream discovery found, minus `internal`) once discovery has run, on both boot paths; the procedure counterpart of `onRestSurface`. `openapiPlugin({ includeAppProcedures: true })` documents them as `POST /rpc/<name>` operations without the app listing them: opt-in, so the spec stays REST-only unless asked, and a procedure also passed in `procedures` is documented once.
+
+  Before this `procedures` was the only way in, and filling it meant importing every descriptor module into `app.config.ts` — evaluated before discovery on every load of the config, the pattern the `onRestSurface` docs name as a boot that hung — while `voltro serve` loads no TypeScript at runtime, so a plugin could not read them later either.
+- **@voltro/protocol, @voltro/plugin-openapi** — A `publicApi` projection documents itself completely: `tags` from the rpc tag's prefix (`teams.list` → `teams`; `publicApi.tags` overrides) with a top-level `tags[]` and `tagDescriptions` on the OpenAPI plugin; an `operationId` from the tag (`teamsList`; `publicApi.operationId` overrides); `security` on every operation — required, or optional under `openAccess` (`[{ bearerAuth: [] }, {}]`), `publicApi.security: false` for none — with `securitySchemes.bearerAuth` published once any projection exists; one response per `errorStatus` entry carrying the error's own schema, `422` for the union's other tags, `429` for a mounted rate limiter; `publicApi.example: { request?, response? }`; path parameters `in: path` and query parameters typed from the input.
+
+  Before this the plugin wrote `tags` only for an explicit `version`, `security` only for a `guards:` route — so after "Authorize" Swagger UI sent the token to those alone and "Try it out" on every other route ran without a key — no `operationId`, no `errorStatus` response, no example, and no query parameter at all for a GET projection.
+
+### Fixed
+
+- **@voltro/protocol** — A `publicApi.path` segment that names no input field refuses the boot, naming the descriptor and the segment (`descriptor 'bookings.get' — path '/v1/bookings/:uuid' binds ':uuid', and the input declares no field of that name (fields: bookingId)`). A field the path binds may repeat in the body or query string with the same value — a PATCH carrying the whole resource — but another value answers `400` naming the field.
+
+  Before this the segment was bound silently: the route mounted, the handler never saw the value, and a body that carried the same field with another value was overwritten by the path without a word.
+- **@voltro/protocol, @voltro/runtime, @voltro/plugin-openapi, @voltro/plugin-prometheus** — A plugin route answers the path it declared, byte for byte: the dispatcher refuses a request whose path is not the route's own — case-folded twins and a bare trailing slash included — with `404`, before the body is read. `PluginHttpRoute.match: 'exact'` narrows a route to its path alone, no sub-path; the default stays `'prefix'`, the contract every route that branches on its tail was written against. A REST descriptor is an exact route; the OpenAPI spec and docs routes and the Prometheus scrape route declare `'exact'`.
+
+  Before this the router matched without case and ignored a trailing slash, and every route owned its sub-paths: `/OPENAPI.JSON`, `/openapi.json/`, `/Docs` and `/Metrics` all answered, so a path guard at the ingress that named the one documented spelling covered none of the others. The docs of both plugins now say the guard can name the path as written.
+- **@voltro/workflow, @voltro/cli** — A run that ended outside the engine no longer leaves its unanswered requests in the cluster journal. Cancelling a run (`timeouts.finish`, `cancelOn`, the operator's button, the bulk action) discards its unprocessed messages at once, and the staleness tick discards those of every ended run (`succeeded`, `failed`, `cancelled`) that a runner last read more than a minute ago — logged as `workflow.cluster: discarded unprocessed messages of runs that have ended`.
+
+  Before this, the `activity` request a killed executor was inside stayed unprocessed after the run was cancelled: every runner that acquired the shard re-read it every ten minutes for the rest of time, its handler waited on a latch that never opens, and the `unprocessed messages` warning was printed again on every engine start. An unprocessed `run` request of a cancelled run would have gone further and executed it. The engine's own reset deletes one request; this deletes the ended run's, and `ClusterDiagnostics.discardMessages` is the one write on that service.
+- **@voltro/cli** — `voltro db encrypt-column <table>.<column> .` accepts the app directory every other `db` command takes as its last argument — accepted and not needed, the connection comes from env. It used to parse `.` as a column reference and refuse. A positional that is neither a `<table>.<column>` nor a directory is named in the refusal.
+- **@voltro/runtime, @voltro/cli, @voltro/database** — Every API key has its `actors` row after the first boot on this version. Both boot paths plant, after the schema is applied, one row per `_voltro_api_keys.id` that has none — through the same `ensureActor` a new key goes through (the built-in row, or the app's `apiKeys.ensureActor` handed the issue input rebuilt from the row). Idempotent; two queries when nothing is missing; `api keys: planted actors rows for keys that had none` with the count, and a key whose row cannot be written is named in a warning rather than failing the boot.
+
+  Two release notes had asked the operator to run a loop once. The first was printed to the wrong group; the second printed `store.select(...)` for a `*.startup.ts`, and `StartupContext.store` is a `DataStore` with no fluent builder — both API pods refused to boot on it. The 0.69.1 note now says what the boot does and which line to look for. The framework tables `@voltro/database` exports (`_voltroApiKeysTable` and the others) are typed `SchemaTable` instead of `TableLike`, so `queryFor(_voltroApiKeysTable)` compiles where a hand-written read is still wanted.
+- **@voltro/runtime** — Idempotent WebSocket mutations acquire and finalize their claims safely across request interruption. A closed socket cannot orphan a claim acquired by a still pending store Promise; synchronous executor failures release fresh claims too. Already-started Promise executors finish their actual write and record the result before interruption completes, preventing a replay from duplicating the write. Effect executors remain interruptible and release only after cleanup. A late interrupt never deletes the completion receipt of a successful write.
+
+  Codemod: none — no application source or configuration changes. Claim TTL, replay limits, transport guards and process-crash recovery guarantees are unchanged.
+- **@voltro/cli** — Docker deployments retain optional native platform bindings until runtime tracing, and the pruner traces both conditional import and require entries so relocated API and web images can still execute native image processing.
+- **@voltro/workflow, @voltro/cli** — `own` on a shard-lock holder in the stall report and the `workflow.cluster` warning is now the engine's own account (`Sharding.hasShardId`), and a holder that is this runner reads `this runner (pid N)`.
+
+  The first version compared the holder's pid with `pg_backend_pid()` of the query that asked. The advisory lock lives on the runner's reserved connection, and the pool hands every other query a different backend — so a runner's own 300 locks read as a stranger's, always, and behind a connection pooler nothing in `pg_stat_activity` could have told them apart either. The report's stated lever for a stranger, ending the holder's session, would have ended the runner. The hint now distinguishes the three cases (another runner, a session that outlived its runner, this runner re-reading a request nobody answers), and the docs say to read `own` before `pg_terminate_backend`.
+- **@voltro/cli** — Production HTTP proxies release upstream resources when the browser abandons an unfinished response, including SSE, and propagate truncated upstream responses as transport failures instead of hanging. Complete responses retain payloads and keep-alive; no application configuration change is needed.
+- **@voltro/protocol, @voltro/runtime, @voltro/cli, @voltro/testing, @voltro/plugin-ratelimit** — `publicApi.rateLimit` on a descriptor is that endpoint's own rule for calls through the `/v1` projection — ahead of the plugin's `rules` and `default`, one bucket per caller per endpoint, under `enabled`. A REST call now carries `surface: 'rest'` and the descriptor's `publicApi` spec on the interceptor context, so a plugin can tell a projected call from an rpc one.
+
+  The field said "rides @voltro/plugin-ratelimit when mounted" and nothing read it: three calls at `limit: 1` answered `200 200 200`, no bucket, no `onLimited`. The plugin never learned which calls came through the projection, let alone what it declared. Without the plugin mounted the spec is inert, as the comment always implied.
+- **@voltro/cli** — The retention sweep arms its policies on the `_voltro_workflow_*` tables only where the workflow engine that creates those tables is composed. An api with no `*.workflow.tsx` has no engine and no such tables, and the five policies still armed on them were five failing `DELETE`s per tick, each an `ERROR` line in the database log, for the life of the deployment — not switchable off from the app. The boot line `retention: N policy(ies) armed` now lists exactly what is swept.
+- **@voltro/plugin-mail** — SMTP replies are classified by SMTP rules instead of HTTP rules: 4xx replies remain retryable, permanent 5xx rejections do not trigger automatic retries (RFC 5321 §4.2.1). HTTP providers keep their existing policy. Tests exercise actual loopback connections, envelope, MIME and attachment encoding without sending external mail.
+
+  Codemod: none — corrected SMTP reply semantics require no application source or configuration migration.
+- **@voltro/workflow** — The workflow engine's boot check for its cluster tables asks whether a table exists with a query that succeeds either way (`to_regclass` on postgres, `information_schema` on mysql, `OBJECT_ID` on mssql, `sqlite_master` on sqlite) instead of selecting from the table and reading the failure as "no" — which the database server logged as an `ERROR` on every first boot of a database. The probes `@effect/cluster` itself makes for its legacy tables are upstream and still fail-as-answer.
+- **@voltro/cli** — `voltro dev` acquires the workflow runtime as a boot step, as `voltro serve` always has — `workflow runtime ready — N entity type(s) registered` on both paths, through one shared helper with a parity test.
+
+  A `ManagedRuntime` builds its layer on first use, and `voltro dev` never used it at boot. A fleet of dev pods therefore had NO cluster runner after a restart — no runner row, no shard locks, no re-delivery — until something asked the runtime for a service. The first thing that asked, in a deployment, was the once-per-fleet staleness tick, five minutes after the boot, in the one pod that ran it: a run orphaned by the restart waited exactly that long and was then adopted by that pod alone.
+- **@voltro/cli** — `voltro baseline sync` writes its `docker/Caddyfile` with tabs, the way `caddy fmt` writes it. Caddy warned on every proxy start that the file "is not formatted", and a project that checks its generated files for drift could not fix it on its side — the next sync undid it.
+- **@voltro/plugin-ratelimit** — `redisStore({ url })` binds its client on the first `consume` when nobody activated it — from `url` or the env it reads at activation — so a limit holds in the test harness, where `makeTestContext` runs no lifecycle hooks. A store with neither stays fail-open (`failOpenReason: 'unbound'`), as at activation.
+
+  Before this a suite that "checked the redis store" ran every call through an unbound store: `200 200 200` at `limit: 2`, no key in Redis, no warning — and nothing a test could read told "the limit held" from "the store was never there".
+- **@voltro/cli, @voltro/i18n** — A `src/pages/[locale]/…` route renders in the locale it matched, on both web boot paths: `voltro start` and `voltro dev` hand the matched `[locale]` parameter to the same i18n resolver (also for the ISR key and for an app without catalogs), and `resolveLocale` takes it as `routeLocale` — ahead of the `voltro:locale` cookie, `Accept-Language` and the default, and only on an exact supported spelling. The build's static prerender already did this; the runtime render fell back to cookie or browser language, so `/en` answered with a German head and `html lang="de"`. In the same change `voltro dev`'s buffered SPA and ISR responses merge a page's `meta.title` into the shell the way production does — there was a second `<title>` before.
+- **@voltro/protocol, @voltro/runtime, @voltro/cli, @voltro/testing, @voltro/plugin-ratelimit** — A rate-limited call on the `/v1` projection answers `429` with `Retry-After` and the `RateLimit-Limit` / `RateLimit-Remaining` / `RateLimit-Reset` headers, the tag and fields as the body — on both boot paths and in `makeTestApp`. A `PluginErrorSchema` may declare `rest: { status, headers }`; the projection encodes a plugin's cross-cutting error under that status (`422` when it names none; the descriptor's own `errorStatus` entry wins), and the plugin declares `429` for `RateLimited`.
+
+  The plugin merged `RateLimited` into every rpc's wire union at boot and the client decoded it typed, but the REST projection encoded through the descriptor's own `error:` union only — the one surface with no typed channel to fall back on answered `500 Internal Server Error` with no `Retry-After`. The only way to a `429` was to import a plugin error into every descriptor file. A `500`'s cause now rides on the response value off the wire, so the `GET /v1/… → 500` log line names the reason on `voltro serve` too.
+
+---
+
 ## [0.69.1] — 2026-09-11
 
 ### Added

package/dist/index.d.ts

@@ -2392,6 +2392,26 @@ export declare interface DataStore {
     insertIgnore(table: string, row: Row, options: {
         conflictColumns: ReadonlyArray<string>;
     }): Promise<Row>;
+    /**
+     * `insertIgnore`, plus the one thing it cannot report: whether the row was
+     * INSERTED or already there.
+     *
+     * On the ignore path `insertIgnore` returns the existing row, which looks
+     * exactly like a freshly inserted one — so a loop that plants missing rows
+     * counts every row it visited as planted, unless it reads the destination
+     * first. Same shape and same answer as `upsertWithOutcome`: the wrapper
+     * mints the id before the statement, the ignore path hands back the EXISTING
+     * row's id, and two ids that differ are the answer. Where that comparison
+     * cannot decide (the caller supplied the id, or the id is database-assigned)
+     * the destination is read first, so `'inserted'` is exact, never a guess.
+     *
+     * Optional and wrapper-provided for the same reason as `upsertWithOutcome`:
+     * present on `ctx.store`, not required of a hand-written `DataStore`. The
+     * typed helper is `insertIgnoreRowOutcome`.
+     */
+    insertIgnoreWithOutcome?(table: string, row: Row, options: {
+        conflictColumns: ReadonlyArray<string>;
+    }): Promise<InsertIgnoreResult>;
     /**
      * Run `work` inside a transaction. ALL `insert/update/delete` calls
      * made via `work`'s store reference (passed as argument) are:
@@ -3726,7 +3746,7 @@ export declare const formatSubjectGraph: (graph: SubjectGraph) => string;
  */
 export declare const FRAMEWORK_LIVE_TABLES: ReadonlySet<string>;
 
-export declare const frameworkTables: readonly [TableLike, TableLike, TableLike];
+export declare const frameworkTables: readonly [SchemaTable, SchemaTable, SchemaTable];
 
 declare type FullTextIndexMeta = {
     readonly name: string;
@@ -4071,6 +4091,39 @@ export declare type InferViewRow<V> = V extends View<string, infer F> ? InferRow
  */
 export declare const INITIAL_VERSION = 1;
 
+/** What an `insertIgnoreWithOutcome` did, beside the row it hands back. */
+export declare interface InsertIgnoreResult {
+    readonly row: Row;
+    /** `'ignored'` means a row already existed for the conflict key; it is the
+     *  row returned, untouched. */
+    readonly outcome: 'inserted' | 'ignored';
+}
+
+/**
+ * `insertIgnore`, plus whether the row was INSERTED or was already there.
+ *
+ * `insertIgnore` returns the existing row on the ignore path, and that row is
+ * indistinguishable from one it just wrote — so a loop that plants missing
+ * rows reports every row it visited as planted unless it reads first. The
+ * store knows the answer the same way `upsertRowOutcome` does: the id it
+ * minted before the statement is not the id the ignore path hands back.
+ *
+ *     const { row, outcome } = await insertIgnoreRowOutcome(ctx.store, actors, actor, {
+ *       conflictColumns: ['id'],
+ *     })
+ *     if (outcome === 'inserted') planted++
+ *
+ * `'inserted'` is never a stand-in for "could not tell". Where the id cannot
+ * decide it — the caller supplied one, or the table's id is database-assigned
+ * — the store reads the destination first and answers exactly.
+ */
+export declare const insertIgnoreRowOutcome: <T extends AnyTable>(store: TypedInsertIgnoreOutcomeStore, table: T, row: InferInsertRow<T>, options: {
+    readonly conflictColumns: ReadonlyArray<keyof InferRow<T> & string>;
+}) => Promise<{
+    readonly row: InferRow<T>;
+    readonly outcome: "inserted" | "ignored";
+}>;
+
 /**
  * Insert MANY rows, typed against the table — `insertRow`'s batch, and nothing
  * else: it forwards to `store.insertMany` unchanged, so the chunking, the
@@ -8167,6 +8220,16 @@ export declare interface TxnRecorderPort {
     readonly maxOf: TxnMaxOf;
 }
 
+/** The minimal store surface `insertIgnoreRowOutcome` needs. */
+export declare interface TypedInsertIgnoreOutcomeStore {
+    readonly insertIgnoreWithOutcome?: (table: string, row: Row, options: {
+        readonly conflictColumns: ReadonlyArray<string>;
+    }) => Promise<{
+        readonly row: Row;
+        readonly outcome: 'inserted' | 'ignored';
+    }>;
+}
+
 /** The minimal store surface `insertManyRows` needs. */
 export declare interface TypedInsertManyStore {
     readonly insertMany: (table: string, rows: ReadonlyArray<Row>) => Promise<ReadonlyArray<Row>>;
@@ -8598,7 +8661,7 @@ export declare const VOLTRO_LOCAL_FIRST_MIXIN_ID: "voltro/localFirst";
  * app (empty unless `apiKeys` is enabled in app.config). See
  * `@voltro/runtime`'s `ApiKeyService`.
  */
-export declare const _voltroApiKeysTable: TableLike;
+export declare const _voltroApiKeysTable: SchemaTable;
 
 export declare const _voltroCdcOffsetsTable: TableLike;
 
@@ -8632,7 +8695,7 @@ export declare const _voltroDataTransfersTable: TableLike;
  * a record dropped while still inside that window lets the duplicate request it
  * exists to stop execute a second time.
  */
-export declare const _voltroIdempotencyTable: TableLike;
+export declare const _voltroIdempotencyTable: SchemaTable;
 
 /**
  * `_voltro_kv` — the durable key-value store behind `ctx.kv` / the `Kv`
@@ -8643,7 +8706,7 @@ export declare const _voltroIdempotencyTable: TableLike;
  * evicted for capacity — they live until deleted or their TTL lapses. Created
  * for every sql app (empty unless `ctx.kv` is used).
  */
-export declare const _voltroKvTable: TableLike;
+export declare const _voltroKvTable: SchemaTable;
 
 /**
  * `_voltro_migration_plans` — one row per declarative-diff plan
@@ -8661,7 +8724,7 @@ export declare const _voltroKvTable: TableLike;
  * the escape-hatch for split/merge/data-move migrations the diff can't
  * infer.
  */
-export declare const _voltroMigrationPlansTable: TableLike;
+export declare const _voltroMigrationPlansTable: SchemaTable;
 
 /**
  * `_voltro_migrations` — one row per migration file. Created by the
@@ -8669,7 +8732,7 @@ export declare const _voltroMigrationPlansTable: TableLike;
  * as each migration's lifecycle progresses (pending → running → applied
  * | failed | reverted).
  */
-export declare const _voltroMigrationsTable: TableLike;
+export declare const _voltroMigrationsTable: SchemaTable;
 
 export declare const _voltroMssqlCdcOffsetsTable: TableLike;
 
@@ -8718,7 +8781,7 @@ export declare const _voltroReplaceInProgressTable: TableLike;
  * writing a full subscription list here every heartbeat would be write
  * amplification for state nobody is reading.
  */
-export declare const _voltroReplicaObservationsTable: TableLike;
+export declare const _voltroReplicaObservationsTable: SchemaTable;
 
 /**
  * `_voltro_seeds` — one row per registered seed. Written to by the
@@ -8726,7 +8789,7 @@ export declare const _voltroReplicaObservationsTable: TableLike;
  * seeds re-run when the fingerprint changes; the `lastRun*` fields
  * capture the most recent execution (history lives in the audit log).
  */
-export declare const _voltroSeedsTable: TableLike;
+export declare const _voltroSeedsTable: SchemaTable;
 
 export declare const walkLeaves: (predicate: Predicate, conjunctive?: boolean) => Generator<PredicateLeafWithContext>;