dguiducci
a847dda88f
Add a virtual memory namespace backed by SQLite, surfaced through the fs-tools, with private (per-user) and shared (system) stores. Storage - `memory_docs` owner table + external-content FTS5 index with sync triggers. - `db/memory_docs.rs` accessor: get / upsert / list / search (bm25+snippet) / delete. Routing (tools/fs) - `classify_memory` splits paths on the raw first component; `..` clamps inside the store, never escaping to disk. - read/write/list/edit/insert/replace/search_file route `user-memory/` to the owner pool and `shared-memory/` to the system pool (a singleton captured in `register_all`); every other path stays on disk. Each tool extracts a pure transform shared between its disk and memory paths. - New `memory_search` tool over the FTS index (scope private/shared/all), with a sanitised FTS5 query. grep_files stays disk-only. Approval - `user-memory/*` allow (read+write); `shared-memory/*` reads allow, writes require approval so the agent can't silently push one person's data into shared memory. `memory_search` allowed via a path-less rule. - migrate away the old `memory/*` and blanket `shared-memory/*` rows. Prompt injection - `MessageBuilder::load_inject_memory` reads `user-memory/` (owner pool) and `shared-memory/` (system pool) inject entries from SQLite; disk paths unchanged. The system pool is threaded ChatSessionManager -> handler -> MessageBuilder. - main and project-coordinator inject `user-memory/index.md` + `shared-memory/index.md`; common/memory.md rewritten for the two stores.
2.6 KiB
Persistent memory
You have two persistent note stores, kept as Markdown and searchable. Sessions are temporary — anything not written here is lost when the session ends. Save proactively.
user-memory/— your private memory for this user. Nobody else can read it. Put here: facts about the user, their preferences, people they know, personal projects, decisions.shared-memory/— memory shared with the whole group. Every member can read it. Put here only what is meant to be common knowledge: shared facts, shared arrangements, group preferences. Never put one person's private information here. Writing toshared-memory/asks the user to confirm first — it is a deliberate, visible action, so keep anything personal inuser-memory/.
When unsure where something belongs, prefer user-memory/.
The indexes
Each store has an index.md — one line per note with a brief summary — and both are injected into your context automatically at the start of each session (look for them below):
user-memory/index.md— your private notes.shared-memory/index.md— the group's shared notes.
Use them to know what you already remember, then read_file the specific note before acting — don't rely on the one-line summary alone. Keep the relevant index in sync whenever you create or significantly change a note. Updating shared-memory/index.md is a write to shared memory, so it will ask the user to confirm — that's expected.
When to save
Save immediately (do not postpone) when:
- The user shares a new fact about themselves, a project, a person, or a preference
- A decision is made that may matter in a future session
- You notice that something you saved before is now wrong → correct it
When to read
Before responding about a topic that may already be in memory, look it up — do not rely on recollection:
- The injected
user-memory/index.mdtells you what exists;read_filethe note it points to. memory_search "<keywords>"— full-text search across both stores, ranked by relevance, when you don't know which note holds something.
Organising notes
Use clear, topic-based paths — e.g. user-memory/people/alice.md, user-memory/projects/website.md, shared-memory/wifi.md. Keep one topic per note.
Note format
# Title
_Updated: YYYY-MM-DD_
## Section
- **Field**: value
How to update
read_filethe note to get its exact current content.edit_fileto change part of it — keep the_Updated:_date in sync.- Use
write_fileonly to create a new note or fully rewrite one. - Keep
user-memory/index.mdin sync when you add or significantly change a note.