Problem
Every memory lands in one undifferentiated pile. Separate databases per project work today — --db ./project.db — but they're a blunt instrument: you lose cross-project recall entirely, and your general preferences don't follow you into a project.
What people actually want is one store with partitions: search this project, or search everything.
What to consider
A namespace column on memories, defaulting to something like "default", with a namespace argument on store and search. Tags can't do this job — they filter within one pile rather than partitioning it, and they don't give a sensible default scope for an agent that doesn't specify one.
Acceptance criteria
Why this needs discussion first
This is the first change that touches the schema, which makes it the first real test of the migration story. It's worth getting the shape right before writing code.
Open questions:
- How does an agent know which namespace to use? If it must be told every call, it'll get it wrong. A server-level default via
--namespace is probably necessary, with the tool argument as an override.
- Should search default to the current namespace or to everything? Defaulting to everything makes namespaces feel useless; defaulting to current makes an agent unable to find things it stored elsewhere without knowing to look.
- Does this overlap enough with per-database separation to not be worth it? A real argument —
--db already works and adds no schema complexity. The case for namespaces rests mainly on cross-namespace search.
Please comment before building.
Pointers
src/localmem_mcp/store.py — _SCHEMA, and the tag-filtering pattern in search() and recent()
- RELEASE.md — what counts as a breaking schema change
Problem
Every memory lands in one undifferentiated pile. Separate databases per project work today —
--db ./project.db— but they're a blunt instrument: you lose cross-project recall entirely, and your general preferences don't follow you into a project.What people actually want is one store with partitions: search this project, or search everything.
What to consider
A
namespacecolumn onmemories, defaulting to something like"default", with a namespace argument on store and search. Tags can't do this job — they filter within one pile rather than partitioning it, and they don't give a sensible default scope for an agent that doesn't specify one.Acceptance criteria
store_memoryandsearch_memoryaccept a namespace; search can span all namespaces explicitlyWhy this needs discussion first
This is the first change that touches the schema, which makes it the first real test of the migration story. It's worth getting the shape right before writing code.
Open questions:
--namespaceis probably necessary, with the tool argument as an override.--dbalready works and adds no schema complexity. The case for namespaces rests mainly on cross-namespace search.Please comment before building.
Pointers
src/localmem_mcp/store.py—_SCHEMA, and the tag-filtering pattern insearch()andrecent()