Help
Known limitations
Memory Layer v1.0 is a stability release for the local-first service, CLI, TUI, web UI, watcher, skills, and read-only MCP workflows. Some newer surfaces remain advanced and should be used with that context.
Stable compatibility targets
| Surface | v1 expectation |
|---|---|
| CLI | Documented core commands and --json shapes remain stable. |
| Config | Global config, project config, and repo-local skills keep their documented locations. |
| Database | Migrations are append-only; applied migrations are not edited. |
| MCP | Read-only query, global search, resume, resource, and prompt tools remain protocol adapters over the service API. |
| Service | Debian, Homebrew, and source/dev profiles keep distinct runtime behavior. |
Advanced surfaces
| Surface | Limitation |
|---|---|
| Loop automation | Approval-gated by design; risky actions stop for human review. |
| Code graph UI | Requires WebGL and depends on extraction coverage for each repository. |
| Eval research workflows | Release claims still require reviewed held-out suites and a passing gate. |
| Demo web UI | Uses browser-local sample data and is not a live backend. |
Release-candidate blockers
- Plan-memory completion can fail if
/v1/curatetimes out. - Repositories with multiple active plan memories may need explicit
--thread-keywhen finishing a plan. - Final v1.0 should only be tagged after packaged install and upgrade testing passes for the release candidate.
Upgrade checklist
Before upgrading:
memory status --project <project-slug>
memory doctor
pg_dump "$DATABASE_URL" > memory-layer-before-upgrade.sqlAfter upgrading:
memory service restart-all
memory doctor
memory health
memory status --project <project-slug>
memory upgrade --dry-runRead Operations, Doctor and health, or Update.