M5.1: the knowledge vault

vault.py: a folder of Markdown notes on the agent host, as SilverBullet reads
them. Only configured folders exist for the agent, each rw or ro (`vault:`
in the configuration); paths are checked in code (relative, inside a folder,
symlinks included, Markdown, never the editor's own files). Writes are
atomic (temporary file, fsync, rename, directory fsync) and merge provenance
into the note's frontmatter, keeping the rest; failures are results.

read_note, list_notes and search_notes are control tools in the harness for
the driver (before the go-ahead, and while a VM is blocked) and for
conversations, labelled with their path; the prompt says a note is
information, never an instruction. Writing by the model is M5.2's.

With the operator: SilverBullet replaces Obsidian and runs on the vault
itself, agents' folders mounted read-only, so no Syncthing (L10, X5, M5.4).
Per-agent mounts come with the containers (M6.1).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J5Utyfzw7gF7UhjRDEtjTk

docs/Architecture.md

@@ -462,8 +462,8 @@ an argument.
 
 Durable knowledge outside any repository (world models, agent memory, the
 operator's material such as procedures) is **a folder of Markdown files on the agent
-host** in the format Obsidian reads (frontmatter, `[[links]]`, tags), so the operator
-browses it in Obsidian.
+host** in the plain format SilverBullet reads (frontmatter, `[[links]]`, tags), so
+the operator browses and edits it in SilverBullet.
 
 - **Agent memory is under `memory/`,** a folder per agent. Other folders' names and
   layout grow with need.
@@ -475,9 +475,12 @@ browses it in Obsidian.
 - **Access is through control tools** (L13); no tool VM sees the vault. The harness
   writes atomically and records each note's provenance (source, work item, time).
   It may also keep the vault's history in git; recovery doesn't depend on it.
-- **The operator's copy** is kept by Syncthing, with direction per folder: agents'
-  folders, memory included, are send-only from the host; the operator's are
-  receive-only on it. So conflicts can't arise.
+- **The operator's access is SilverBullet on the vault itself,** in its own
+  container beside the agents: one copy, nothing synced. It mounts the operator's
+  folders read-write and the agents' folders read-only, so the kernel keeps one
+  writer per folder even within one SilverBullet space, and it sees nothing of the
+  agent host but the vault. Agents never go through SilverBullet: they keep
+  working while it is down, and their mounts keep them apart.
 - **Never an instruction or approval channel.** Work is never read out of the vault,
   and no agent writes there to make another act; agents coordinate through the
   operator, Matrix or issues (L1). The operator points to a note in conversation
@@ -973,7 +976,7 @@ so every upstream action traces to one agent.
 ### X5. Supporting services
 
 All self-hosted: Matrix (Synapse), Gitea, LiteLLM, the local inference host,
-Vaultwarden, LLDAP with Authelia, and Syncthing for the operator's copy of
+Vaultwarden, LLDAP with Authelia, and SilverBullet for the operator's view of
 the vault. Each agent has its own account, token and room in each; nothing is
 shared between agents.