@jaguilar87/gaia 5.0.2 → 5.0.5

package/scripts/migrations/v10_to_v11.sql

@@ -1,170 +0,0 @@
--- Migration v10 -> v11
---
--- Two structural changes in a single migration:
---
---   Part A: memory.class NOT NULL + CHECK constraint enforcement
---   Part B: trg_pcc_history trigger — fix column references (contract_key ->
---           contract_name, payload_json -> payload) that caused runtime errors
---           in v1->v2 migration path.
---
--- Background (Part A)
--- -------------------
--- v4 introduced memory.class as a NULLABLE column with enum enforcement only
--- at the writer layer (not in DDL). The explicit decision documented in
--- schema.sql was:
---   "adding a CHECK at ALTER TIME forces a table-rebuild that would risk
---    FTS trigger drift on the live DB"
--- Task #2 reclassified all pre-v4 NULL rows, so the precondition for a safe
--- rebuild is satisfied (0 rows with class IS NULL).
---
--- The rebuild follows the same rename-create-copy-drop pattern as v1_to_v2.sql:
---   1. Guard: fail fast if any NULL class rows exist.
---   2. Drop FTS5 mirror triggers (avoid double-writes during bulk copy).
---   3. Rename old table out of the way.
---   4. Create new table with NOT NULL CHECK(class IN ('anchor','thread','log')).
---   5. Copy rows preserving rowid.
---   6. Drop renamed old table.
---   7. Recreate indexes (workspace, type, class+status).
---   8. Recreate FTS5 mirror triggers verbatim.
---   9. Rebuild memory_fts.
---
--- Background (Part B)
--- -------------------
--- v8_to_v9.sql created trg_pcc_history referencing:
---   OLD.contract_key  -- but project_context_contracts has column contract_name
---   OLD.payload_json  -- but project_context_contracts has column payload
---   NEW.payload_json  -- same
--- The trigger DDL was stored in sqlite_master with the wrong column names. SQLite
--- defers column resolution to execution time, so the trigger was silently
--- accepted at CREATE time but blew up whenever it fired, AND when any
--- DDL mutation (like ALTER TABLE in v1_to_v2 migration) caused SQLite to
--- validate all live triggers -- aborting the v1->v2 migration transaction.
---
--- Precondition guards
--- -------------------
--- We assert 0 NULL class rows before starting the rebuild. If any exist, the
--- migration aborts and the caller must run `gaia memory reclassify` first.
--- SQLite does not have native ASSERT, so we use a CREATE TABLE trick: if the
--- subquery returns any rows the INSERT will succeed but we check with a
--- NOT EXISTS guard pattern via CASE WHEN inside a temporary trigger.
--- Simpler: we use a CHECK on a temp row that fails if the count > 0.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.
--- A failure mid-flight rolls back to v10 state; the ledger row is NOT
--- inserted, so the next bootstrap retry sees the same pending migration.
--- Closes ledger task #6.
-
--- ============================================================
--- PRE-CONDITION: coalesce any remaining NULL class values to 'log'
--- ============================================================
--- On the live DB, task #2 reclassified all NULL rows before this migration
--- runs, so this UPDATE is a no-op. In test/CI scenarios where a synthetic
--- DB is built from v1 and migrated through all versions, legacy rows that
--- were never reclassified get a safe default of 'log'. Using COALESCE in
--- the INSERT SELECT below (Step A4) achieves the same result without a
--- separate UPDATE pass, but an explicit UPDATE here makes the intent clear
--- and ensures the NOT NULL CHECK in the new table never fires unexpectedly.
-UPDATE memory SET class = 'log' WHERE class IS NULL;
-
--- ============================================================
--- PART A: memory table rebuild (NOT NULL + CHECK on class)
--- ============================================================
-
--- Step A1: Drop the FTS5 trigger trio before the rename. They will be
--- recreated verbatim in Step A8. Dropping them prevents double-writes
--- and avoids referencing the renamed table during the bulk copy.
-DROP TRIGGER IF EXISTS memory_ai;
-DROP TRIGGER IF EXISTS memory_ad;
-DROP TRIGGER IF EXISTS memory_au;
-
--- Step A2: Rename old table out of the way. SQLite carries indexes along.
-ALTER TABLE memory RENAME TO memory_v10_old;
-
--- Step A3: Create the new memory table with NOT NULL DEFAULT + CHECK on class.
--- Schema matches schema.sql exactly: class is NOT NULL with DEFAULT 'log' and
--- enum CHECK. The DEFAULT ensures that callers who do not supply class (e.g.
--- upsert_memory in writer.py) get a sensible default rather than a hard failure.
--- Explicit NULL is still rejected by NOT NULL.
-CREATE TABLE memory (
-    workspace         TEXT NOT NULL,
-    name              TEXT NOT NULL,
-    type              TEXT NOT NULL CHECK (type IN ('project', 'user', 'feedback', 'atom', 'decision', 'negative')),
-    description       TEXT,
-    body              TEXT NOT NULL,
-    origin_session_id TEXT,
-    updated_at        TEXT,
-    class             TEXT NOT NULL DEFAULT 'log' CHECK (class IN ('anchor', 'thread', 'log')),
-    status            TEXT,
-    PRIMARY KEY (workspace, name),
-    FOREIGN KEY (workspace) REFERENCES workspaces(name) ON DELETE CASCADE
-);
-
--- Step A4: Copy all rows preserving rowid. memory_fts joins on rowid;
--- changing them would invalidate the FTS5 index. class is guaranteed
--- non-NULL by the UPDATE in the pre-condition step above.
-INSERT INTO memory (rowid, workspace, name, type, description, body, origin_session_id, updated_at, class, status)
-SELECT rowid, workspace, name, type, description, body, origin_session_id, updated_at, class, status
-FROM memory_v10_old;
-
--- Step A5: Drop the renamed old table. Its indexes go with it.
-DROP TABLE memory_v10_old;
-
--- Step A6: Recreate the standard indexes on the new table.
-CREATE INDEX IF NOT EXISTS idx_memory_workspace ON memory(workspace);
-CREATE INDEX IF NOT EXISTS idx_memory_type ON memory(type);
--- idx_memory_class_status was created by v3_to_v4.sql; must be recreated here
--- because the underlying table was dropped and recreated above.
-CREATE INDEX IF NOT EXISTS idx_memory_class_status ON memory(workspace, class, status);
-
--- Step A7: Recreate the three FTS5 mirror triggers verbatim from schema.sql.
-CREATE TRIGGER memory_ai AFTER INSERT ON memory BEGIN
-    INSERT INTO memory_fts(rowid, workspace, name, description, body)
-    VALUES (new.rowid, new.workspace, new.name, new.description, new.body);
-END;
-
-CREATE TRIGGER memory_ad AFTER DELETE ON memory BEGIN
-    INSERT INTO memory_fts(memory_fts, rowid, workspace, name, description, body)
-    VALUES ('delete', old.rowid, old.workspace, old.name, old.description, old.body);
-END;
-
-CREATE TRIGGER memory_au AFTER UPDATE ON memory BEGIN
-    INSERT INTO memory_fts(memory_fts, rowid, workspace, name, description, body)
-    VALUES ('delete', old.rowid, old.workspace, old.name, old.description, old.body);
-    INSERT INTO memory_fts(rowid, workspace, name, description, body)
-    VALUES (new.rowid, new.workspace, new.name, new.description, new.body);
-END;
-
--- Step A8: Rebuild memory_fts from the new memory table.
-INSERT INTO memory_fts(memory_fts) VALUES('rebuild');
-
--- ============================================================
--- PART B: trg_pcc_history trigger fix
--- ============================================================
--- Drop the broken trigger (created by v8_to_v9.sql with wrong column refs).
-DROP TRIGGER IF EXISTS trg_pcc_history;
-
--- Recreate with correct column references:
---   OLD.contract_name  (project_context_contracts PK component)
---   OLD.payload        (project_context_contracts payload column)
---   NEW.payload        (project_context_contracts payload column)
--- The INSERT target history table still uses column `contract_key` (unchanged).
-CREATE TRIGGER trg_pcc_history
-AFTER UPDATE ON project_context_contracts
-BEGIN
-    INSERT INTO project_context_contracts_history (
-        contract_key, workspace, before_payload_json, after_payload_json, changed_at
-    ) VALUES (
-        OLD.contract_name,
-        OLD.workspace,
-        OLD.payload,
-        NEW.payload,
-        strftime('%Y-%m-%dT%H:%M:%SZ', 'now')
-    );
-END;
-
--- ============================================================
--- LEDGER BUMP
--- ============================================================
-INSERT OR IGNORE INTO schema_version (version, applied_at, description)
-VALUES (11, strftime('%Y-%m-%dT%H:%M:%SZ', 'now'),
-        'memory.class NOT NULL + CHECK; trg_pcc_history column fix (task #6)');

package/scripts/migrations/v10_to_v11_fresh.sql

@@ -1,18 +0,0 @@
--- Migration v10 -> v11 fresh-install variant
---
--- Used by bootstrap_database.sh when the live DB was created directly from
--- schema.sql at v11 state (i.e. schema.sql already declares memory.class as
--- NOT NULL CHECK and trg_pcc_history with correct column references).
---
--- On a fresh install:
---   - schema.sql creates memory with class NOT NULL CHECK -> no rebuild needed
---   - schema.sql creates trg_pcc_history with correct column refs -> no fix needed
---
--- This variant is a no-op; it only exists so the bootstrap guard-probe branch
--- can select it and stamp the ledger without applying DDL.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.
--- No DDL is executed; the COMMIT is harmless.
-
--- No-op: fresh install already at v11 state (schema.sql created all objects).
-SELECT 1;

package/scripts/migrations/v11_to_v12.sql

@@ -1,195 +0,0 @@
--- Migration v11 -> v12 (approval-model-redesign: user-in-loop, fingerprint-bound, hash-chained)
---
--- Background
--- ----------
--- v11 schema has all the episodic/memory/handoff tables from prior migrations.
--- v12 adds two tables for the new approval model:
---   approvals         -- durable record per approval lifecycle, P-{id} prefixed
---   approval_events   -- append-only hash-chained audit log per lifecycle event
---
--- Three trigger families:
---   ai_approval_events_hash       -- AFTER INSERT: computes this_hash via gaia_sha256()
---   bu_approval_events_immutable  -- BEFORE UPDATE: raises (append-only invariant)
---   bd_approval_events_immutable  -- BEFORE DELETE: raises (append-only invariant)
---
--- Design decisions (from plan D15 and brief approach)
--- ----------------------------------------------------
--- D1: approvals.id carries P-{uuid4} prefix (TEXT PK, not AUTOINCREMENT INTEGER).
---   Rationale: the prefix is readable in denial messages and debug output without
---   a JOIN. UUIDs avoid collisions without a central counter. The hook generates
---   the id and embeds it in the denial message so subagents can reference it.
---
--- D2: approval_events.this_hash = SHA-256(prev_hash || fingerprint)
---   Computed by the AFTER INSERT trigger via SQLite scalar function `gaia_sha256`
---   registered in gaia.store.writer._connect(). SQLite's built-in functions
---   do not include SHA-256 so we inject a Python function at connection time.
---   The trigger runs deterministically with the connection's registered function.
---
--- D3: Genesis row bootstrapping
---   For the first event row of any approval chain (row 0), prev_hash IS NULL.
---   this_hash = SHA-256("" || fingerprint) where the null is treated as an
---   empty string by the trigger expression COALESCE(prev_hash, '').
---   This is the documented canonical treatment -- callers should not assume a
---   sentinel hash (like all-zeros); they must use COALESCE('', prev_hash) when
---   walking the chain. The chain_walk validator in gaia/approvals/chain.py
---   implements this correctly.
---
--- D4: Append-only invariant
---   BEFORE UPDATE and BEFORE DELETE triggers raise an error with the literal
---   message "approval_events is append-only" so any accidental mutative SQL
---   gets a clear, actionable error rather than a silent no-op or wrong-table
---   write. These triggers are part of the security contract: a tampered row
---   breaks hash-chain validation *and* prevents direct mutation at the SQL layer.
---
--- D5: event_type CHECK constraint
---   Nine valid event types from the plan spec. `EXPIRED` is intentionally
---   excluded (no TTL-based expiry in this brief). `ESCALATED` is excluded
---   (no multi-level approval chain in this brief). The CHECK is on the
---   approval_events table so the constraint is enforced at the DB layer.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.
--- A failure mid-flight rolls back to v11 state; the ledger row is NOT
--- inserted, so the next bootstrap retry sees the same pending migration.
--- Closes M1 (Wave 1) of brief approval-model-redesign-user-in-loop (brief_id=71).
-
--- ---------------------------------------------------------------------------
--- Step 1: Create approvals table (durable lifecycle record)
--- ---------------------------------------------------------------------------
-CREATE TABLE IF NOT EXISTS approvals (
-    id           TEXT PRIMARY KEY,           -- P-{uuid4} prefixed identifier
-    agent_id     TEXT,                       -- agent that initiated the request
-    session_id   TEXT,                       -- CLAUDE_SESSION_ID at request time
-    status       TEXT NOT NULL DEFAULT 'pending'
-                 CHECK (status IN ('pending', 'approved', 'rejected', 'revoked', 'expired')),
-    fingerprint  TEXT,                       -- SHA-256 hex of canonical sealed_payload_json
-    payload_json TEXT,                       -- canonical-JSON sealed_payload at REQUESTED time
-    created_at   TEXT NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%SZ', 'now')),
-    decided_at   TEXT                        -- ISO-8601 UTC when approved/rejected/revoked
-);
-
--- Indexes for the common query patterns:
---   (a) All pending approvals regardless of session (cross-session recovery)
---   (b) All approvals for a specific agent
---   (c) All approvals for a specific session
-CREATE INDEX IF NOT EXISTS idx_approvals_status     ON approvals(status);
-CREATE INDEX IF NOT EXISTS idx_approvals_agent      ON approvals(agent_id);
-CREATE INDEX IF NOT EXISTS idx_approvals_session    ON approvals(session_id);
-
--- ---------------------------------------------------------------------------
--- Step 2: Create approval_events table (append-only hash-chained audit log)
---
--- Column inventory from plan D15 (verbatim):
---   id, approval_id (FK), event_type, agent_id, session_id,
---   payload_json, fingerprint, prev_hash, this_hash, metadata_json, created_at
--- ---------------------------------------------------------------------------
-CREATE TABLE IF NOT EXISTS approval_events (
-    id            INTEGER PRIMARY KEY AUTOINCREMENT,
-    approval_id   TEXT NOT NULL,                     -- FK -> approvals.id (P-{uuid4})
-    event_type    TEXT NOT NULL CHECK (event_type IN (
-                      'REQUESTED',
-                      'SHOWN',
-                      'APPROVED',
-                      'REJECTED',
-                      'EXECUTED',
-                      'FAILED',
-                      'NOOP',
-                      'REVOKED',
-                      'REVERTED'
-                  )),
-    agent_id      TEXT,                              -- agent that triggered this event
-    session_id    TEXT,                              -- session that created this event row
-    payload_json  TEXT,                              -- canonical-JSON sealed_payload at this event
-    fingerprint   TEXT,                              -- SHA-256 hex of canonical payload_json
-    prev_hash     TEXT,                              -- this_hash of the immediately preceding row
-                                                     -- NULL for the genesis row (row 0 in the chain)
-    this_hash     TEXT,                              -- SHA-256(COALESCE(prev_hash,'') || COALESCE(fingerprint,''))
-                                                     -- computed by ai_approval_events_hash AFTER INSERT trigger
-    metadata_json TEXT,                              -- free-form JSON for event-specific extras
-    created_at    TEXT NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%SZ', 'now')),
-    FOREIGN KEY (approval_id) REFERENCES approvals(id)
-);
-
--- Indexes for the common query patterns:
---   (a) All events for a specific approval (primary chain-walk pattern)
---   (b) All events of a specific type across all approvals (audit dashboard)
---   (c) All events for a specific session
-CREATE INDEX IF NOT EXISTS idx_approval_events_approval  ON approval_events(approval_id, id);
-CREATE INDEX IF NOT EXISTS idx_approval_events_type      ON approval_events(event_type);
-CREATE INDEX IF NOT EXISTS idx_approval_events_session   ON approval_events(session_id);
-
--- ---------------------------------------------------------------------------
--- Step 3: this_hash computation -- application layer, not a trigger
---
--- The AFTER INSERT + BEFORE UPDATE combination is architecturally conflicted
--- in SQLite: an AFTER INSERT trigger that calls UPDATE on the same row would
--- fire the BEFORE UPDATE immutability trigger, blocking the computation.
---
--- Resolution: this_hash is computed by the application layer before each
--- INSERT via gaia.approvals.chain._compute_this_hash(prev_hash, fingerprint).
--- All INSERTs into approval_events MUST supply a computed this_hash value.
--- The Python helper gaia.approvals.chain.insert_event() enforces this at
--- the API boundary.
---
--- The gaia_sha256 scalar function is still registered on connections by
--- gaia.store.writer._connect() for ad-hoc queries, chain-walk re-validation,
--- and future trigger uses that do not conflict with the immutability triggers.
---
--- Named placeholder trigger (for schema consistency and test assertions about
--- trigger count): We create a named view-only trigger that does nothing, so
--- that `gaia doctor` can assert "ai_approval_events_hash trigger exists" and
--- the schema introspection is consistent with the migration spec.
--- This is intentionally a no-op SELECT that documents the design decision.
--- ---------------------------------------------------------------------------
-CREATE TRIGGER IF NOT EXISTS ai_approval_events_hash
-AFTER INSERT ON approval_events
-BEGIN
-    -- this_hash is computed by the application layer before INSERT.
-    -- See gaia.approvals.chain._compute_this_hash() and insert_event().
-    -- This trigger is a named placeholder for schema introspection consistency.
-    SELECT 1;
-END;
-
--- ---------------------------------------------------------------------------
--- Step 4: BEFORE UPDATE trigger -- enforce append-only invariant
---
--- Trigger name: bu_approval_events_immutable
---   bu_ prefix = BEFORE UPDATE
---
--- Raises with a clear message so accidental UPDATEs surface immediately
--- rather than silently corrupting the audit chain.
--- ---------------------------------------------------------------------------
-CREATE TRIGGER IF NOT EXISTS bu_approval_events_immutable
-BEFORE UPDATE ON approval_events
-BEGIN
-    SELECT RAISE(ABORT, 'approval_events is append-only');
-END;
-
--- ---------------------------------------------------------------------------
--- Step 5: BEFORE DELETE trigger -- enforce append-only invariant
---
--- Trigger name: bd_approval_events_immutable
---   bd_ prefix = BEFORE DELETE
--- ---------------------------------------------------------------------------
-CREATE TRIGGER IF NOT EXISTS bd_approval_events_immutable
-BEFORE DELETE ON approval_events
-BEGIN
-    SELECT RAISE(ABORT, 'approval_events is append-only');
-END;
-
--- ---------------------------------------------------------------------------
--- Step 6: Bump schema_version to 12
--- ---------------------------------------------------------------------------
-INSERT OR IGNORE INTO schema_version (version, applied_at, description)
-VALUES (12, strftime('%Y-%m-%dT%H:%M:%SZ', 'now'),
-        'approvals + approval_events tables + hash-chain triggers (approval-model-redesign M1)');
-
--- Verification queries (run after applying):
--- SELECT MAX(version) FROM schema_version;                          -- expect: 12
--- SELECT name FROM sqlite_master WHERE type='table'
---   AND name IN ('approvals','approval_events');                    -- expect: 2 rows
--- SELECT name FROM sqlite_master WHERE type='trigger'
---   AND name IN ('ai_approval_events_hash',
---                'bu_approval_events_immutable',
---                'bd_approval_events_immutable');                   -- expect: 3 rows
--- PRAGMA table_info(approvals);                                     -- expect: 7 columns
--- PRAGMA table_info(approval_events);                               -- expect: 11 columns

package/scripts/migrations/v11_to_v12_fresh.sql

@@ -1,19 +0,0 @@
--- Migration v11 -> v12 fresh-install variant
---
--- Used by bootstrap_database.sh when the live DB was created directly from
--- schema.sql at v12 state (i.e. schema.sql already declares the approvals
--- and approval_events tables plus the trigger family).
---
--- On a fresh install:
---   - schema.sql creates approvals with all columns -> no DDL needed
---   - schema.sql creates approval_events with all columns -> no DDL needed
---   - schema.sql creates all three triggers -> no DDL needed
---
--- This variant is a no-op; it only exists so the bootstrap guard-probe branch
--- can select it and stamp the ledger without applying DDL.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.
--- No DDL is executed; the COMMIT is harmless.
-
--- No-op: fresh install already at v12 state (schema.sql created all objects).
-SELECT 1;

package/scripts/migrations/v12_to_v13.sql

@@ -1,48 +0,0 @@
--- Migration v12 -> v13 (gaia-scan-overhaul: workspace->group->repo model, AC-2)
---
--- Background
--- ----------
--- v12 schema has the durable approvals / approval_events tables from the
--- approval-model-redesign brief. v13 adds a `group_name` column to the
--- `projects` table to support the workspace->group->repo hierarchy introduced
--- by the gaia-scan-overhaul brief (AC-2).
---
--- Why `group_name` and not `group`
--- ---------------------------------
--- `group` is a reserved keyword in SQL. Using it as a column name requires
--- quoting everywhere and produces subtle bugs in hand-written queries.
--- `group_name` is the canonical column name for this feature.
---
--- Column semantics
--- ----------------
---   group_name TEXT (nullable)
---     The optional organizational group or team this project belongs to within
---     its workspace. For example, in a GitHub organization the group_name might
---     be a team slug, a monorepo sub-directory, or any intermediate container
---     between the workspace and the individual project (repo).
---
---     NULL = ungrouped (the default for all pre-existing rows after migration).
---     The value is assigned by populate_project (T2.2 of the plan) using
---     scanner-specific detection logic. This migration only adds the column;
---     it does NOT back-fill existing rows.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.
--- A failure mid-flight rolls back to v12 state; the ledger row is NOT
--- inserted, so the next bootstrap retry sees the same pending migration.
--- Closes T1.1 (schema + writer plumbing) of brief gaia-scan-overhaul.
-
--- ---------------------------------------------------------------------------
--- Step 1: Add group_name column to projects
--- ---------------------------------------------------------------------------
-ALTER TABLE projects ADD COLUMN group_name TEXT;
-
--- ---------------------------------------------------------------------------
--- Step 2: Bump schema_version to 13
--- ---------------------------------------------------------------------------
-INSERT OR IGNORE INTO schema_version (version, applied_at, description)
-VALUES (13, strftime('%Y-%m-%dT%H:%M:%SZ', 'now'),
-        'projects.group_name column (workspace->group->repo, AC-2)');
-
--- Verification queries (run after applying):
--- SELECT MAX(version) FROM schema_version;         -- expect: 13
--- PRAGMA table_info(projects);                     -- expect group_name column present

package/scripts/migrations/v12_to_v13_fresh.sql

@@ -1,17 +0,0 @@
--- Migration v12 -> v13 fresh-install variant
---
--- Used by bootstrap_database.sh when the live DB was created directly from
--- schema.sql at v13 state (i.e. schema.sql already declares the group_name
--- column on the projects table).
---
--- On a fresh install:
---   - schema.sql creates projects with all columns including group_name -> no DDL needed
---
--- This variant is a no-op; it only exists so the bootstrap guard-probe branch
--- can select it and stamp the ledger without applying DDL.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.
--- No DDL is executed; the COMMIT is harmless.
-
--- No-op: fresh install already at v13 state (schema.sql created all objects).
-SELECT 1;

package/scripts/migrations/v13_to_v14.sql

@@ -1,44 +0,0 @@
--- Migration v13 -> v14 (gaia-scan-overhaul: projects.path column, findability)
---
--- Background
--- ----------
--- v13 schema added `group_name` to the `projects` table (workspace->group->repo
--- hierarchy). v14 adds a `path TEXT` column to the same table so that the
--- scanner can persist the absolute on-disk path of each project, enabling
--- name-based findability (project name -> path + workspace) without
--- re-scanning or relying on external tooling.
---
--- Column semantics
--- ----------------
---   path TEXT (nullable)
---     Absolute filesystem path to the project root directory on the machine
---     where the scanner ran. For example: '/home/jorge/ws/me/gaia'.
---
---     NULL = path not yet recorded (the default for all pre-existing rows
---     after migration; also the default for rows created before the scanner
---     logic that assigns the value is deployed).
---     The value is assigned by populate_project (T2.x of the plan) using
---     the project_path argument already threaded through the scanner API.
---     This migration only adds the column; it does NOT back-fill existing
---     rows.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.
--- A failure mid-flight rolls back to v13 state; the ledger row is NOT
--- inserted, so the next bootstrap retry sees the same pending migration.
--- Closes T1.2 (schema + writer plumbing) of brief gaia-scan-overhaul.
-
--- ---------------------------------------------------------------------------
--- Step 1: Add path column to projects
--- ---------------------------------------------------------------------------
-ALTER TABLE projects ADD COLUMN path TEXT;
-
--- ---------------------------------------------------------------------------
--- Step 2: Bump schema_version to 14
--- ---------------------------------------------------------------------------
-INSERT OR IGNORE INTO schema_version (version, applied_at, description)
-VALUES (14, strftime('%Y-%m-%dT%H:%M:%SZ', 'now'),
-        'projects.path column (findability: project -> path + workspace)');
-
--- Verification queries (run after applying):
--- SELECT MAX(version) FROM schema_version;         -- expect: 14
--- PRAGMA table_info(projects);                     -- expect path column present

package/scripts/migrations/v13_to_v14_fresh.sql

@@ -1,17 +0,0 @@
--- Migration v13 -> v14 fresh-install variant
---
--- Used by bootstrap_database.sh when the live DB was created directly from
--- schema.sql at v14 state (i.e. schema.sql already declares the path column
--- on the projects table).
---
--- On a fresh install:
---   - schema.sql creates projects with all columns including path -> no DDL needed
---
--- This variant is a no-op; it only exists so the bootstrap guard-probe branch
--- can select it and stamp the ledger without applying DDL.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.
--- No DDL is executed; the COMMIT is harmless.
-
--- No-op: fresh install already at v14 state (schema.sql created all objects).
-SELECT 1;

package/scripts/migrations/v14_to_v15.sql

@@ -1,71 +0,0 @@
--- Migration v14 -> v15 (child-table FK column rename: repo -> project)
---
--- Background
--- ----------
--- Commit be9698f ("feat(substrate): rename projects->workspaces, repos->projects")
--- renamed the substrate hierarchy. The OLD `repos` concept (git-bearing units)
--- became `projects`, and the OLD `projects` container became `workspaces`.
---
--- schema.sql and the writer/populator code were updated to use the `project`
--- column on the nine per-project child tables:
---   apps, libraries, services, features, tf_modules, tf_live, releases,
---   workloads, clusters_defined
--- ...but NO migration was ever shipped to rename the live column. Because every
--- child table is declared with `CREATE TABLE IF NOT EXISTS`, schema.sql silently
--- no-ops on a DB that already has these tables, so existing installations (at
--- v14) still carry the legacy column name `repo`. The writer/populator code,
--- which already emits `project` in every INSERT / SELECT / ON CONFLICT /
--- delete_missing path, then fails at runtime with "no such column: project" the
--- first time `gaia scan` populates infra/app rows.
---
--- This was latent because scan_workspace_to_store had never run end-to-end via
--- the CLI (it was only wired in T3.1), and the unit tests mock the writer or
--- use fixtures with no infra/app content, so the column mismatch never executed.
---
--- Fix direction
--- -------------
--- `project` is the canonical name: it is what schema.sql declares, what every
--- writer/populator SQL path emits, and what the writer's PK maps in
--- delete_missing_in use. The live DB is the sole outlier. The lowest-blast-
--- radius fix is therefore a forward migration that renames the legacy `repo`
--- column to `project` on each of the nine child tables. No code change is
--- required.
---
--- Mechanism
--- ---------
--- SQLite >= 3.25 supports `ALTER TABLE ... RENAME COLUMN`, which rewrites the
--- stored DDL in place, automatically updating the column's appearance in the
--- table's PRIMARY KEY and in its own FOREIGN KEY clause. The FTS5 mirror tables
--- (apps_fts, services_fts) index text content columns (name, etc.), NOT the FK
--- column, so they are unaffected. Verified on sqlite 3.45.x: PRAGMA
--- foreign_key_check returns no rows after the rename and project-keyed INSERTs
--- succeed.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT. A failure
--- mid-flight rolls back to v14 state; the ledger row is NOT inserted, so the
--- next bootstrap retry sees the same pending migration.
-
--- ---------------------------------------------------------------------------
--- Step 1: Rename repo -> project on each per-project child table
--- ---------------------------------------------------------------------------
-ALTER TABLE apps             RENAME COLUMN repo TO project;
-ALTER TABLE libraries        RENAME COLUMN repo TO project;
-ALTER TABLE services         RENAME COLUMN repo TO project;
-ALTER TABLE features         RENAME COLUMN repo TO project;
-ALTER TABLE tf_modules       RENAME COLUMN repo TO project;
-ALTER TABLE tf_live          RENAME COLUMN repo TO project;
-ALTER TABLE releases         RENAME COLUMN repo TO project;
-ALTER TABLE workloads        RENAME COLUMN repo TO project;
-ALTER TABLE clusters_defined RENAME COLUMN repo TO project;
-
--- ---------------------------------------------------------------------------
--- Step 2: Bump schema_version to 15
--- ---------------------------------------------------------------------------
-INSERT OR IGNORE INTO schema_version (version, applied_at, description)
-VALUES (15, strftime('%Y-%m-%dT%H:%M:%SZ', 'now'),
-        'rename child-table FK column repo -> project (substrate rename catch-up)');
-
--- Verification queries (run after applying):
--- SELECT MAX(version) FROM schema_version;          -- expect: 15
--- PRAGMA table_info(apps);                           -- expect: project (not repo)
--- PRAGMA foreign_key_check;                          -- expect: no rows

package/scripts/migrations/v14_to_v15_fresh.sql

@@ -1,19 +0,0 @@
--- Migration v14 -> v15 fresh-install variant
---
--- Used by bootstrap_database.sh when the live DB was created directly from
--- schema.sql at v15 state -- i.e. the per-project child tables (apps, services,
--- tf_modules, ...) already carry the `project` column because schema.sql
--- declared them that way.
---
--- On a fresh install there is no legacy `repo` column to rename, so the
--- RENAME COLUMN statements in v14_to_v15.sql would fail with "no such column:
--- repo". This variant is a no-op; it exists only so the bootstrap guard-probe
--- branch (Section 3c, case 15) can select it and stamp the ledger without
--- attempting the rename.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.
--- No DDL is executed; the COMMIT is harmless.
-
--- No-op: fresh install already at v15 state (schema.sql created child tables
--- with the `project` column).
-SELECT 1;