Skip to main content

run_identity_store_schema

Function run_identity_store_schema 

Source
pub fn run_identity_store_schema(conn: &Connection) -> Result<(), StoreError>
Expand description

Initialize (or re-validate) the ~/.agentmux/shared/identity-store.db schema — the permanently-global store introduced by docs/specs/SPEC_IDENTITY_STORE_SPLIT_2026_08_17.md to fix conversation-continuity-across-a-version-switch (docs/specs/REPORT_HISTORY_CONTINUITY_ACROSS_VERSION_UPGRADE_2026_08_17.md).

This is a near-superset of run_shared_store_schema’s tables (v2): every one of them, INCLUDING db_accounts as of v2 — but db_accounts here is a read-through FALLBACK MIRROR only, not the authoritative write path. Unlike agent→account links, bundles, drone definitions, muxbus credentials, and native memory, db_accounts has one genuine, intentional isolation need (Armory’s disposable delete-account testing flow): a real per-account creation-time scope split (SPEC §3.2) hasn’t shipped yet, so id_store/resolve_shared_store_path() stays the primary read/write path for accounts, preserving Armory’s isolation exactly as before. This store’s copy exists ONLY so a link resolved here (always global) doesn’t dead-end on an account row that’s stuck in a fresh, per- channel-isolated id_store — see identity::resolver::inject’s account resolution (falls back to this store’s identity_get only when id_store’s own lookup misses) and migrations::m0022_identity_store_links_backfill (backfills this mirror the same way it backfills links). db_agent_identity_links.account_id still has NO foreign key here (same reasoning run_shared_store_schema already uses to drop its FK to db_agent_definitions: cross-database FK enforcement is impossible in SQLite, and this table’s db_accounts is itself just a mirror, not guaranteed complete — application code enforces referential integrity, tolerating a miss, instead).

A dedicated store (not a subset of the existing shared store reached via a new always-global path) is deliberate, not just a naming choice: it makes “can this table ever be reached from a per-channel-isolated codepath” a structural fact (a totally separate file/connection) rather than a convention someone could violate by calling resolve_shared_store_path() for a new call site later — the exact failure mode docs/specs/CHECKLIST_AGENT_DATA_SCOPE_ROUTING_2026_08_17.md items 2-4 already document as having bitten this codebase more than once.

Idempotent — safe to call on every startup.