@voltro/database 0.23.0 → 0.24.0

package/CHANGELOG.md

@@ -39,6 +39,117 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [0.24.0] — 2026-08-02
+
+### ⚠ BREAKING
+
+- **@voltro/ai, @voltro/cli** — **`agent_threads` and `agent_messages` are `_voltro_agent_threads` and `_voltro_agent_messages`.** The last two framework-owned tables sitting in the user's namespace; the other ten moved in 0.22.0 and these were not in that set.
+
+  The collision it ends is the obvious half. The half that cost a consumer something is `versioningPlugin`: its "framework and plugin tables are out of the default" keys on the `_voltro_` prefix, so `agent_messages` was IN the default versioned set — and `runAssistant` patches the streaming assistant row about every 100 ms while it types. Under `timing: 'in-transaction'` that is a row-history write per throttle tick, on the hottest path in the app. They found it while adopting the versioning inversion and excluded both tables by hand; that `exclude:` entry can go now.
+
+  **The rows move themselves.** `.renamedFrom()` on both, so the next `db apply` or auto-migrate boot emits a catalog-only `ALTER TABLE … RENAME TO` on every dialect — no copy, no row rewrite. `AGENT_THREADS_TABLE` / `AGENT_MESSAGES_TABLE` are exported and carry the new names, and the synthesized `<agent>.messages` query moved with them, so typed code is unaffected.
+
+  The codemod is `manual` for the same reason the 0.22.0 one was: what a transform cannot see is raw SQL written by hand against those names.
+
+### Added
+
+- **@voltro/plugin-auth** — Brute-force account lockout. After 5 failed credential attempts (wrong password OR wrong MFA code) within 15 minutes, sign-in for that email is refused with a `429 account_locked` for 15 minutes; a completed login clears the counter. The counter is keyed by email — an unknown address locks exactly like a real one, so the lock can't be used to probe which accounts exist. **On by default** (a security default); tune or disable via `authRoutesPlugin({ lockout: { maxAttempts, windowSeconds, lockSeconds } })`. Apps that spread `authTables` get the new `loginAttempts` table automatically on the next `voltro db apply` / `voltro dev` boot — it rides the declarative differ, no codemod.
+- **@voltro/cli** — Backup provenance stamp. `voltro data backup` now writes a `voltro-backup-stamp.json` sidecar next to the native dump recording the dialect, the authoritative live-schema fingerprint, the `@voltro/cli` version, and the timestamp — a native `pg_dump`/`mariadb-dump` artifact is otherwise opaque about what it is. `voltro data restore` reads the stamp BEFORE touching the DB and acts on two failures that are silent until they corrupt: a CROSS-DIALECT restore (postgres dump into a mysql DB) is REFUSED (override with `--force`), and a SCHEMA/CODE fingerprint skew WARNS to run `voltro db apply` after the restore. A backup with no stamp (older/hand-made) restores with a caution, not a hard stop. Docs additionally clarify that point-in-time recovery (PITR) is a database/provider concern (WAL/binlog archiving) the framework deliberately does not reimplement, and that a backup you have never restored is a hypothesis. `codemod: none` — new CLI output + a restore-time guard; no user-authored code is affected.
+- **@voltro/database, @voltro/sql-postgres, @voltro/runtime, @voltro/cli** — Per-statement query timeout via `DB_STATEMENT_TIMEOUT_MS` (or `ConnectionConfig.statementTimeoutMs`). A runaway query — a missing index, an accidental cartesian join — no longer pins a pooled connection indefinitely: it is cancelled once it outlasts the deadline, its connection returns to the pool, and the caller gets a normal error instead of a hang that, under load, exhausts the pool and stalls the whole app. Applies to the **runtime query path only** — migrations (`voltro db apply`) run legitimately long statements and are never cancelled by it. **Wired for postgres today** (the default dialect), where it maps to the server-side `statement_timeout` — a real server-enforced cancel (SQLSTATE `57014`), not a client-side disconnect that leaves the query running. Other dialects accept the field but currently ignore it (mssql's driver exposes no per-request timeout, MySQL/MariaDB's `max_execution_time` bounds SELECTs only, SQLite has no pool to protect). New `isQueryTimeout` classifier in `@voltro/runtime` recognises a timeout cancel across dialects. Off by default (unset = no timeout — unchanged behaviour). `codemod: none` — a new opt-in env var / config field; no user-authored code is affected.
+- **@voltro/database, @voltro/cli** — Rolling-deploy safety classifier + `voltro db plan` advisory. A migration can be fully data-safe (every op auto-applies) and still break a zero-downtime rollout: during the overlap window old pods run the previous code against the already-migrated schema, so a dropped/renamed column, a narrowed type, or an added constraint makes those old pods 500 on reads or have their writes rejected. This is an axis ORTHOGONAL to the lossy/blocked data-safety gate — a `dropped()` column is blessed for data loss and still breaks an old reader.
+
+  `classifyRollingDeploySafety(op)` (a pure function in `@voltro/database`) returns a per-operation verdict with a reason + an expand/contract remedy; `voltro db plan` now lists the unsafe operations under a `⚠`, separately from the lossy/blocked summary. Advisory, NOT a refusal — the framework can't know the deploy strategy, and a maintenance-window / scale-to-zero deploy has no overlap window. The classifier is consumed by both the self-hosted advisory and (later) the cloud managed-hosting migration wall. Docs bless the expand/contract pattern. `codemod: none` — new API + CLI output only; no user-authored code is affected.
+- **@voltro/runtime** — Configurable graceful-shutdown deadline via `VOLTRO_SHUTDOWN_GRACE_MS` (milliseconds, clamped to 1s–5min, default 10s). After `SIGTERM`/`SIGINT` the runtime runs its finalizers (connection-pool close, plugin `onDeactivate`, analytics flush, trace persist) and then exits — but installing the signal handler removes node's default kill, so a finalizer that never completes would otherwise hang the process forever; the deadline caps that. Operators set it to sit just under their orchestrator's hard kill (k8s `terminationGracePeriodSeconds` minus the preStop sleep, ECS `stopTimeout`) so the app drains and exits cleanly on its own before SIGKILL truncates it mid-drain. A non-numeric / non-positive value falls back to the 10s default (never a `NaN` deadline that fires immediately). `codemod: none` — a new opt-in env var; no user-authored code is affected.
+- **@voltro/client, @voltro/runtime, @voltro/cli, @voltro/protocol** — WS-rpc mutation idempotency. A retried mutation carrying the same `idempotency-key` is deduplicated at the server: the first result is replayed and the handler does NOT run twice — so a network-blip retry, a reconnect resend, or (with a stable key) a double-click can't create a duplicate order / double charge. It reuses the same engine + `_voltro_idempotency` table as the REST path, so setting `idempotency` in `app.config.ts` now protects BOTH surfaces. `useMutation` / `useAction` mint a per-call key automatically and attach it to the rpc frame (over `RpcClient.currentHeaders`, merged with the auth headers) — pass `mutate(input, { idempotencyKey })` with a stable key for higher-level dedup. The key is scoped by `(tenant, subject, mutation)` so one subject's key can never replay for another, and the stored output is round-tripped through the mutation's output Schema so a `Date`-bearing replay reproduces the original exactly. Off by default (no `idempotency` config → no dedup). `@voltro/client` now peer-depends on `@effect/rpc` + `@effect/platform` (already transitive via `effect`).
+
+### Fixed
+
+- **@voltro/runtime, @voltro/cli** — **A `*.schedule.ts` or `*.subscribe.ts` body written as an Effect silently did nothing.** Not "was rejected" — ran, recorded a success, and never executed.
+
+  ```ts
+  export const handler: ScheduleHandler = () =>
+    Effect.gen(function* () { yield* reconcileInvoices() })   // never ran
+  ```
+
+  Both call sites accepted the value and dropped it. `scheduler.ts` did `await def.handler(ctx)`, and an Effect is not a thenable, so `await` returned it unchanged. `subscriberRunner.ts` tested `result instanceof Promise`, which an Effect is not, so the branch was skipped. Neither raised anything. In an Effect-first framework the natural thing to write was the thing that quietly did nothing — worse than a type error, because a type error is visible.
+
+  Both handler types now accept sync, Promise **and** Effect forms, and one shared `settleHandlerBody` decides what a body IS, so the two call sites can no longer disagree about it. They keep their different DISPOSAL, deliberately: a schedule AWAITS its body (a firing that failed must not record as a success), a subscriber does not (a slow body must not back-pressure the change stream).
+
+  Reported four releases ago. It sat because it was listed as "open" at the bottom of a feedback round and never entered the backlog — the register that now holds that tail is `plans/open/framework/consumer-reported-tail.md`.
+- **@voltro/plugin-auth** — **Brute-force lockout could be entirely inert, on by default, with nothing in the log to say so.** The postgres store fails OPEN on a store error — correct, a DB hiccup must not lock every user out of an app — but it failed open in silence: `recordLoginFailure` swallowed its write error, `isLockedOut` then read "not locked", and the security control that the release notes describe as **on by default** counted nothing at all.
+
+  The reachable case is not a hiccup. An app that enumerates its tables by hand instead of spreading `authTables` never migrates `loginAttempts`, so every write fails with `relation "loginAttempts" does not exist` — permanently, invisibly.
+
+  Behaviour is unchanged: still open, still no throw into the login flow. What is new is that each failure logs `[auth] lockout … failed — brute-force protection is not counting`, which also separates the two cases by hand: a transient error logs once, a missing table logs on every failed sign-in.
+
+  Found by the release gate, and the finding is uncomfortable in a useful way — the contract suite that runs against a LIVE postgres had been extended for lockout, and its hand-written fixture DDL was never given the new table. The fail-open then converted "relation does not exist" into a plain assertion failure, which is the only reason it was visible at all. The fixture now asserts that it covers every table the plugin declares, in both directions, and that assertion runs without postgres so the drift cannot be introduced on a machine where the pg half skips.
+- **@voltro/cli, @voltro/database** — **`voltro db apply` now installs the change triggers the boot diagnostic tells you to install.** It did not, and said it did.
+
+  0.23.0 added a check that compares declared reactivity against the triggers actually in the database, and it works — a consumer's first boot on 0.23.0 reported 500 of their 525 tables as having no change trigger. The remedy it named was `voltro db apply`, and `db apply` answered:
+
+  ```text
+  schema diff: 0 operations, 0 blocked
+    (schema is up to date)
+  db apply: schema is up to date — nothing to apply
+  ```
+
+  Both were telling the truth. Reactive triggers are emitted only by the two FULL-schema emitters — the CREATE-everything path for a fresh database, and the framework bootstrap — so every table an existing app has added through the PLANNER since it was created never got one. The planner has no trigger dimension to notice with, so `db plan` correctly reports zero operations while 500 tables sit untriggered. Their database had 27 triggers, all 27 on framework tables.
+
+  The consequence is the one the diagnostic describes: a single instance is unaffected (its own writes reach its own subscribers in-process), so this stays invisible until you scale out, and then subscriptions quietly stop seeing other instances' writes.
+
+  `db apply` and `db apply --plan` now converge triggers as an explicit, reported step — **including when the schema diff is empty**, which is not an edge case here but the reported one. It is deliberately NOT a planner operation: a trigger carries no data, its DDL is idempotent, and it is derived entirely from `isReactive`, so it converges rather than diffs.
+
+  **A second defect found while fixing the first: a custom `cdcChannel` made the check report every reactive table as missing.** The detector derived the trigger name itself (`framework_changes_<table>`) while the emitter puts the channel in the name on any non-default channel — two derivations of one name, disagreeing exactly where nobody looks. They read one function now.
+
+  Also: **`_voltro_schedule_claims` had no retention.** One row per (schedule, minute-bucket), append-only, and the only table of its family without a sweep — `_voltro_schedule_runs` (the OUTCOME of a firing) had one; its coordination twin (the RACE for the same firing) did not. Measured by the same consumer at 35,128 rows in 14 days across 31 schedules. Now pruned at 30 days by default (`VOLTRO_SCHEDULE_CLAIMS_TTL_HOURS`), which is safe because a claim only ever answers a question about one minute bucket and the scheduler asks about the current one.
+- **@voltro/cli, @voltro/database** — **`voltro serve` could not boot from its own bundle on any app with binlog CDC enabled**, and reported it as a build problem.
+
+  ```text
+  [voltro] serve bundle failed to load: n7 is not a constructor
+  [voltro] FATAL: production `voltro serve` requires a precompiled serve bundle …
+    Run `voltro build` before serving
+  ```
+
+  The bundle was neither missing nor unloadable. `@vlasky/zongji` — the binlog reader — sat on `NATIVE_RUNTIME_LEAVES`, the list of packages routed through a runtime CJS shim instead of being inlined, under a comment describing it as a leaf with "a compiled `.node` binding". It has none: it is a pure-JS ESM package. Through the shim its consumer broke, from the opposite direction to the `pg` regression the same list already documents — the shim's `module.exports` IS the ESM namespace `{ default: ctor }`, esbuild's `__toESM` wraps it again, and `(await import('@vlasky/zongji')).default` came back as the namespace object. Measured both ways:
+
+  ```text
+  shimmed:  typeof mod.default === 'object'   → `is not a constructor`
+  inlined:  typeof mod.default === 'function' → constructs
+  ```
+
+  Inlining it removes the shim's interop from the path. A new guard asserts the RULE rather than the list: every entry on `NATIVE_RUNTIME_LEAVES` must actually carry a compiled binding, or be one of the two documented dynamic-import cases.
+
+  **And the message that hid it is fixed.** The launcher wrapped the bundle's IMPORT and its RUN in one `try`, so every runtime fault the app's boot could raise came out as "serve bundle failed to load … Run `voltro build`", with the stack discarded. The reporter had just run it. The two are separated now: an import that throws is still a build problem, and an import that succeeds followed by a `runServe` throw is reported as itself, with its stack, and does not fall through to a second execution path.
+
+  **`voltro db files` ran a migration and could not record it, on MariaDB.** The file-migration writer passed an ISO-8601 string into `_voltro_migration_plans.appliedAt`, a `DATETIME`, which MariaDB rejects (`ER_TRUNCATED_WRONG_VALUE`). The INSERT runs AFTER `up()`, so the side effects landed and the bookkeeping did not: a probe migration inserting one row grew 1 → 2 → 3 → 4 across four invocations with zero `source='file'` ledger entries, and the deploy could never complete — `db apply` refuses while a file migration is pending and nothing could ever record it.
+
+  The PLANNER's writer had the conversion, inline, with a comment describing this exact rejection. The file writer was a second copy without it, so the common path worked and the escape hatch was broken exactly where it is reached for. One `appliedAtValue` now, shared, covered against a live MariaDB. A ledger write that fails after a successful `up()` also gets its own error type: the recovery is the opposite of the ordinary one — do NOT re-run — and it used to surface as a generic `Failed to execute statement`.
+
+  **`voltro build` never removed output from earlier builds.** Content-hashed chunks mean every build writes new names and nothing overwrites the old ones; nothing reads them either, so they accumulate and ship in the image. Measured by a consumer at 11,048 files where a clean build produces 2,131. Now pruned after the build, keyed on mtime — deliberately not a wipe before it, which opens a window in which the bundle does not exist.
+
+  **A completed drain now says so** (`drained in 80ms`), and one cut at the deadline says that instead. Previously the only trace of either was whatever a shutdown hook happened to log, so "drained in 80 ms" and "was cut at 10 s" looked identical.
+- **@voltro/runtime** — **A request the SSRF policy blocks is now a catchable failure instead of an uncatchable defect.**
+
+  It was `Effect.die(new SsrfBlockedError(...))`. A blocked outbound request is a decision the policy made about a URL the CALLER supplied — and as a defect the caller could not do anything about it: the fiber collapsed, it surfaced as an untagged 500, and a handler that wanted to fall back to a queue, return a typed error to the client, or skip an optional enrichment had no way to.
+
+  It rides inside `HttpClientError.RequestError` rather than being raised on its own, because `HttpClient.HttpClient`'s error channel IS `HttpClientError` — failing with a foreign type would not typecheck for any consumer. So `catchTag('RequestError')` and `catchAll` both see it, `description` names the policy, and the `SsrfBlockedError` survives as `cause` for a caller that wants the specific reason.
+
+  Not breaking: the error channel already carried `HttpClientError`. What changed is that the failure now arrives on it.
+
+  Reported three releases ago. It sat because it was listed as open at the bottom of a feedback round and never entered the backlog — see `plans/open/framework/consumer-reported-tail.md`.
+
+### Internal (no consumer-facing effect)
+
+- **@voltro/database** — `VOLTRO_SOFT_DROP=1` convergence is now proven against a live postgres, not argued.
+
+  The planner-side fix — treating `<name>__dropped_<YYYYMMDDHHMMSS>` as framework-managed so an undeclared snapshot is never re-proposed for dropping — shipped some releases ago. What never existed was the assertion, and a consumer had told us so: *"still not testable from a host without the DB"*. That was their constraint, read as ours. The docker stack is exactly what it needed.
+
+  The test soft-drops a COLUMN and a TABLE for real, asserts the data survives under the snapshot name, and asserts the **re-plan is EMPTY** — the property, not the statements. Verified red by disabling the planner's snapshot awareness: both cases then die in `applyPlan`'s convergence check, which is the original defect.
+
+  Two harness mistakes are recorded in the file because each produced a failure that reads exactly like the framework defect under test: an unscoped re-plan against a SHARED database proposes dropping every table in it, and a file-wide scope puts the first test's table into the second test's residue.
+
+---
+
 ## [0.23.0] — 2026-08-02
 
 ### ⚠ BREAKING

package/dist/index.d.ts

@@ -1404,6 +1404,31 @@ export declare interface ConnectionConfig {
      */
     readonly ssl?: boolean;
     readonly maxConnections?: number;
+    /**
+     * Per-statement timeout in ms — a runaway query (missing index, cartesian
+     * join) is aborted instead of holding a pooled connection forever, which under
+     * load exhausts the pool and stalls the whole app. Applied at the CONNECTION
+     * level so every query is bounded (no per-call opt-in). Env `DB_STATEMENT_TIMEOUT_MS`.
+     * Runtime-path only — the migration path (`voltro db apply`) deliberately does
+     * NOT read this, so a long backfill / index build is never cancelled by the app
+     * query ceiling.
+     *
+     * **Wired for postgres only** (the default dialect), enforced server-side via
+     * node-postgres' `statement_timeout` pool option — a runaway query is cancelled
+     * with SQLSTATE 57014, not merely disconnected. Every OTHER dialect currently
+     * ACCEPTS the field but IGNORES it, and the honest reasons differ:
+     *   - **mssql** — `@effect/sql-mssql` exposes only `connectTimeout` (connection
+     *     establishment), not tedious's per-request `requestTimeout`; mapping this
+     *     onto `connectTimeout` would bound the wrong phase, so it is left unwired
+     *     rather than wrong.
+     *   - **mysql/mariadb** — the server's `max_execution_time` bounds SELECTs only
+     *     (writes run unbounded), so a connection-level setting would be a partial,
+     *     misleading guarantee; not wired in V1.
+     *   - **sqlite** — in-process, one connection, no pool to exhaust; nothing to
+     *     protect.
+     * Unset (or any non-postgres dialect) = no timeout — behaviour is unchanged.
+     */
+    readonly statementTimeoutMs?: number;
     /**
      * Postgres only: the schema the app's tables live in, pinned as the
      * connection `search_path` (env `DB_SCHEMA`). When set, EVERY pooled

package/dist/sql.d.ts

@@ -190,6 +190,28 @@ export declare type BootMigrationOutcome = {
  *  producing a complete, non-overlapping partition of the table list. */
 export declare const chunkTables: <T>(xs: ReadonlyArray<T>, n: number) => T[][];
 
+/**
+ * Classify a single DDL operation for rolling-deploy safety.
+ *
+ * UNSAFE (breaks old code during the overlap window):
+ *   - `drop-column` / `drop-table` — old code reads it → error.
+ *   - `rename-column` / `rename-table` — to old code the old name vanished.
+ *   - `alter-column-type` — old reads may fail to decode, old writes may be
+ *     rejected by the new type; even a "widening" is risky to assume.
+ *   - `alter-column-nullability` → NOT NULL — old code that inserts without the
+ *     column (or with NULL) is now rejected.
+ *   - `add-unique` / `add-unique-composite` / `add-check` / `add-foreign-key`
+ *     — a constraint old writes may violate the instant it exists.
+ *
+ * SAFE (old code keeps working):
+ *   - `create-table` / `add-column` (nullable or defaulted) / `add-index` —
+ *     additive; old code doesn't see it.
+ *   - `drop-index` / `drop-unique*` / `drop-check` / `drop-foreign-key` —
+ *     removing enforcement never makes an old query ERROR.
+ *   - `alter-column-nullability` → nullable, `alter-column-default` — relaxing.
+ */
+export declare const classifyRollingDeploySafety: (op: MigrationOperation) => RollingDeploySafety;
+
 declare interface ColumnDefinition<TsType, Type extends ColumnType = ColumnType, HasDefault extends boolean = boolean> {
     readonly type: Type;
     readonly nullable: boolean;
@@ -712,10 +734,7 @@ declare type ColumnType = 'id' | 'text' | 'integer' | 'real' | 'decimal' | 'bigi
  */
 export declare const declaredSnapshot: (tables: ReadonlyArray<TableLike>, dialect?: DialectId) => SchemaSnapshot;
 
-/** The NOTIFY channel a schema emits on when none is configured. Exported so
- *  the store and the DDL cannot drift: they must agree, and before this they
- *  did not — the store read `options.cdcChannel` while the trigger hardcoded
- *  the default, so any custom channel listened to silence. */
+/** The NOTIFY channel a schema emits on when none is configured. */
 export declare const DEFAULT_CDC_CHANNEL = "framework_changes";
 
 /**
@@ -769,7 +788,11 @@ export declare const destructiveScope: (raw: string | undefined) => {
 export declare const detectReactiveTriggerDrift: (sql: SqlClient.SqlClient, tables: ReadonlyArray<{
     readonly tableName: string;
     readonly isReactive?: boolean;
-}>) => Effect.Effect<ReactiveTriggerDrift, SqlError_2>;
+}>, 
+/** The app's `cdcChannel`. Part of the trigger NAME on any non-default
+ *  channel, so omitting it here reported every table as missing on a database
+ *  where every trigger was present. */
+channel?: string) => Effect.Effect<ReactiveTriggerDrift, SqlError_2>;
 
 /** Dialect IDs the framework supports. */
 declare type DialectId = 'postgres' | 'mysql' | 'mariadb' | 'mssql' | 'sqlite' | 'turso';
@@ -938,6 +961,21 @@ export declare interface FileMigrationContext {
     readonly appliedAt: string;
 }
 
+/**
+ * A migration whose `up()` SUCCEEDED and whose ledger row could not be written.
+ *
+ * Its own error type because the recovery is the opposite of the ordinary one:
+ * do NOT re-run. The change has landed; what is missing is the record that says
+ * so, and every future invocation will apply it again until that row exists.
+ */
+export declare class FileMigrationLedgerError extends Error {
+    readonly migrationId: string;
+    readonly file: string;
+    readonly cause: unknown;
+    readonly _tag = "FileMigrationLedgerError";
+    constructor(migrationId: string, file: string, cause: unknown);
+}
+
 export declare interface FileMigrationRunResult {
     readonly applied: ReadonlyArray<{
         id: string;
@@ -1565,7 +1603,7 @@ export declare interface RawSqlFragment {
     readonly dependsOn?: ReadonlyArray<string>;
 }
 
-/** Prefix `reactiveTableTriggerSql` names its triggers with. */
+/** Prefix every reactive trigger name starts with, whatever the channel. */
 export declare const REACTIVE_TRIGGER_PREFIX = "framework_changes_";
 
 export declare interface ReactiveTriggerDrift {
@@ -1576,6 +1614,39 @@ export declare interface ReactiveTriggerDrift {
     readonly stale: ReadonlyArray<string>;
 }
 
+/**
+ * The statements that bring the DATABASE's change triggers back in line with
+ * what the schema declares.
+ *
+ * This exists because the diff could not do it and said it could. Reactive
+ * triggers are emitted only by the two full-schema emitters — the CREATE-
+ * everything path for a fresh database, and the framework bootstrap — so a
+ * table that arrived through the PLANNER (every table an existing app has
+ * added since it was created) never got one. The planner has no trigger
+ * dimension at all, so `db plan` reports 0 operations and `db apply` reports
+ * "schema is up to date" while the drift detector is simultaneously telling
+ * you 500 tables have no trigger, and pointing at `voltro db apply` as the
+ * remedy. Reported by a consumer with 525 tables and 27 triggers, all 27 on
+ * framework tables.
+ *
+ * A single instance is unaffected — its own writes reach its own subscribers
+ * through the in-process path — so this is invisible until you scale out, which
+ * is the worst possible time to find it.
+ *
+ * Postgres only: it is the one dialect where reactivity is carried by DDL. The
+ * binlog / Change Tracking readers are configured at runtime from the same
+ * in-memory table list, so they cannot drift from it.
+ */
+export declare const reactiveTriggerRepairSql: (input: {
+    readonly tables: ReadonlyArray<AnyTable>;
+    readonly dialect: DialectId;
+    /** Table names the detector found reactive-but-untriggered. */
+    readonly missing: ReadonlyArray<string>;
+    /** Table names the detector found triggered-but-declared-nonReactive. */
+    readonly stale: ReadonlyArray<string>;
+    readonly channel?: string;
+}) => ReadonlyArray<string>;
+
 export declare const releaseMigrationLock: (sql: SqlClient.SqlClient) => Effect.Effect<void, SqlError_2>;
 
 export declare const renderColumnMysql: (col: ColumnSnapshot) => string;
@@ -1600,6 +1671,27 @@ export declare const rollbackFileBasedMigration: (sql: SqlClient.SqlClient, ctx:
     durationMs: number;
 }, unknown>;
 
+/** Verdict for one operation under a rolling deploy. */
+export declare type RollingDeploySafety = {
+    readonly safe: true;
+} | {
+    readonly safe: false;
+    /** Why an instance on the OLD code breaks against the new schema. */
+    readonly reason: string;
+    /** The expand/contract move that keeps both code versions working. */
+    readonly remedy: string;
+};
+
+/**
+ * The rolling-deploy-unsafe operations in a plan, each paired with its verdict.
+ * Empty ⇒ the whole plan is safe to apply while an old deploy is still live.
+ */
+export declare const rollingDeployUnsafeOps: (operations: ReadonlyArray<PlannedOperation>) => ReadonlyArray<{
+    readonly op: PlannedOperation;
+    readonly reason: string;
+    readonly remedy: string;
+}>;
+
 export declare const runFileBasedMigrations: (sql: SqlClient.SqlClient, ctx: RunFileBasedMigrationsCtx) => Effect.Effect<FileMigrationRunResult, unknown>;
 
 export declare interface RunFileBasedMigrationsCtx {