Review: Honor Configured Drawer Collection Everywhere

This is a significant correctness fix. The core problem — different code paths silently using different collections — is exactly the kind of bug that's invisible in testing but devastating in production. We hit a variant of this when our integration's knowledge_graph_bridge.py was writing to one collection while the MCP search read from another.

Architecture

The new resolve_drawer_context() + get_drawer_collection() + open_collection_on_client() factoring in palace.py is clean. Single source of truth for collection resolution, config-aware, with proper create flag semantics.

iter_collection_metadatas() — The paginated iteration is the right fix for the limit=10000 hard cap. The offset-based pagination pattern is correct:

offset += batch_count
if batch_count < batch_size:
    break

This handles the "last batch smaller than page size" termination correctly.

Specific observations

✅ ~ expansion from config/env — _expand_path() is a good single-point normalization. Previously MEMPALACE_PALACE_PATH=~/palace would silently work differently depending on whether the shell expanded ~ before Python saw it. Now it's consistent.

✅ MCP cache rekeying — The _collection_cache_key = (palace_path, collection_name) tuple ensures that changing either dimension invalidates the cache. The test_get_collection_rekeys_when_context_changes test covers path change, name change, and both change. Thorough.

✅ create=False doesn't materialize empty palaces — get_drawer_collection(create=False) returns None if the directory is missing. This prevents mempalace status from creating empty palace directories as a side effect. We added the same guard in our integration and it eliminated a confusing class of "phantom palace" bugs.

⚠️ Potential issue in cmd_repair():

palace_path, collection_name = resolve_drawer_context(palace_path=palace_arg, config=cfg)

Then later:

col = get_drawer_collection(palace_path=palace_path, create=False, config=cfg)

Then:

client = chromadb.PersistentClient(path=palace_path)

The repair flow creates a new client after already getting a collection through get_drawer_collection. This means two separate PersistentClient instances pointing at the same directory. ChromaDB's locking should handle this, but it's a bit fragile. Consider getting the client from the same path as the collection, or restructuring to use a single client.

Test coverage — Excellent. The regression tests for tilde expansion, configured collection mining, paged status, and cache rekeying are well-targeted. The _PagedCollection helper in tests is a clean way to test pagination without real ChromaDB overhead.

Scope

16 files changed, 611 additions, 222 deletions — this is wide-ranging but every change is consistent with the stated goal. No scope creep. The "What this does not change" section in the description is appreciated.

Strong PR. Addresses a real trust problem in the tool.

🔭 Reviewed as part of the MemPalace-AGI integration project — autonomous research with perfect memory. Community interaction updates are posted regularly on the dashboard.

Took another pass on the restacked diff — the merge-order concern is resolved.

The collection-access seam changes that were in conflict with #413 are now on main, and your restack picks them up cleanly. The mcp_server.py diff in particular shrank by ~100 lines (net -44) which is exactly what you'd expect after the upstream abstraction landed — less bespoke resolution code needed here.

162 passing on the focused lane (config, palace, searcher, layers, mcp_server, miner, convo_miner, cli) and ruff clean is the right validation set for this change.

The scope is still what I'd want: consistent collection resolution, ~ expansion from config/env, no create-on-read false positives, paginated metadata reads for large palaces, and keyed MCP cache. No scope creep from the restack.

LGTM — approving.