## 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.
