/** * @fileoverview Migration v16 — add `source` column + extend `trust_tier` CHECK * @see SMI-4665: Filesystem-walking SKILL.md import command * * Adds two changes to the `skills` table: * * 1. `source TEXT NOT NULL DEFAULT 'registry' CHECK (source IN ('registry', 'local'))` * — distinguishes registry-synced rows from filesystem-imported rows so * `sync --force` can refuse to clobber locally-imported skills. * * NOTE: Migration v2 (SMI-974) added a free-form `source TEXT` column that * held values like `'github'` for Phase-5 imports. The v16 recreation * coerces any non-`'local'` legacy value to `'registry'` so the new CHECK * constraint accepts existing rows. The semantic shift is intentional — * callers that need the original import-source string can rely on * `repo_url` (always set for github-sourced rows). See SMI-4665 retro. * * 2. Extend the `trust_tier` CHECK to allow `'local'`. Existing values: * `verified`, `community`, `experimental`, `unknown`. Local skills * surface as a distinct tier in search output instead of being indistinguishable * from unscanned registry imports under `'unknown'`. * * SQLite cannot ALTER an existing CHECK constraint in place — the table is * recreated using the standard rename/copy/drop 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. * * Idempotent: short-circuits when the `source` column already exists. Re-running * the migration on a v16+ DB is a no-op. The duplicate-column guard in * `runMigrations` / `runMigrationsSafe` adds defense-in-depth. */ import type { Database } from '../database-interface.js'; /** * Apply the v16 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-migrated DB (the canonical schema * already includes `source` for fresh installs). */ export declare function applyMigrationV16(db: Database): void; //# sourceMappingURL=v16-skill-source.d.ts.map