Markdown memory backend (#44 Phase A)

[rdwj]

Addresses #44 Phase A.

Fills the Level-1 / Level-2 gap in the memory backend lineup — a human-readable, git-committed memory store for agents whose memory a developer wants to eyeball and edit by hand.

Design summary

Two modes selected by config:

• Level 1 (file: ./memory.md) — one compound markdown doc, each memory is a ## <heading> section. The Karpathy LLM Wiki pattern.
• Level 2 (dir: ./memories) — one .md file per topic, filename (without extension) is the memory id. Use when you have multiple functional areas to curate separately (e.g. standing instructions vs project memories).

Same backend, same code, the config picks which mode.

Memory IDs = section headings (Level 1) or filename stems (Level 2). The LLM can both append (write) and edit (update) using human-readable addresses rather than opaque UUIDs.

search(query="") returns every section/file in stable file order, intentionally designed for cache-friendly injection: agents load the whole memory set once at session start and inject it as a stable prefix so token positions don't shift between turns. Non-empty queries do a case-insensitive substring filter without ranking — no index, no magic. If you need ranked retrieval, jump to the sqlite backend.

report_contradiction is a log-only no-op; the human edits the file to resolve.

Positioning vs other backends

Added a decision tree to docs/architecture.md Memory Integration section:

Does this agent need memory across sessions?
├─ No  → backend: null
└─ Yes → How will you curate it?
   ├─ I'll read and edit the file by hand, commit it to git
   │  ├─ One topic       → markdown, file: ./memory.md    (Level 1)
   │  └─ Multiple areas  → markdown, dir:  ./memories      (Level 2)
   ├─ Agent needs searchable memory on one host → sqlite   (Level 3)
   ├─ Multiple agents share memory / vector     → pgvector (Level 4)
   └─ Audit trails, RBAC, retention             → memoryhub (Level 5)

Each jump is a real jump, not a sliding scale of features. Users should recognise themselves in exactly one row.

What this PR deliberately does NOT build

• No search ranking beyond file order (use sqlite)
• No regex (use sqlite)
• No per-section frontmatter/metadata (it's sqlite in a costume)
• No multi-level directory trees (flat dir only)
• No auto-injection into BaseAgent.build_system_prompt — that belongs in the separate memory-prefix-slot follow-up (#47) because it applies to all backends, not just markdown

Scope-discipline check

Single-file module, no new runtime deps (pyyaml already present), pattern mirrors memory_sqlite.py / memory_pgvector.py exactly. The custom backend remains the escape hatch.

Test plan

• 36 new tests in test_memory_markdown.py — factory (both modes, missing/malformed/both-keys/neither-key configs, relative paths), Level 1 write/search/update, Level 2 write/search/update/unsafe-filename rejection, stable sort order, dispatcher integration
• Full fipsagents suite 429/429 green (393 previously + 36 new)
• gitleaks clean

Follow-ups

• #47 — BaseAgent first-class stable memory-prefix slot so the cache-friendly injection pattern works across all backends
• Memory-layer-agnostic scaffolding: markdown + LlamaStack backends, CLI selector #44 Phase B (LlamaStack memory backend) — unchanged plan; can proceed whenever the LlamaStack endpoint from Validate BaseAgent against LlamaStack as inferencing endpoint #42 is the right starting point