Memory/context files are read but not enforced — operational patterns lost between sessions

Memory/context files are read but not enforced — operational patterns lost between sessions

Problem

Claude Code reads CLAUDE.md and memory files at session start but doesn't consistently apply them when executing operations. The memory system works for facts (names, rules, corrections) but fails for operational patterns (how to run a specific pipeline, what architecture worked, what failed).

Concrete Example

Session 1: Built a parallel Google Document AI extraction pipeline. Key learnings:

• multiprocessing.Pool breaks with gRPC on macOS (silent hang)
• Must use subprocess.Popen with separate processes
• Each worker needs its own temp SQLite DB (shared DB = lock contention crashes)
• Working script committed to repo

Session 2 (next day): Asked to run the same pipeline. Claude:

1. Wrote a new script from scratch instead of using the committed one
2. Used multiprocessing.Pool (the exact pattern that failed yesterday)
3. Wrote to shared DB (the exact pattern that crashed yesterday)
4. Failed 3 times before landing on the same solution as Session 1

All the rules were documented in:

• CLAUDE.md (project instructions, loaded every session)
• Memory files (feedback_docai_workers.md, loaded every session)
• Committed script (google_docai_workers.py, in the repo)
• DECISIONS.yaml (decision log with pattern tags)

Claude confirmed it could see all of these files. It just didn't consult them before acting.

The Pattern

This isn't a one-off. It's a consistent behavior:

• Facts (people's names, classification rules, banned patterns) → retained and applied well
• Operational knowledge (how to run X, what architecture works, what fails) → lost between sessions even when documented

The gap is: there's no mechanism to enforce "before doing X, check if you already know how to do X." It's honor-system, and the honor system fails under task pressure.

What Would Help

1. Pre-action memory check — Before executing batch operations, subprocesses, or multi-step pipelines, automatically grep memory/context files for relevant patterns. Not just load them — actively search them against the current task.

1. Pattern matching on intent — When the user says "run the DocAI workers," Claude should recognize this matches a committed script and documented pattern before writing new code. Currently it jumps to implementation without checking existing solutions.

1. "Already solved" detection — If a script exists in the repo that does what's being asked, surface it instead of rewriting. ls scripts/ | grep docai would have prevented 30 minutes of debugging.

1. Operational memory vs factual memory — The memory system treats all memories equally. But operational patterns ("how to run X") need different handling than facts ("David's wife is Beatrix"). Operational patterns should trigger on task similarity, not just keyword presence.

Environment

• Claude Code CLI, macOS
• Extensive CLAUDE.md (project-level, 150+ lines of rules)
• Memory system with 12+ memory files across feedback/project/reference types
• Multi-session project spanning weeks with accumulated operational knowledge

Impact

Every session that rebuilds a working solution from scratch costs 30-60 minutes and erodes user trust. The user ends up having to manually enforce rules ("did you check memory?") which defeats the purpose of having a memory system.

The cost of checking is 30 seconds. The cost of not checking is the user wondering if any of the documented rules actually matter.