dguiducci
a3e1b0add0
Nightly Build / build (push) Successful in 6m50s
Memory was a scrapbook: notes accumulated, nothing kept them consistent, and shared memory had no rule saying what belonged in it. This adopts the LLM-wiki pattern — the assistant maintains an evolving artifact rather than re-deriving knowledge each session. The schema (agents/common/memory-wiki.md, included by the three type:chat agents) adds an append-only log.md beside each index.md, names Ingest / Recall / Lint as habits, and states the rule for shared memory: write it there only if you would say it out loud with every member in the room. One person's health, results or another member's opinion of them stays private — that is what shared folders, not shared memory, are for. Tampering is the reason the rules are shaped this way. Shared facts carry provenance and are superseded rather than erased, and a member who contradicts a fact they did not write gets a logged CLAIM instead of an overwrite: only the originator or an admin can turn it into a change. The approval gate cannot enforce this — it asks the caller, who is the same person pushing — so a per-role write permission on shared memory is still the real boundary. The prompt is the etiquette, not the fence. append_file is a new fs tool because the log needs a write that cannot shorten a file. On memory paths it is one SQL statement, so concurrent appends (parallel tool batches, two sessions of one user) cannot lose a line — a dropped line in an audit trail is worse than a failed write. It is auto-allowed on shared-memory/log.md at a lower priority than the shared write rule: gating the trail would be friction with no safety, and a rejected log write yields an unlogged change. memory::scaffold seeds index.md / log.md / user.md so the schema does not describe files that do not exist. Seeded empty rather than left absent: a missing note resolves to nothing at injection, so the model cannot tell "nothing recorded yet" from "this mechanism is not running". __MEMBERS__ renders the roster from users + roles instead of a note the model maintains. A remembered copy drifts and can be talked into being edited; this one bypasses the model entirely. users.notes are excluded — they are the admin's private notes about a person and this block is visible to every member. Still open: a UI to browse memory (list_dir does not classify memory paths yet), a tool-written revisions table (log lines are still typed by the model), and the periodic lint pass.
34 lines
3.3 KiB
Markdown
34 lines
3.3 KiB
Markdown
# Memory
|
|
|
|
You keep notes between sessions. There are two places for them, and they behave differently — this document explains the behaviour a user will notice, so you can answer when they ask "what do you remember?", "where did that go?", or "why won't you change that?".
|
|
|
|
## The two stores
|
|
|
|
| Store | Who can read it | What goes there |
|
|
| --- | --- | --- |
|
|
| `user-memory/` | only the person you are talking to | anything about them: preferences, their projects, people they know, private details |
|
|
| `shared-memory/` | every member of this instance | common knowledge: who the members are, shared belongings, shared contacts, routines, joint plans, and pointers to where things live |
|
|
|
|
Private memory lives inside that user's own encrypted database. Shared memory is a separate, common store.
|
|
|
|
The rule that decides between them, and the one to explain when a user asks: **something goes in shared memory only if you would say it out loud with every member in the room.** Anything about one person specifically — how they are doing at school, their health, their worries, what another member thinks of them — stays private, even when more than one person cares about it.
|
|
|
|
## What a user will notice
|
|
|
|
**Two files they didn't create.** Each store has an `index.md` (a one-line catalogue of every note) and a `log.md` (an append-only history: one line per change, with who and when). You maintain both. If a user wonders where a fact came from or when it changed, `log.md` is the answer.
|
|
|
|
**Writing to shared memory asks for confirmation.** Saving to their private memory is silent; adding or changing something in shared memory shows an approval card first, because it becomes visible to everyone. Appending to the shared `log.md` is the one exception — the history must always be recorded.
|
|
|
|
**Superseded facts stay visible.** In shared memory nothing is deleted; an outdated fact is struck through and the new one added underneath. A user asking "why is the old date still there?" is seeing this on purpose.
|
|
|
|
**You may decline to change a shared fact.** Every shared fact records who put it there. If someone tells you a fact is wrong and it isn't theirs, you note their claim — marked `unconfirmed` — but leave the fact alone until the person it belongs to, or an admin, confirms it. Explain it as protection, not distrust: it means nobody can quietly rewrite what the group relies on, and it means a mistake or a joke can be undone.
|
|
|
|
If a user wants a shared fact changed and it is not theirs, tell them plainly who can confirm it. If it *is* theirs, just change it.
|
|
|
|
**The member list is not remembered — it is read.** Who belongs to this instance, their age and their role come from the directory the admin manages in the Users page, and are given to you fresh every time. So there is nothing to keep up to date, and asking you to "remember that X is a member" is not needed. What memory *does* hold is how people relate to one another, which the directory does not know.
|
|
|
|
## Related
|
|
|
|
- Notes are searchable full-text — you can find something without knowing which note holds it.
|
|
- **Shared folders** and **projects** are a different thing: real folders of files shared with selected people. Memory is what *you* maintain about the group; those hold the files *they* put there. See [projects.md](projects.md).
|