Repository navigation
feat(memory): core Episode projection schema migration (plan-20260926 DM-01) #614
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Large diffs are not rendered by default.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,67 @@ | ||
| -- Memory core projection schema (plan-20260926 DM-01, migration A). | ||
| -- | ||
| -- These tables are ZERO-AUTHORITY and fully REBUILDABLE (GC-DM-01): every row is | ||
| -- a pure function of the repository's durable facts (commit/change, agent | ||
| -- session, agent run, bridge operation). They hold no authoritative state and | ||
| -- can be re-derived at any time via `libra memory rebuild`. A stale index never | ||
| -- answers (freshness is validated on read, mirroring 2026070301_revision_ordinal). | ||
| -- | ||
| -- This migration is delivered `forward-only` (ADR-DM-13): once applied, an older | ||
| -- binary cannot reopen the repository database (future-schema rejection is | ||
| -- exercised by DM-10's simulated-old-runner test). The `_down.sql` is provided | ||
| -- and tested but is only a controlled test/ops tool, not the published rollback | ||
| -- path (progression by patching forward). | ||
| -- | ||
| -- Table layout is frozen verbatim by plan-20260926 "Schema 规范" (DM-01 rows only). | ||
| -- `memory_episode_path` / `memory_episode_search_doc` belong to DM-10. | ||
| -- DM-01 deliberately does NOT create the FTS5 virtual table (that is DM-08). | ||
|
|
||
| CREATE TABLE IF NOT EXISTS `memory_episode` ( | ||
| `episode_id` TEXT PRIMARY KEY, | ||
| `repo_id` TEXT NOT NULL, | ||
| `source_kind` TEXT NOT NULL CHECK (`source_kind` IN | ||
| ('commit','agent_session','agent_run','bridge_operation')), | ||
| `source_key` TEXT NOT NULL, | ||
| `outcome` TEXT NOT NULL CHECK (`outcome` IN | ||
| ('succeeded','failed','aborted','partial','unknown')), | ||
| `actor` TEXT, | ||
| `started_at` INTEGER NOT NULL, | ||
| `ended_at` INTEGER NOT NULL, | ||
| `anchor_commit` TEXT, | ||
| `change_id` TEXT, | ||
| `title` TEXT NOT NULL, | ||
| `body` TEXT NOT NULL, | ||
| `content_digest` TEXT NOT NULL, | ||
| `producer` TEXT NOT NULL DEFAULT 'derived-v1', | ||
| `rules_version` INTEGER NOT NULL, | ||
| UNIQUE(`repo_id`, `source_kind`, `source_key`) | ||
| ); | ||
|
|
||
| CREATE TABLE IF NOT EXISTS `memory_episode_evidence` ( | ||
| `episode_id` TEXT NOT NULL, | ||
| `ordinal` INTEGER NOT NULL, | ||
| `kind` TEXT NOT NULL CHECK (`kind` IN | ||
| ('commit','checkpoint','review_run','operation')), | ||
| `ref_id` TEXT NOT NULL, | ||
| `link_confidence` TEXT NOT NULL CHECK (`link_confidence` IN | ||
| ('identity','operation','temporal')), | ||
| `resolution_status` TEXT NOT NULL DEFAULT 'resolved' CHECK (`resolution_status` IN | ||
| ('resolved','unresolved')), | ||
| PRIMARY KEY (`episode_id`, `ordinal`), | ||
| FOREIGN KEY (`episode_id`) REFERENCES `memory_episode`(`episode_id`) ON DELETE CASCADE | ||
| ); | ||
|
|
||
| CREATE TABLE IF NOT EXISTS `memory_projection_state` ( | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. via Codex [P1] Validate pre-existing Memory table shapes before accepting this migration
Repositories that tried the earlier Memory branch are therefore certified as upgraded without the schema expected by subsequent Memory cards. Please inspect all three existing tables inside the migration transaction and either reject incompatible shapes with an actionable error or explicitly convert them. Add a regression fixture proving that a mismatched shape cannot commit the |
||
| `repo_id` TEXT NOT NULL, | ||
| `source_kind` TEXT NOT NULL CHECK (`source_kind` IN | ||
| ('commit','agent_session','agent_run','bridge_operation')), | ||
| `cursor_json` TEXT NOT NULL, | ||
| `fingerprint` TEXT NOT NULL, | ||
| `rules_version` INTEGER NOT NULL, | ||
| `schema_version` INTEGER NOT NULL, | ||
| `horizon_truncated` INTEGER NOT NULL CHECK (`horizon_truncated` IN (0,1)), | ||
| `revoked_count` INTEGER NOT NULL DEFAULT 0, | ||
| `aged_out_count` INTEGER NOT NULL DEFAULT 0, | ||
| `rebuilt_at` INTEGER NOT NULL, | ||
| PRIMARY KEY (`repo_id`, `source_kind`) | ||
| ); | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| -- Memory core projection schema down (plan-20260926 DM-01 migration A). | ||
| -- | ||
| -- `forward-only` (ADR-DM-13): this down is a controlled test/ops tool, not the | ||
| -- published rollback path. Drop in FK-reverse order (children before parents): | ||
| -- `memory_episode_evidence` references `memory_episode` and must be dropped first. | ||
| DROP TABLE IF EXISTS `memory_episode_evidence`; | ||
| DROP TABLE IF EXISTS `memory_episode`; | ||
| DROP TABLE IF EXISTS `memory_projection_state`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
via Codex
[P1] Document the old-binary compatibility boundary in the release notes
Although this adds no new CLI command, applying
2026092901changes the repository-open contract: binaries whose registry ends at2026092701(including the preceding release) reject the repository as a future schema. Reinstalling the old binary does not undo the receipt. This consequence is acknowledged in ADR-DM-13 and the internal SQL comments, but this release entry saysNo public CLI behavior changesand gives users no downgrade/recovery guidance.Please explicitly state the minimum compatible version after migration, that recovery uses a compatible newer binary/forward fix rather than binary downgrade alone, and that users needing a return to the old version must retain a consistent pre-upgrade backup. Reflect the boundary in the user-facing compatibility documentation as well.