@jaguilar87/gaia 5.0.4 → 5.0.5

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;

package/scripts/migrations/v15_to_v16.sql

@@ -1,57 +0,0 @@
--- Migration v15 -> v16 (gaia-scan-overhaul: projects soft-delete columns)
---
--- Background
--- ----------
--- The prune step in scan_workspace_to_store currently issues hard DELETEs for
--- projects that are no longer found on disk. Brief gaia-scan-overhaul replaces
--- that with a soft-delete: projects are marked 'missing' instead of removed,
--- so historical context (memory atoms, episodes, briefs keyed on that project)
--- survives the scan cycle.
---
--- This migration adds two scanner-owned columns to the `projects` table:
---
---   status TEXT NOT NULL DEFAULT 'active'
---     Values: 'active' | 'missing'.
---     'active'  -- project was present on the last scan run.
---     'missing' -- project was NOT found on the most recent scan; kept as a
---                  tombstone so child-table data and historical context survive.
---     Default 'active': existing rows (which were present at migration time)
---     are classified as active. New rows inserted by the scanner also default
---     to 'active' without requiring callers to supply the column.
---
---   missing_since TEXT (nullable)
---     ISO8601 UTC timestamp of when status was first set to 'missing'.
---     NULL when status='active'. The scanner sets this on the first cycle
---     where it cannot find the project; subsequent cycles leave it unchanged
---     (the timestamp records the FIRST disappearance, not the most recent).
---
--- Scope of this migration
--- -----------------------
--- ONLY the DDL changes. The prune logic (DELETE -> UPDATE status='missing') is
--- implemented in the NEXT task (scan populator changes). This migration only
--- ensures the columns exist and that the writer accepts them.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT. A failure
--- mid-flight rolls back to v15 state; the ledger row is NOT inserted, so the
--- next bootstrap retry sees the same pending migration.
-
--- ---------------------------------------------------------------------------
--- Step 1: Add status column to projects (NOT NULL DEFAULT 'active')
--- ---------------------------------------------------------------------------
-ALTER TABLE projects ADD COLUMN status TEXT NOT NULL DEFAULT 'active';
-
--- ---------------------------------------------------------------------------
--- Step 2: Add missing_since column to projects (nullable)
--- ---------------------------------------------------------------------------
-ALTER TABLE projects ADD COLUMN missing_since TEXT;
-
--- ---------------------------------------------------------------------------
--- Step 3: Bump schema_version to 16
--- ---------------------------------------------------------------------------
-INSERT OR IGNORE INTO schema_version (version, applied_at, description)
-VALUES (16, strftime('%Y-%m-%dT%H:%M:%SZ', 'now'),
-        'projects soft-delete: status + missing_since columns');
-
--- Verification queries (run after applying):
--- SELECT MAX(version) FROM schema_version;          -- expect: 16
--- PRAGMA table_info(projects);                       -- expect: status, missing_since columns present

package/scripts/migrations/v15_to_v16_fresh.sql

@@ -1,18 +0,0 @@
--- Migration v15 -> v16 fresh-install variant
---
--- Used by bootstrap_database.sh when the live DB was created directly from
--- schema.sql at v16 state -- i.e. the `projects` table already carries the
--- `status` and `missing_since` columns because schema.sql declared them that way.
---
--- On a fresh install there are no legacy rows to alter, so the ALTER TABLE
--- statements in v15_to_v16.sql would fail with "duplicate column name".
--- This variant is a no-op; it exists only so the bootstrap guard-probe branch
--- (Section 3c, case 16) can select it and stamp the ledger without attempting
--- the ALTER.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.
--- No DDL is executed; the COMMIT is harmless.
-
--- No-op: fresh install already at v16 state (schema.sql created projects with
--- status and missing_since columns).
-SELECT 1;

package/scripts/migrations/v16_to_v17.sql

@@ -1,51 +0,0 @@
--- Migration v16 -> v17 (DEMOTE case: workspaces soft-delete columns)
---
--- Background
--- ----------
--- v16 added soft-delete (status / missing_since) to the `projects` table. The
--- multi-workspace DEMOTE test revealed the same gap one level up: when a
--- workspace loses its Gaia install footprint (the user removes its `.claude/`,
--- "demoting" it), the `workspaces` row had no way to record that. A re-scan of
--- a demoted directory would persist the row and refresh `last_scan_at` as if it
--- were still a live workspace.
---
--- This migration adds two scanner-owned columns to the `workspaces` table,
--- mirroring the v16 projects soft-delete contract:
---
---   status TEXT NOT NULL DEFAULT 'active'
---     Values: 'active' | 'missing'.
---     'active'  -- the workspace carried a Gaia install on the last scan.
---     'missing' -- the workspace's install footprint disappeared (demoted);
---                  kept as a tombstone so its projects/history survive.
---     Default 'active': existing rows (live workspaces at migration time) are
---     classified active without requiring callers to supply the column.
---
---   missing_since TEXT (nullable)
---     ISO8601 UTC timestamp of when status was first set to 'missing'.
---     NULL when status='active'. Set on the first scan that finds the install
---     gone; subsequent scans leave it unchanged (records the FIRST demote).
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT. A failure
--- mid-flight rolls back to v16 state; the ledger row is NOT inserted, so the
--- next bootstrap retry sees the same pending migration.
-
--- ---------------------------------------------------------------------------
--- Step 1: Add status column to workspaces (NOT NULL DEFAULT 'active')
--- ---------------------------------------------------------------------------
-ALTER TABLE workspaces ADD COLUMN status TEXT NOT NULL DEFAULT 'active';
-
--- ---------------------------------------------------------------------------
--- Step 2: Add missing_since column to workspaces (nullable)
--- ---------------------------------------------------------------------------
-ALTER TABLE workspaces ADD COLUMN missing_since TEXT;
-
--- ---------------------------------------------------------------------------
--- Step 3: Bump schema_version to 17
--- ---------------------------------------------------------------------------
-INSERT OR IGNORE INTO schema_version (version, applied_at, description)
-VALUES (17, strftime('%Y-%m-%dT%H:%M:%SZ', 'now'),
-        'workspaces soft-delete: status + missing_since columns (DEMOTE)');
-
--- Verification queries (run after applying):
--- SELECT MAX(version) FROM schema_version;          -- expect: 17
--- PRAGMA table_info(workspaces);                      -- expect: status, missing_since columns present

package/scripts/migrations/v16_to_v17_fresh.sql

@@ -1,18 +0,0 @@
--- Migration v16 -> v17 fresh-install variant
---
--- Used by bootstrap_database.sh when the live DB was created directly from
--- schema.sql at v17 state -- i.e. the `workspaces` table already carries the
--- `status` and `missing_since` columns because schema.sql declared them that way.
---
--- On a fresh install there are no legacy rows to alter, so the ALTER TABLE
--- statements in v16_to_v17.sql would fail with "duplicate column name".
--- This variant is a no-op; it exists only so the bootstrap guard-probe branch
--- (Section 3c, case 17) can select it and stamp the ledger without attempting
--- the ALTER.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.
--- No DDL is executed; the COMMIT is harmless.
-
--- No-op: fresh install already at v17 state (schema.sql created workspaces with
--- status and missing_since columns).
-SELECT 1;

package/scripts/migrations/v17_to_v18.sql

@@ -1,66 +0,0 @@
--- Migration v17 -> v18 (stable project identity: collapse same repo across vantages)
---
--- Background
--- ----------
--- The `projects` table is keyed (workspace, name). The scanner derives `name`
--- from the on-disk basename and `workspace` from the scan vantage's identity.
--- The SAME physical repository scanned from two different roots -- e.g. once
--- from the workspace root and once from inside the repo's own subdirectory
--- (which resolves a different *workspace* identity) -- produced TWO distinct
--- (workspace, name) rows: a duplicate of one physical project.
---
--- This migration adds a stable, vantage-independent project identity so the
--- UPSERT can collapse those duplicates into one row. Identity is resolved by
--- the scanner (tools/scan/store_populator.resolve_project_identity) in this
--- order: git-common-dir (realpath) > normalized remote (host/owner/repo) >
--- realpath of the project path.
---
--- Two additive, NON-DESTRUCTIVE changes:
---
---   1. ALTER TABLE projects ADD COLUMN project_identity TEXT (nullable)
---      Scanner-owned. NULL allowed for legacy/uninitialized rows so the column
---      adds cleanly to an existing DB without backfill. A subsequent `gaia scan`
---      populates it for every live project.
---
---   2. CREATE UNIQUE INDEX idx_projects_identity ... WHERE project_identity IS NOT NULL
---      PARTIAL unique index. Enforces one row per physical repo for rows that
---      HAVE an identity, while exempting legacy NULL-identity rows from the
---      uniqueness constraint (so multiple NULL rows can coexist until the next
---      scan backfills them). This is the ON CONFLICT target the writer uses.
---
--- Backfill note
--- -------------
--- This migration does NOT backfill project_identity for existing rows -- it
--- cannot derive git-common-dir from SQL alone, and the value is cheap to
--- recompute on the next scan. Existing duplicate rows (if any) are left intact;
--- the first scan after migration assigns identities and any genuine duplicate
--- collapses on the following scan once both rows share an identity. Because the
--- index is PARTIAL, the ADD COLUMN (all rows NULL) cannot fail on existing
--- duplicates.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT. A failure
--- mid-flight rolls back to v17 state; the ledger row is NOT inserted, so the
--- next bootstrap retry sees the same pending migration.
-
--- ---------------------------------------------------------------------------
--- Step 1: Add project_identity column to projects (nullable, scanner-owned)
--- ---------------------------------------------------------------------------
-ALTER TABLE projects ADD COLUMN project_identity TEXT;
-
--- ---------------------------------------------------------------------------
--- Step 2: Partial UNIQUE index that collapses the same physical repo to one row
--- ---------------------------------------------------------------------------
-CREATE UNIQUE INDEX IF NOT EXISTS idx_projects_identity
-    ON projects(project_identity) WHERE project_identity IS NOT NULL;
-
--- ---------------------------------------------------------------------------
--- Step 3: Bump schema_version to 18
--- ---------------------------------------------------------------------------
-INSERT OR IGNORE INTO schema_version (version, applied_at, description)
-VALUES (18, strftime('%Y-%m-%dT%H:%M:%SZ', 'now'),
-        'projects stable identity: project_identity column + partial unique index (collapse same repo across vantages)');
-
--- Verification queries (run after applying):
--- SELECT MAX(version) FROM schema_version;                                  -- expect: 18
--- SELECT name FROM pragma_table_info('projects') WHERE name='project_identity'; -- expect: project_identity
--- SELECT name FROM sqlite_master WHERE type='index' AND name='idx_projects_identity'; -- expect: idx_projects_identity

package/scripts/migrations/v17_to_v18_fresh.sql

@@ -1,24 +0,0 @@
--- Migration v17 -> v18 fresh-install variant
---
--- Used by bootstrap_database.sh when the live DB was created directly from
--- schema.sql at v18 state -- i.e. the `projects` table already carries the
--- `project_identity` column because schema.sql declared it that way.
---
--- On a fresh install there are no legacy rows to alter, so the ALTER TABLE
--- statement in v17_to_v18.sql would fail with "duplicate column name".
--- This variant therefore SKIPS the ALTER but still creates the partial unique
--- index -- the index is intentionally NOT declared in schema.sql because
--- referencing project_identity there would parse-fail when bootstrapping a
--- legacy (pre-v18) DB whose CREATE TABLE IF NOT EXISTS short-circuits before
--- the column exists. Creating it here (idempotent IF NOT EXISTS) is the only
--- place the index lands on a fresh install. Same convention as
--- idx_memory_class_status (scripts/migrations/v3_to_v4_fresh.sql).
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.
-
--- Step 1 (skipped on fresh install): the project_identity column already exists.
-
--- Step 2: create the partial unique index that collapses the same physical repo
--- (same project_identity) to one row, exempting NULL-identity legacy rows.
-CREATE UNIQUE INDEX IF NOT EXISTS idx_projects_identity
-    ON projects(project_identity) WHERE project_identity IS NOT NULL;

package/scripts/migrations/v1_to_v2.sql

@@ -1,97 +0,0 @@
--- Migration v1 -> v2: widen memory.type CHECK constraint.
---
--- Background
--- ----------
--- v1 schema: memory.type CHECK (type IN ('project', 'user', 'feedback'))
--- v2 schema: memory.type CHECK (type IN ('project', 'user', 'feedback', 'atom', 'decision', 'negative'))
---
--- The bug this migration fixes
--- ----------------------------
--- bootstrap_database.sh applies schema.sql with `CREATE TABLE IF NOT EXISTS`.
--- On DBs created under v1 the CREATE short-circuits and the widened CHECK in
--- schema.sql never lands -- yet the bootstrap historically stamped the
--- schema_version ledger row for v2 unconditionally. Result: the ledger lied
--- and writes of the new types ('atom', 'decision', 'negative') failed at
--- runtime with CHECK constraint errors while `gaia doctor` reported OK.
---
--- Pattern: SQLite cannot ALTER a CHECK constraint. Canonical workaround:
---   1. Drop the FTS5 mirror triggers (avoid duplicate writes during copy).
---   2. Rename the old table out of the way.
---   3. Create the new table with the widened CHECK matching schema.sql.
---   4. Copy rows preserving rowid (memory_fts joins on rowid).
---   5. Drop the renamed old table.
---   6. Recreate the indexes on the new table.
---   7. Recreate the FTS5 mirror triggers verbatim.
---   8. Rebuild memory_fts from the new memory table.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT. A
--- failure mid-flight rolls back to the v1 state and the ledger row is NOT
--- inserted -- the next bootstrap retry will see the same pending migration.
---
--- Pre-conditions: caller has verified that the live memory.type CHECK does
--- NOT yet include 'atom'. Applying this on an already-widened table would
--- still succeed (the rename-create-copy ends in the same state) but the
--- caller skips it to avoid unnecessary work.
-
--- 1. Drop the FTS5 trigger trio. They mirror writes into memory_fts; we do
---    not want them to fire during the bulk copy below. memory_fts itself is
---    untouched here -- we will rebuild it after the copy completes.
-DROP TRIGGER IF EXISTS memory_ai;
-DROP TRIGGER IF EXISTS memory_ad;
-DROP TRIGGER IF EXISTS memory_au;
-
--- 2. Rename the old table out of the way. The indexes (idx_memory_project,
---    idx_memory_workspace, idx_memory_type) move with the table under their
---    original names -- SQLite ALTER TABLE RENAME carries indexes along.
-ALTER TABLE memory RENAME TO memory_v1_legacy;
-
--- 3. Create the new memory table with the widened CHECK constraint that
---    matches schema.sql verbatim (6 allowed types).
-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,
-    PRIMARY KEY (workspace, name),
-    FOREIGN KEY (workspace) REFERENCES workspaces(name) ON DELETE CASCADE
-);
-
--- 4. Copy all rows preserving rowid. This is critical: memory_fts joins on
---    rowid, so changing them would invalidate the FTS5 index. We list rowid
---    explicitly to bypass SQLite's default rowid allocation.
-INSERT INTO memory (rowid, workspace, name, type, description, body, origin_session_id, updated_at)
-SELECT rowid, workspace, name, type, description, body, origin_session_id, updated_at
-FROM memory_v1_legacy;
-
--- 5. Drop the renamed old table. Its indexes go with it.
-DROP TABLE memory_v1_legacy;
-
--- 6. Recreate the indexes on the new table. Same names as schema.sql.
-CREATE INDEX IF NOT EXISTS idx_memory_workspace ON memory(workspace);
-CREATE INDEX IF NOT EXISTS idx_memory_type ON memory(type);
-
--- 7. 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;
-
--- 8. Rebuild memory_fts from the new memory table. FTS5's native reindex:
---    clears the internal state and rescans the backing table. Cleaner than
---    DELETE + INSERT loops.
-INSERT INTO memory_fts(memory_fts) VALUES('rebuild');

package/scripts/migrations/v2_to_v3.sql

@@ -1,68 +0,0 @@
--- Migration v2 -> v3 (rename path).
---
--- Background
--- ----------
--- v2 schema had:
---   context_contracts (workspace, section_name, payload, metadata, updated_at)
---   PK: (workspace, section_name)
---
--- v3 schema has:
---   project_context_contracts (workspace, contract_name, payload, metadata, updated_at)
---   PK: (workspace, contract_name)
---   + new table agent_contract_permissions
---   + new index idx_agent_contract_perms_agent
---
--- The rename of `context_contracts` -> `project_context_contracts` reflects
--- its actual role: rows are project-context contracts, not permission grants.
--- The column rename `section_name` -> `contract_name` aligns the vocabulary
--- with the permission model introduced alongside it.
---
--- Three real-world entry states
--- -----------------------------
--- State 1 (only old):  context_contracts exists, project_context_contracts does NOT.
---                      Typical of a clean v2 install upgrading for the first time.
---                      This script handles state 1 via ALTER TABLE RENAME.
--- State 2 (only new):  project_context_contracts exists, context_contracts does NOT,
---                      agent_contract_permissions exists.  Nothing to do -- the guard
---                      probe in bootstrap_database.sh detects state 2 and stamps the
---                      ledger without invoking this script.
--- State 3 (both):      Both tables exist.  Caused by a previous bootstrap where
---                      schema.sql under v3 was applied (CREATE TABLE IF NOT EXISTS
---                      created the new table) but the legacy context_contracts was
---                      never dropped.  State 3 needs row migration + drop, handled
---                      by v2_to_v3_merge.sql -- not by this script.
---
--- bootstrap_database.sh selects state 1 vs 3 via the guard probe and runs the
--- matching script.  Each script is therefore single-purpose and atomic.
---
--- Atomicity: bootstrap_database.sh wraps this script in BEGIN/COMMIT.  A failure
--- mid-flight rolls back to v2 state and the ledger row is NOT inserted, so the
--- next bootstrap retry will see the same pending migration.
-
--- 1. Rename the table.
-ALTER TABLE context_contracts RENAME TO project_context_contracts;
-
--- 2. Rename the column.
-ALTER TABLE project_context_contracts RENAME COLUMN section_name TO contract_name;
-
--- 3. Index on workspace -- name reflects the new table identity.  The old
---    index moved with the table on RENAME TO, but its name still references
---    the legacy table.  Drop + recreate keeps the index name consistent
---    with the new table identity.
-DROP INDEX IF EXISTS idx_context_contracts_workspace;
-CREATE INDEX IF NOT EXISTS idx_project_context_contracts_workspace
-    ON project_context_contracts(workspace);
-
--- 4. New permissions table + its index.  IF NOT EXISTS makes the script
---    safe to re-run if a partial earlier attempt already created them.
-CREATE TABLE IF NOT EXISTS agent_contract_permissions (
-    agent_name    TEXT NOT NULL,
-    contract_name TEXT NOT NULL,
-    can_read      INTEGER NOT NULL DEFAULT 0,
-    can_write     INTEGER NOT NULL DEFAULT 0,
-    cloud_scope   TEXT,
-    PRIMARY KEY (agent_name, contract_name, cloud_scope)
-);
-
-CREATE INDEX IF NOT EXISTS idx_agent_contract_perms_agent
-    ON agent_contract_permissions(agent_name);