Epic: Memory and Project State Backbone [MVP-1]

[radoxtech]

Package: @diricode/memory
Iteration: MVP-1
Issues: DC-MEM-001 — DC-MEM-007
Parent Meta-Epic: #464

Summary

Durable, queryable project memory for DiriCode MVP-1 using SQLite (project-local .dc/memory.db) with timeline-first storage, FTS5 search, token/cost telemetry, multi-project isolation, and a local-first issue management system. Operationalizes ADR-048 and acts as the state spine for checkpoint/resume, observability, and issue-driven planning.

Tracking

• [Sub-Epic] Agents Roster — POC through MVP persona rollout #385

Delivery emphasis

MVP-1 memory is not just archival storage. It must support:

• session continuity
• turn/task checkpoints
• replayable observations
• token/cost telemetry
• local issue/task state without any GitHub dependency

Issues

#	ID	Title	Status
#90	DC-MEM-001	SQLite database setup with migrations	✅ Done
#91	DC-MEM-002	Session storage	🏗️ Open
#92	DC-MEM-003	Observation/timeline storage	🏗️ Open
#93	DC-MEM-004	FTS5 full-text search	🏗️ Open
#94	DC-MEM-005	Token usage tracking	🏗️ Open
#95	DC-MEM-006	Local Issue System Client	🏗️ Open
#96	DC-MEM-007	Multi-project support	🏗️ Open

Delivery Sequence (Recommended)

1. DC-MEM-001 — Foundation (SQLite + migrations) ✅
2. DC-MEM-002 + DC-MEM-003 — Session and observation continuity
3. DC-MEM-004 — Search (FTS5 over messages + observations)
4. DC-MEM-005 — Usage telemetry (token/cost tracking)
5. DC-MEM-007 — Isolation (project vs global DB routing)
6. DC-MEM-006 — Local issue system client

Architecture

• runtime truth is local SQLite
• sync adapters are output targets, not input sources
• GitHub remains planning/project visibility, not runtime state backend

Guardrails

• Must NOT expose raw SQLite access outside @diricode/memory
• Must NOT couple memory schema to UI concerns
• Must NOT break project isolation by default
• Must NOT let checkpoint persistence become optional in MVP-1

Depends on: #10