claude-code: carry each project's memory folder between nodes (issue 367, ADR 0343)

A session started on another node began without what the sessions elsewhere had
learned, because Claude Code keeps project memory on one node. The module's own
process now carries the memory folders through its kept memory state: a change
is written elsewhere only over the version it replaced, a file changed on two
nodes keeps both (newer first) with a warning, and every replaced or removed
version is kept. No tool writes memory.

modules/claude-code/README.md

@@ -11,8 +11,9 @@ Two directories, declared, so the mesh refuses a second module owning either:
 - `~/.claude` under the home of the account agents run as (the operator's, unless the machine names an agent
   account of its own), that account's, `0700`. The module owns the directory —
   that it exists, who owns it, its mode — and of what is inside only what it writes. Everything else
-  in it (memory, history, projects, local settings, a person's own rules and skills) is the person's
-  and is never read or written (hq ADR 0182). Unassigned, the module leaves the directory: the host
+  in it (history, projects, local settings, a person's own rules and skills) is the person's
+  and is never read or written (hq ADR 0182) — but for each project's memory folder, which the module
+  carries between nodes (hq ADR 0343, below). Unassigned, the module leaves the directory: the host
   removes a directory only when it is empty.
 
 And, for where the agent runs as an account of its own (hq ADR 0266):
@@ -69,8 +70,33 @@ must see, a node that joins later included — kept, so it carries no secret eit
 | an MCP server registered through this module before registering was refused (hq issue 340) | a key in the module's `servers` state — `all.<server>` for every node, `<node>.<server>` for one; every node watches it and renders what applies to it, a node's own entry over the one for every node. A node that joins later, or was off, reads the whole current set at start; unregistering is a delete. Nothing adds a key any more: a new tool server is the operator's, in the `mcp_servers` setting at the controller's terminal |
 | a proposed instruction section (hq ADR 0274) | a key in the module's `proposals` state per proposal, the ask published on `operator-channel` under this module's name, and the router's record of it read under that name alone; what a node approved is its own file, never the bus |
 | a session's question to the operator (hq ADR 0332) | a key `q-…` in the module's `questions` state per question, the ask published on `operator-channel` under this module's name, and the router's record of it read under that name alone; the router's word that it ended without a choice is kept on the question; two slot keys `slot-1`, `slot-2` name the questions open |
+| a project's memory (hq ADR 0343) | a key in the module's `memory` state per file — `<kind>.<project and path, base64url>`, `operator` for the operator's own homes and `agent` for an agent account's — holding the text, its digest, the digest of the version it replaced, the node and when it changed; a removal is a value marked removed, never a deleted key. Written at the revision read, so of two nodes writing one file only one wins. Every node of the same kind watches it. No event and no tool answer carries memory text |
 | the agent's configuration (hq ADR 0216) | a key in the module's `config` state per registration — `mesh.<kind>.<name>` for every node, `node.<node>.<kind>.<name>` for one, `home.<node>.<kind>.<name>` for one account's own directory — the item and its files in one value, at most 256 KiB. Every node watches it and renders what applies to it, a node item over a mesh item of the same kind and name. A hook, settings, or an item that would run something by itself is never taken, whenever it was put there (hq issue 340) |
 
+## A session's memory follows the operator (hq ADR 0343)
+
+A session started on another node starts with what the sessions on every other node learned (hq issue 367). The
+module's long-running process carries each project's memory folder, `~/.claude/projects/<project>/memory/`, and
+nothing else of the home:
+
+- **Picked up** every ten seconds: a file whose text differs from the version last carried goes into the `memory`
+  state. Not carried, and listed with why: a symbolic link, a file over 128 KiB, and a file holding a key block, a
+  signed token, a known token prefix or a password in an address.
+- **Written** on every other node of the same home kind, only where its file is still the version the change
+  replaced, or there is none; staged in the folder and renamed in, never through a symbolic link. The version
+  replaced is kept first in `memory-copies/` in the module's state directory, 30 days.
+- **A file changed on two nodes** becomes one file holding both, the newer first, then a line naming each version's
+  node and time, then the older; that file is carried, so every node ends on it, and the operator is warned through
+  the operator channel's `notify` (a warning, cleared when the file next changes without a conflict).
+- **A removal** of a carried file, from a folder that still exists, is a marker in the state for 30 days: a node still
+  holding the removed version moves it into the copies; a node that changed it keeps it and carries it again. A
+  missing folder, a key the state lost and a deleted key remove nothing.
+- **The two home kinds never mix**: the operator's own homes carry among themselves, an agent account's among
+  themselves (hq ADR 0266), so a confined agent's notes never reach a session run as the operator.
+- **No tool writes memory** (hq issue 340): `claude_code_memory` only lists what is carried — fingerprints, never the
+  text — the files not carried, the open conflicts and the copies kept. A value put straight into the state by a
+  holder of a tool runner's credential is not yet told apart (hq issue 638).
+
 ## The mesh's tools first (hq ADR 0245)
 
 The agent kept reaching for `ssh <machine> journalctl` while the service manager's `journal` verb existed. So: