Constant IDENTITY_STORE_SCHEMA_VERSION 

pub const IDENTITY_STORE_SCHEMA_VERSION: i64 = 11;

user_version stamped into the new, permanently-global ~/.agentmux/shared/identity-store.db (distinct file from store.db — see run_identity_store_schema’s own doc comment for why). Independent counter from SHARED_STORE_SCHEMA_VERSION. v1 — initial: agent→account links, bundles, drone definitions, muxbus credentials, per-agent M2M credentials, native memory mirror, cron jobs. Everything run_shared_store_schema already held EXCEPT db_accounts — see docs/specs/SPEC_IDENTITY_STORE_SPLIT_2026_08_17.md §3.1. v2 — db_accounts, as a FALLBACK MIRROR only (reagentx P0 review on PR #2632): the link resolves via this store now, but the account row it points to could still only exist in the per-channel-isolatable id_store, which is empty on a fresh channel — the reported bug wasn’t actually fixed end to end without this. id_store remains the PRIMARY, authoritative, write path (so Armory’s disposable-test-account isolation is unchanged); this copy is consulted only when id_store doesn’t have the row. See identity::resolver::inject’s account resolution for the read-with-fallback + write-back-to-source-store logic this enables. v3 — db_agent_native_memory_versions, for schema parity with the v1 native memory mirror this store already carries. Same as that table, this store’s copy is not an actively-written duplicate (id_store/store.db remains the authoritative write path — see v2’s note above) — added here only so a future always-global read path (mirroring what v2 did for db_accounts) is not blocked on a missing table. See docs/specs/SPEC_MEMORY_VERSION_CONTROL_AND_ARMORY_AUDIT_2026_08_19.md. v4 — db_bundles.is_system, for schema parity with OBJECT_SCHEMA_VERSION v27 / SHARED_STORE_SCHEMA_VERSION v9 (same column, same reasoning as v3 above — this store’s db_bundles copy is not an actively- written duplicate either). Real ALTER TABLE ADD COLUMN added to run_identity_store_schema in the same change, so this counter MUST bump alongside it — an unbumped counter would leave an existing identity-store.db stamped at the old user_version forever, silently defeating check_schema_compat/stamp_version’s forward-compat lock for this one store (reagent P1, PR #2782). See docs/specs/SPEC_GLOBAL_MEMORY_SYSTEM_TIER_2026_08_24.md. v5: db_work_queue — the Muxqueue backlog (docs/reports/REPORT_UNIVERSAL_AGENT_WORK_QUEUE_2026_09_01.md). A NEW table, so no ALTER is involved, but the counter still bumps: an identity-store.db stamped v4 that a v5 binary opens must be recognized as older, not “already current” (same reagent P1 on PR #2782 reasoning recorded for v4 above).

   Deliberately in THIS store, not the per-channel one. A queue whose
   rows are per-channel means "any agent IN THIS CHANNEL can pick it
   up", which is close to useless given every local/dev/portable build
   is its own channel — see the report's §6.2, and
   `docs/analysis/ANALYSIS_PER_CHANNEL_AUTH_BYPASSES_2026_08_31.md`
   for what the per-channel/global seam has already cost once.

v6: db_skills, db_mcp_servers — Phase 2 of SPEC_DURABLE_BINDINGS_2026_09_10.md. These become the AUTHORITATIVE catalogs as of this version; the per-channel copies in run_object_schema keep their declarations (never removed — see that spec’s §5.1 and §8 item 3) and continue to exist only as the same best-effort degraded-mode fallback bootstrap/stores.rs already substitutes for every other identity-store table (mstore in place of identity_store when the identity store can’t be resolved, created, or opened). Deliberately NOT declared with the ref tables (db_agent_skills_ref, db_bundle_skills_ref, and the MCP equivalents) — those stay channel-scoped until Phase 3/6 promotes them; adding them here now, unpaired with a live writer, would be schema for a phase that hasn’t shipped. v7: partial UNIQUE indexes on db_skills(name, skill_type) and db_mcp_servers(name), each WHERE is_global = 1 — global rows only; two different owners’ private rows sharing a name is still fine. Closes a real race in m0031_carry_skills_and_mcp_servers_to_identity_store: two channels’ migrations can run concurrently (multiple AgentMux instances is an explicitly supported scenario), both read “no matching global row yet” before either has inserted, and both proceed to insert under different ids — the promised first-wins cross-channel dedup silently fails without a DB-level constraint to arbitrate the race (Codex P1, PR #3181). The migration’s insert now handles the resulting UNIQUE constraint failed by re-querying for whichever row actually won. v8 — idx_ids_skills_global_name replaces idx_ids_skills_global_name_type: narrows the skill global-uniqueness index from (name, skill_type) to name alone, matching the invariant skill_upsert_unique_global’s own dup-check has always enforced (WHERE name = ?1 AND id <> ?2 AND is_global = 1 — no skill_type filter). Codex P2, PR #3182, SPEC_DURABLE_BINDINGS_2026_09_10.md §5.4: the v7 index was narrower than the invariant it was meant to back, so a same-name-different-skill_type race between two channels could insert two rows the application itself considers duplicates. MCP servers don’t have this mismatch — idx_ids_mcp_servers_global_name is already name-only — so this bump is skills-only. m0033_narrow_skill_global_uniqueness_index defensively collapses any existing same-name/different-type pair m0031’s own (name, skill_type)-keyed dedup may already have produced, to the earlier-created_at row, before the new index is created. v9 — db_bundle_versions, for schema parity with OBJECT_SCHEMA_VERSION v35 / SHARED_STORE_SCHEMA_VERSION v10 (same table, same reasoning as v3 above — this store’s copy is not an actively-written duplicate either). See docs/specs/SPEC_AGENT_FACING_GLOBAL_MEMORY_API_2026_09_15.md. v10 — db_work_queue.target_agent_uid / claimed_by_uid, and db_cron_jobs.target_uid (parity with SHARED_STORE_SCHEMA_VERSION v11): the UID (db_agents.id) beside each slug column, dual-written and not yet read. Identity M1b of SPEC_AGENT_IDENTITY_CARRIED_NOT_DERIVED_2026_09_23.md §9.1. target_agent_uid is resolved ONCE at enqueue (spec §5.4); claimed_by_uid is CARRIED from the claimer’s own AGENTMUX_AGENT_UID (M1a, #3548), falling back to resolving its agent_id with the fallback counted (spec §9.2). Empty when unknown; never guessed. v11 — db_work_queue.created_by_uid, and db_cron_jobs.created_by_uid / db_bundle_versions.written_by_uid (parity with SHARED_STORE_SCHEMA_VERSION v12): the actor’s UID beside each actor-name column, taken from the request’s Caller (its X-Agent-Token), never from a body field. Empty for an Unattributed request; never guessed. Dual-written, not yet read. Identity M4c-1 of SPEC_AGENT_IDENTITY_CARRIED_NOT_DERIVED_2026_09_23.md §6.5.9.

Added WITHOUT a bump: db_mcp_server_reach (OBJECT_SCHEMA_VERSION v44 has the same table). The catalog’s reach switches live with the catalog, here, so they survive an upgrade where an agent bind (db_agent_mcp_ref, in objects.db) does not. This store is one file shared by every AgentMux on the computer, installed and dev builds alike, and check_schema_compat makes any build that speaks an older version refuse it. So a bump here locks every older AgentMux on the computer out as soon as one newer build starts: a dev build of a branch with a bump did exactly that on 2026-10-11. A table an older build never reads needs no lock: an older build ignores it, a newer one creates it if missing. Bump only for a change an older build would misread or corrupt. SPEC_CONNECTORS_MCP_WHAT_AGENTS_RUN_2026_10_10.md §2.1.