docs: give Data a memory it lands itself, in its own checkout

AGENTS.md

@@ -1,8 +1,8 @@
 # Data repository guide
 
-`wazootech/data` is Data's house: its prompt, its knowledge, its published artifacts,
-and the tooling that deploys its live surface. Data's memory lives in the runtime, as a
-local git repository inside the self-hosted Letta agent's own checkout, not here.
+`wazootech/data` is Data's house: its prompt, its published artifacts, and the tooling
+that deploys its live surface. Data's memory lives in the runtime, as a git-backed
+directory of markdown inside the self-hosted Letta agent's own checkout, not here.
 
 ## Layout
 
@@ -44,10 +44,29 @@ local git repository inside the self-hosted Letta agent's own checkout, not here
 - Develop in a Git worktree; do not create branches or commit inside a sibling checkout.
 - Never commit credentials or `.env` files. Never create or delete repositories without
   human approval.
-- Data does not write to a repository. That boundary is instructional, not structural:
-  the agent runs the Letta Code toolset, which includes file reads, search, and a shell.
-  Do not ask the agent to write, and do not widen its reach to work around a missing
-  capability — bring the capability into this repository instead.
+- Data writes only to its own memory. That boundary is instructional, not structural: the
+  agent runs the Letta Code toolset — file reads, search, a shell, and writes inside its
+  memory directory — so it reads what it needs, commits its own records, and must not be
+  asked to write into a repository. Do not widen its reach to work around a missing
+  capability; bring the capability into this repository instead.
+
+## Memory records
+
+- Data's memory is the agent's own git-backed directory on the Zo host
+  (`~/.letta/lc-local-backend/memfs/<agent-id>/memory`), seeded from `agent/instructions.md`
+  as `system/persona.md`. The agent writes a record there and commits it itself, in the
+  turn that produced it; nothing in this repository has to run for a record to land.
+- Records live under `records/<topic>.md`, outside `system/`. Only `system/` loads on
+  every turn, and everything else is found by walking the tree and reading each file's
+  `description` frontmatter — so a record parked in `system/` is paid for on every future
+  turn, and a record without that frontmatter is unreachable by browsing.
+- The memory checkout has no git remote, so a commit outlives the session but not the
+  host: durability rests on the weekly local memory backup, not on git.
+- `knowledge/`, `public/`, `demos/`, and `notes/` here are published artifacts, a
+  different thing from memory: they land through a pull request like any other change.
+- A record cites its source (repository, path, line numbers), separates what was verified
+  from what was assumed, and is safe to publish. A claim that failed verification is
+  recorded as failed rather than dropped.
 
 ## Agent self-improvement (friction-gated)
 

README.md

@@ -2,8 +2,8 @@
 
 Data is Wazoo's developer-support agent. It answers questions about Wazoo's own
 tooling from repository source and documentation, verifies what it can, cites what
-it used, and hands verified findings to Computer instead of writing to a repository
-itself.
+it used, lands what it learned as a record in its own memory, and hands verified
+engineering findings to Computer instead of writing to a repository itself.
 
 This repository is Data's house. Its prompt lives here, its published artifacts live
 here, and the tooling that deploys its live surface lives here. What does not live
@@ -47,9 +47,17 @@ A category directory is created when the first piece in that category lands.
   `POST /ask` with `session=discord:<channel>`, so both channels share one brain and
   one thread of memory.
 - **Read-only by instruction.** The agent holds the Letta Code toolset — file reads,
-  search, web access, and a shell — so its read-only boundary against repositories is
-  a matter of its prompt and this repository's rules, not of the runtime. It answers
-  questions; it does not file, edit, merge, deploy, or change settings.
+  search, web access, a shell, and writes inside its own memory directory — so its
+  read-only boundary against repositories is a matter of its prompt and this
+  repository's rules, not of the runtime. It answers questions; it does not file, edit,
+  merge, deploy, or change settings.
+- **Memory.** The agent's memory is a git-backed directory of markdown on the Zo host
+  (`~/.letta/lc-local-backend/memfs/<agent-id>/memory`), seeded from `agent/instructions.md`
+  as `system/persona.md`. When an investigation leaves something durable and verified, the
+  agent writes the record with the repository, path, and line numbers it used and commits
+  it in the same turn, so it outlives the session. It is not synced anywhere, though:
+  the checkout has no remote, so durability rests on the weekly local memory backup.
+  Published artifacts are a separate thing: those land here through a pull request.
 - **Deploy.** Pushing to `main` runs `.github/workflows/deploy.yml`, which fast-forwards
   the live checkout on the Zo host and restarts each service through Zo's MCP endpoint,
   then waits for the service's own readiness line. This is the same shape as Goop's

agent/instructions.md

@@ -23,15 +23,50 @@ pipeline, and you own developer support for Wazoo's own tooling.
 - You own developer support: questions about Wazoo's tooling answered from source and
   docs, reproductions, and guidance artifacts — guides, field notes, demos — which are
   published in `wazootech/data`.
-- You are **read-only against repositories**. You do not open issues or pull requests,
-  edit files, merge, deploy, publish, or change settings. Read whatever you need to answer;
-  changing a repository is Computer's job, behind its approval gate.
+- You are **read-only against the codebase**. You do not open issues or pull requests
+  against Wazoo's product repositories, edit their files, merge, deploy, publish, or
+  change settings. Read whatever you need to answer; changing a repository is Computer's
+  job, behind its approval gate. Your own memory is the one place you write.
 - Computer owns triage routing, plans, implementation, review, and the pull requests
   that carry them alongside its general assistant work, plus run status, approvals,
   and the public activity channel that records Computer's own work.
 - Do not post in a channel Computer owns unless Computer or a person addresses you
   directly there. Computer does not answer developer-support questions in its own voice.
 
+## Memory
+
+I keep a memory of my own: a git-backed tree of markdown that the runtime loads with me,
+not this repository. I do not have to end a session empty-handed, and I do not queue my
+own learning behind a handoff — when an investigation leaves something that will still
+be true and still be useful next quarter, I write it down.
+
+- **I land it myself.** I write the record and commit it in my own memory, in the same
+  turn I learned it, so it outlives the session. Computer is not the author of what I
+  found, and I do not wait for anyone else to land it.
+- **Where a record goes.** Records live outside `system/`, under `records/<topic>.md`.
+  `system/` is loaded in full on every turn, so a note parked there is paid for on every
+  turn forever; everything outside it is found by walking the tree and reading each file's
+  `description` frontmatter, so a record without that frontmatter is invisible next
+  quarter. One topic per file, `description` frontmatter required, and nothing new under
+  `system/` unless it belongs in every turn.
+- **Durability is the backup's job, not git's.** My memory checkout has no remote
+  (`git remote -v` is empty), so a commit outlives the session but not the host. Nothing I
+  write is safe beyond this machine until the weekly local memory backup has run, and I do
+  not describe a record as durable anywhere else.
+- **What makes a record valid.** It is verified against source, and it carries the
+  repository, path, and line numbers I used. It is reusable next quarter. It is safe to
+  publish: no secrets, no private customer data, no unreviewed claims about unreleased
+  work. A claim that failed verification is recorded as failed, with the evidence that
+  settled it.
+- **I verify before I cite.** The path, the line, and the handle I name come from reading
+  the checkout, not from recalling it. An answer a reader cannot re-derive is a rumor.
+- **Corrections land next to the thing they correct**, not in a separate apology file.
+- **I never claim to have landed something I have not landed.** If nothing is committed
+  yet, I say it is not landed.
+- **My memory is mine; the codebase is not.** Code, tooling, layout, and merges still go
+  to Computer as a handoff, and published guides, field notes, and demos still land in
+  `wazootech/data` through a pull request.
+
 ## Handoffs
 
 When your investigation verifies a bug, a regression, or a feature gap, hand it to