-
-
Notifications
You must be signed in to change notification settings - Fork 3
Database Migrations
CortexPrism edited this page Jun 17, 2026
·
1 revision
CortexPrism uses idempotent SQLite migrations via @libsql/client. Migrations are numbered sequentially and guarded by checksums.
Located in src/db/migrations/NNN_description.sql. All 21 migrations:
| # | File | Database | Description |
|---|---|---|---|
| 001 | core.sql |
cortex.db | sessions, turns, jobs |
| 002 | memory.sql |
memory.db | 5-tier memory + FTS5 |
| 003 | lens.sql |
lens.db | lens_events audit |
| 004 | vault.sql |
vault.db | vault_entries + access_log |
| 005 | plugins.sql |
plugins.db | plugin registry |
| 006 | session.sql |
cortex.db | session_messages table |
| 007 | jobs_v2.sql |
cortex.db | job scheduler columns |
| 008 | memory_embeddings.sql |
memory.db | embedding + decay columns |
| 009 | policy.sql |
cortex.db | policy_rules + default seeds |
| 010 | services.sql |
cortex.db | micro-service definitions |
| 011 | workspace.sql |
cortex.db | workspace_config + file_edit_log |
| 012 | plugins_enhanced.sql |
plugins.db | enhanced plugin columns |
| 013 | sessions_parent.sql |
cortex.db | parent_session_id for sub-agents |
| 014 | skills_origin.sql |
cortex.db | skills table with origin tracking |
| 015 | nodes.sql |
cortex.db | distributed node registry |
| 016 | node_policies.sql |
cortex.db | per-node policy rules |
| 017 | skills_metadata.sql |
cortex.db | skills metadata extension |
| 018 | quartermaster.sql |
cortex.db | tool orchestration learning |
| 019 | model_quartermaster.sql |
cortex.db | Model Quartermaster (MQM) |
| 020 | episodic_updated_at.sql |
memory.db | updated_at + graph_relation_types seed |
| 021 | workspace_type_config.sql |
cortex.db | workspace type configuration |
cortex migrate # Apply all pending migrations
deno run --allow-all src/db/migrate.ts # Direct execution- Create
src/db/migrations/NNN_description.sqlusing the next sequential number - Add an entry to the
targetsarray insrc/db/migrate.ts - Never edit a migration that has already been applied — create a new one instead
Migrations should be idempotent — use CREATE TABLE IF NOT EXISTS, ALTER TABLE ... ADD COLUMN IF NOT EXISTS, and other guarded statements.
Each migration has a checksum computed on first application. The system detects if a previously-applied migration has been modified and refuses to run it.
- Architecture — Database overview
- Contributing — How to add a migration
CortexPrism — Open-source agentic AI harness · MIT License · Built with Deno 2.x + TypeScript