/**
 * Boot-gate version comparison with expand-only rollback tolerance.
 *
 * The schema-version gates (`verifyExpectedSchemaVersion` for Postgres,
 * `verifyExpectedClickHouseSchemaVersion` for ClickHouse) both decide whether a
 * booting image's EXPECTED schema version is SATISFIED by what the database has
 * APPLIED. Both route their `matches` verdict through here so the two gates can
 * never drift (Code Quality § "Coupled values: shared source at 2 occurrences").
 *
 * The tolerance exists because expand/contract migrations make an old image safe
 * against a newer schema: rolling the image back without rolling the DB back is
 * the intended expand-only rollback, and a strict-equality gate defeated it by
 * refusing to boot. See the migration-safety pattern.
 */
/**
 * True when `version` is a monotonically-ordered migration identifier whose
 * lexicographic order equals its chronological/sequence order — a Prisma
 * migration name (`20260706120000_add_users`, fixed-width timestamp) or a
 * ClickHouse migration filename (`011-issue-brief-citations.sql`, zero-padded
 * numeric prefix). Both are selected as "latest" by `.sort()` at synth time
 * (`pickLatest*Migration`) and apply time (the runner), so lexicographic
 * comparison here mirrors that selection exactly.
 *
 * Returns false for the non-orderable audit fields — `_schema_migrations.version`
 * (sha256 content hash) and `prisma_version` (the constant marker `"applied"`) —
 * so the caller fails closed on exact identity for those.
 */
export declare function isOrderableSchemaVersion(version: string): boolean;
/**
 * Whether the `expected` schema version baked into the image is satisfied by the
 * `actual` version applied to the database.
 *
 * When BOTH are orderable migration identifiers, the DB may sit AT or AHEAD of
 * the image's expectation — an old image booting against a newer expand-only
 * schema is safe, so `actual >= expected` passes. The forward direction
 * (`actual < expected`, new code against an older schema) still fails: the
 * columns/tables the image needs may not exist yet.
 *
 * When EITHER is non-orderable (content hash, constant marker), there is no
 * defined newer/older, so it falls back to strict identity — fail-closed,
 * byte-identical to the pre-tolerance behaviour.
 *
 * The `>=` is lexicographic, which equals sequence order only when both
 * versions share an equal-width numeric prefix (Prisma's fixed 14-digit
 * timestamp always does; a ClickHouse `NNN-…` filename only if authored
 * zero-padded). If the widths differ — or a `.sql` name carries no numeric
 * prefix at all — lexicographic order cannot be trusted, so it also falls back
 * to strict identity (fail-closed) rather than return a possibly-inverted `>=`.
 */
export declare function isSchemaVersionSatisfied(expected: string, actual: string): boolean;