todo: understand claude and opencode memory, then centralize into a vector db

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

todo/memory/_index.md

@@ -0,0 +1,9 @@
+---
+theme: memory
+heading: 'Memory — one store instead of per-harness files'
+kind: theme
+---
+
+How each coding harness remembers things today (Claude's `CLAUDE.md`/memory files, opencode's own
+mechanism, whatever else joins later), and whether that should be one shared store instead of N private
+ones. Related: `todo/affordances/` is the delivery mechanism this theme will need.

todo/memory/understand-and-centralize-agent-memory-into-a.md

@@ -0,0 +1,32 @@
+---
+id: memory/understand-and-centralize-agent-memory-into-a
+title: 'Understand how Claude and opencode do memory, then centralize both into one vector database'
+theme: memory
+status: open
+created: 2026-08-25
+date_source: stated
+order: 1
+---
+
+**Understand how Claude and opencode do memory, then centralize both into one vector database.** Wanted
+2026-08-25. Two steps in order, and the second should not be started before the first is actually
+answered rather than assumed:
+
+1. **Understand what "memory" means for each harness, as it exists today.** For Claude that is this
+   platform's own memory system (`~/.claude/projects/*/memory/`, `MEMORY.md` plus per-topic files — the
+   mechanism this very session uses) and whatever `CLAUDE.md` files and file-based conventions the SDK
+   itself reads. For opencode — wired into this platform (`sidecar/opencode/`) but not deeply understood
+   by this session — the equivalent needs the same audit: where does it read and write anything durable
+   about a session or a user, and does it call that memory at all or something else entirely.
+
+2. **Centralize into one vector database**, so both harnesses (and whatever joins later) read and write
+   the same store instead of each keeping its own files. **Needs an affordance per harness**, teaching it
+   NOT to use its native memory mechanism and to use the shared store instead — the same delivery
+   mechanism already used to teach Claude sessions about image rendering and gitea
+   (`capabilities/affordances/`, loaded per turn, no restart).
+
+Open, deliberately not decided here: which vector database; what gets embedded (raw notes, summaries,
+both); whether centralization REPLACES each harness's native memory outright or sits ahead of it as a
+retrieval layer the harness is told to consult first; and how a memory tied to one user account maps
+onto a store meant to serve every harness the same account uses. Step 1 should surface most of these —
+this is exploratory before it is a build.