singularity-forge/docs/plans/memory-consolidation-db-plan.md

M001-6377a4: Consolidate Memory State into .sf/sf.db

Gathered: 2026-05-07
Status: Implemented baseline, remaining work is product integration.

Purpose

Memory state must follow the same rule as the rest of SF state: structured, queryable, project-owned data lives in .sf/sf.db. Runtime memory code should not write global sidecar databases or introduce a second SQLite engine.

Current Baseline

• SF memory APIs use node:sqlite through the project database.
• The Pi memory extraction queue now opens <cwd>/.sf/sf.db.
• Extracted memory artifacts are written under <cwd>/.sf/memory.
• Runtime package dependencies no longer include a WASM SQLite engine for the memory pipeline.

Remaining Product Work

• Make /memory view prefer DB-backed memory rows over generated markdown when both exist.
• Connect extracted stage outputs to the existing memories table instead of only producing markdown summaries.
• Add a migration command only if we decide old user data should be imported. Do not keep passive compatibility code in startup paths.

Acceptance

• /memory rebuild records extraction queue state in .sf/sf.db.
• /memory view reads the same project memory source that UOK and prompt assembly use.
• Grep finds no runtime memory import of alternate SQLite engines.
• Tests cover the DB path, rebuild path, and clear path.