Field report: 5 failure modes from 2 months of file-based Claude Code memory

I've been using Claude Code daily for ~2 months on a dozen solo projects, and built a file-based persistent-memory system around it (auto-loaded index + one-fact-per-file memory + enforcement hooks). The interesting part isn't the architecture — it's the five ways it broke, each one a real documented incident:

1. A written rule is an instruction, not a barrier — only hooks block. A rule in CLAUDE.md, correct for one runtime version, silently broke an older version still in production. The model followed it perfectly; the rule was wrong.
2. An unsourced AI claim stored in memory becomes a toxic "fact." Almost built an entire engine on a hallucinated algorithm a review model asserted confidently.
3. History and actionable state are two different files. A rich session log still couldn't answer "what's waiting on me right now?"
4. An automation without a verified heartbeat dies silently. Three automations presumed running were all dead — one had never fired once.
5. Two files with the same name = guaranteed drift, and filesystem dates lie.

For context: I deliberately hand-rolled the memory and versioning layers — no Git, no memory framework — to fully understand the problem before reaching for tools. That's why every failure here is first-hand. Having learned the hard way, I'm now likely to adopt Git for the versioning layer to save time.

Lessons, architecture, the two enforcement hooks (anonymization pre-commit + heartbeat check) and memory templates: https://github.com/AgathoZorya/curiositystar-agent-memory

Full disclosure, noted in the repo: the prose and code were written by Claude itself, working inside the live system.