Repository navigation
manage_adr (MCP/CLI) and the UI /api/adr endpoints use separate storage backends #256
Description
The MCP tool manage_adr writes/reads ADRs as files at <root>/.codebase-memory/adr.md. The HTTP UI's /api/adr endpoints read/write SQLite via cbm_store_adr_get / cbm_store_adr_store. Writes via either interface are invisible to the other.
Reproduction (v0.6.0, macOS arm64):
# write via CLI
codebase-memory-mcp cli manage_adr '{"project":"<name>","mode":"update","content":"## PURPOSE\ntest\n"}'
# CLI roundtrips
codebase-memory-mcp cli manage_adr '{"project":"<name>","mode":"get"}' # -> returns content
cat <repo>/.codebase-memory/adr.md # -> content present
# UI endpoint
curl http://localhost:9749/api/adr?project=<name> # -> {"has_adr": false}
The UI's + ADR button stays + ADR because hasAdr comes from that /api/adr response (graph-ui/src/components/StatsTab.tsx:111).
Code pointers:
src/mcp/mcp.c:3498-3555—handle_manage_adr, file-backed at<root>/.codebase-memory/adr.md.src/ui/http_server.c:449-559—handle_adr_get/handle_adr_save, SQLite-backed viacbm_store_adr_*(src/store/store.c:4537,4560).
Expected: one canonical backend. The file-on-disk path is likely the right target since it's committable and lives with the repo; the SQLite-backed UI handlers would need to switch to reading/writing the file.
Impact: ADRs created by agents via MCP don't surface in the graph UI. ADRs created by humans in the UI aren't readable by agents.
Activity
fix(adr): unify manage_adr onto the SQLite store shared with the UI (#…
DeusData commentedon May 31, 2026
Thanks — clean diagnosis. The two interfaces did use separate backends:
manage_adrread/wrote<root>/.codebase-memory/adr.md(a file), while the UI/api/adrGET/POST used the SQLiteproject_summariestable viacbm_store_adr_get/cbm_store_adr_store. Writes on one side were invisible to the other.Fixed in commit 70e3ed7:
manage_adrnow goes throughcbm_store_adr_get/cbm_store_adr_store— the same store backend the UI uses — for all modes (update/store,get,sections). So an ADR written via the MCP tool shows up in the UI and vice-versa.Migration: to avoid losing ADRs created by older versions, on first access
manage_adrchecks for a legacy.codebase-memory/adr.mdand, if the store has no ADR yet, imports it into the store automatically. So your existing file-based ADRs carry over with no manual step.Regression tests added:
tool_manage_adr_unified_backend_issue256— writes viamanage_adr(update), then reads back viacbm_store_adr_get(the exact API/api/adruses) and asserts they match.tool_manage_adr_get_with_existing_adrnow exercises the file→store migration path.Ships in the next release. Thanks for the precise reproduction!