Daniele
488c702517
Until now file browsing existed only inside a project, and the two memory
stores were reachable only by the agent's tools. `#files` is the general
surface: home, both memory stores, the shared folders and projects the
caller belongs to, plus the read-only skills and docs trees.
The root is virtual, and that is the design. Anchoring at `~` is wrong:
the explorer reads host-side, while `shared/`, `projects/`, `skills/` and
`docs/` are bind mounts inside the container — a page rooted at the home
would show less than the user has with no way to reach the rest, and on
native Linux would show Docker's empty mountpoint stubs, a door that
appears to work and leads nowhere. So level 0 is a synthetic list from the
new `GET /api/files/roots`, serialized from the caller's `UserFs` plus the
two virtual memory roots. It sends `kind`, never a label: labels are copy
and get translated.
`GET /api/files/dir` now answers `{ path, can_write, entries }`, and a
memory path is classified before `resolve_view_path` (which refuses one)
and listed from `memory_docs`: one level derived from the flat key space
by the pure `memory_docs::immediate_children`, over a single query whose
unslashed prefix also spots an exact note as "not a directory". Memory is
read-only from the page — every writer routes through `resolve_view_path`,
and `shared-memory/*` is `@fs_write require` for the agent, so a button
that walks past that rule is a decision of its own.
The explorer moves out of projects into `shared/file-explorer.js`, taking
`root` + `rootLabel` and reading `can_write` from the listing rather than
from its host: writability changes per branch and comes from the same
`UserFs::can_write_to` the server rejects writes with, so the buttons
offered and the writes accepted cannot disagree. Deep-linking needed it
steerable without a two-way binding, hence `rel` in and
`explorer-navigate` out — the event fires only for a click, never for a
`rel` the host set, so echoing it back is a no-op.
The URL carries the agent path of the open folder in one parameter, the
same vocabulary the assistant uses, so a link is shareable and pasteable
into a conversation; which root it belongs to is derived, not stored.
docs/: a new files.md, plus two pages this made false — shared-folders.md
claimed in three places that a shared folder has no explorer, and
memory.md never said a user can now read their own notes.
4.9 KiB
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.
They can read their notes themselves. Both stores appear as folders on the Files page (sidebar → Files), so a user can open and read any note without asking you — but read-only: editing and deleting still go through you, which is what keeps log.md honest and, for shared memory, keeps the confirmation step in place. See files.md.
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.
Your writing voice is learned, not re-explained. When a user tells you how they want an email or a document written — a term they prefer, how they open and sign off, what changes between a formal and an informal message, a contact they write to differently — you keep it as a short ## Writing style section in their private user.md, and apply it the next time you draft something. A user who wonders why you suddenly close their emails the way they do is seeing this; they can ask you to read it back, change a line, or drop 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.
Memory is maintained, not just written to
Both stores are kept as a small wiki: notes cross-reference each other, index.md says where things are, and log.md records every change. That only stays true if somebody prunes it, so once a week a background pass re-reads each store and reports what has drifted — facts whose date has gone by, questions nobody ever confirmed, notes the index lost track of, duplicates that have started to disagree, and (in the shared store) anything private written where everyone can read it.
Those passes never edit memory. They report, and a person decides. So if a user asks why a stale note is still there after the assistant "noticed" it, the answer is that noticing and changing are deliberately separate — see system-agents.md.
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.