/**
 * Migration Runner
 *
 * Extracted from schema.ts (SMI-3910) to keep schema.ts focused on
 * schema definition and database creation.
 *
 * Handles running pending migrations against the database, with
 * graceful handling of duplicate-column errors from migrations that
 * add columns already present in the initial schema.
 *
 * IMPORTANT: Uses db.exec(migration.sql) directly instead of splitting
 * by semicolon. Splitting breaks trigger bodies (e.g., FTS5 sync triggers).
 * See MEMORY.md "SCHEMA_SQL semicolon-split trap".
 */
import type { Database } from './database-interface.js';
/**
 * Migration definition for schema upgrades.
 *
 * A migration carries either a literal `sql` string OR an imperative `apply`
 * function for cases where the change cannot be expressed as a single
 * idempotent SQL blob (e.g. SMI-4665 v16 — SQLite cannot ALTER an existing
 * CHECK constraint, so the table must be recreated, but only when the column
 * is actually missing).
 */
export interface Migration {
    version: number;
    description: string;
    sql?: string;
    apply?: (db: Database) => void;
}
export declare const MIGRATIONS: Migration[];
/**
 * Get the current schema version from the database
 */
export declare function getSchemaVersion(db: Database): number;
/**
 * Run pending migrations to upgrade the schema.
 *
 * Uses db.exec(migration.sql) directly — never splits by semicolon,
 * which would break trigger bodies. Duplicate-column errors are caught
 * at the full-SQL level.
 */
export declare function runMigrations(db: Database): number;
/**
 * SMI-974: Run migrations with error handling for existing columns.
 *
 * Like runMigrations but wraps each migration in try/catch so a single
 * failure doesn't prevent subsequent migrations from running.
 */
export declare function runMigrationsSafe(db: Database): number;
//# sourceMappingURL=migration-runner.d.ts.map