/**
 * @fileoverview Migration v17 — widen the `trust_tier` CHECK to allow `'curated'`
 * @see SMI-4917: First-time-install bug fixes
 *
 * The skill registry ships skills with `trust_tier = 'curated'` (introduced in
 * SMI-2381 — third-party publishers manually opted in). The canonical `TrustTier`
 * type and the API/Zod schema accept `'curated'`, but the SQLite CHECK constraint
 * on the `skills` table omitted it (`schema-sql.ts`, `v16-skill-source.ts` allowed
 * only `verified, community, experimental, unknown, local`). Every `'curated'` row
 * therefore failed on insert, so `sync` silently dropped every curated skill.
 *
 * SQLite cannot ALTER an existing CHECK constraint in place — the table is
 * recreated using the standard create/copy/drop/rename dance, all wrapped in a
 * transaction so a mid-process kill leaves either the old shape or the new shape,
 * never a half-applied state. This mirrors `applyMigrationV16` exactly; the column
 * set, indexes, and FTS5 triggers are copied verbatim from v16 (v17 changes only
 * the `trust_tier` CHECK list — no column added, no column dropped).
 *
 * R1 (FK inbound refs): with `foreign_keys=ON` (the driver default), `DROP TABLE
 * skills` fires every inbound `ON DELETE CASCADE` action *immediately* — SQLite
 * does NOT defer cascade actions to the end of the transaction. Today
 * `skill_categories` (`schema-sql.ts:96-100`) is the only child with a hard FK
 * `skill_id ... REFERENCES skills(id) ON DELETE CASCADE`; its rows would be
 * silently cascade-deleted by the recreate (SMI-4919). The recreate therefore
 * backs `skill_categories` up into a TEMP table before `DROP TABLE skills` and
 * restores it verbatim after the RENAME, all inside the one `BEGIN; ... COMMIT;`.
 * (`skill_versions`, `skill_advisories`, `skill_co_installs`,
 * `skill_dependencies`, `risk_score_history` use soft `skill_id TEXT` columns
 * with no FK — they are unaffected.) RULE: any future `skills` table-recreate
 * MUST back up every `ON DELETE CASCADE` child of `skills` the same way (today
 * `skill_categories` is the only one — re-check `schema-sql.ts` before changing
 * this dance).
 *
 * Idempotent: v17 adds no column, so the probe inspects the CHECK text itself —
 * if the `skills` DDL already contains `'curated'`, the migration is a no-op.
 * Re-running on a v17+ DB (or a fresh install, whose base `SCHEMA_SQL` already
 * includes `'curated'`) short-circuits. The duplicate-column guard in
 * `runMigrations` / `runMigrationsSafe` does not apply here (no column change),
 * so the probe is the sole idempotency mechanism — it is load-bearing.
 */
import type { Database } from '../database-interface.js';
/**
 * Apply the v17 migration if not already present.
 *
 * Exported as a function rather than a SQL string because the table-recreation
 * dance must short-circuit on an already-widened DB. v17 adds no column, so the
 * probe inspects the `skills` table DDL for the `'curated'` literal — if present,
 * the constraint is already widened (fresh install or v17 already applied) and
 * the migration is a no-op.
 */
export declare function applyMigrationV17(db: Database): void;
//# sourceMappingURL=v17-curated-trust-tier.d.ts.map