Summary
Pages created via dewey_store_compiled and dewey_store_learning are persisted in the internal SQLite store (.uf/dewey/graph.db) but are invisible to MCP read tools (dewey_get_page, dewey_list_pages, dewey_search).
Reproduction
- Store a compiled article:
dewey_store_compiled(tag="test", content="# Test", sources=["src-1"])
- Verify it exists in SQLite:
SELECT name FROM pages WHERE source_id = 'compiled';
-- Returns: compiled/test
- Attempt to read via MCP:
dewey_get_page(name="compiled/test") → "page not found"
dewey_get_page(name="test") → "page not found"
dewey_list_pages(namespace="compiled") → []
dewey_search(query="test content") → No results
Root Cause Analysis
The dewey serve command defaults to --backend obsidian, which reads pages from the Obsidian vault directory (.md files at the vault root). The internal store (.uf/dewey/graph.db) is a separate data layer used by store_learning, store_compiled, and compile.
The MCP read tools (get_page, list_pages, search) query the Obsidian vault backend. The MCP write tools (store_compiled, store_learning) write to the internal store. These two layers are not bridged.
Evidence
From an active session with 1,295 pages in SQLite (including 61 learnings and 16 compiled articles):
dewey_health() → pageCount: 0, backend: obsidian
dewey_graph_overview() → totalPages: 0, totalBlocks: 0
dewey_list_pages() → []
sqlite3 .uf/dewey/graph.db "SELECT COUNT(*) FROM pages;" → 1295
Expected Behavior
Pages stored via dewey_store_compiled and dewey_store_learning should be retrievable via dewey_get_page, dewey_list_pages, and dewey_search.
Impact
- Compiled articles cannot be reviewed or queried after creation
- Learnings stored via MCP are write-only — agents cannot retrieve them via the same API
dewey_semantic_search does work (separate embedding index), creating inconsistency where semantic search finds pages that get_page cannot retrieve
dewey_promote fails with "Page not found" for internal store pages
Environment
- dewey version: dev (built from source)
- Backend: obsidian (default)
- Server:
dewey serve --vault . via OpenCode MCP
Summary
Pages created via
dewey_store_compiledanddewey_store_learningare persisted in the internal SQLite store (.uf/dewey/graph.db) but are invisible to MCP read tools (dewey_get_page,dewey_list_pages,dewey_search).Reproduction
Root Cause Analysis
The
dewey servecommand defaults to--backend obsidian, which reads pages from the Obsidian vault directory (.mdfiles at the vault root). The internal store (.uf/dewey/graph.db) is a separate data layer used bystore_learning,store_compiled, andcompile.The MCP read tools (
get_page,list_pages,search) query the Obsidian vault backend. The MCP write tools (store_compiled,store_learning) write to the internal store. These two layers are not bridged.Evidence
From an active session with 1,295 pages in SQLite (including 61 learnings and 16 compiled articles):
Expected Behavior
Pages stored via
dewey_store_compiledanddewey_store_learningshould be retrievable viadewey_get_page,dewey_list_pages, anddewey_search.Impact
dewey_semantic_searchdoes work (separate embedding index), creating inconsistency where semantic search finds pages thatget_pagecannot retrievedewey_promotefails with "Page not found" for internal store pagesEnvironment
dewey serve --vault .via OpenCode MCP