Auto-memory (MEMORY.md) gets corrupted across sessions, causing cascading bad answers

Problem

The auto-memory file (memory/MEMORY.md) that persists across conversations has no protection against being overwritten with incorrect or partial information. When one session writes bad data to memory, every future session reads it and anchors on the wrong context, producing increasingly worse answers.

What happens:

1. Session A reads some project files, writes a summary to memory/MEMORY.md
2. That summary is incomplete or contradicts other project docs (session only read 1 of 10 relevant files)
3. Session B starts, reads MEMORY.md first (since it's auto-loaded), and anchors on the wrong information
4. Session B gives answers that contradict the project's actual documentation
5. User has to spend tokens correcting Session B, which may then "fix" MEMORY.md with yet another partial understanding
6. Cycle repeats

Related behavior issues when context gets complex:

• Pattern matching instead of understanding: Model latches onto specific keywords in the question instead of processing the full context. Gives answers about the keyword, not the actual question.
• Dropping CLAUDE.md rules: When confused, the model stops following the project's CLAUDE.md instructions (communication style, depth requirements, pushback rules) and falls back to generic short answers.
• Making up answers instead of reading existing files: Even when extensive documentation exists in the project, the model generates answers from its own knowledge instead of searching and reading the docs first. This is especially wasteful on expensive models (Opus).
• Anchoring on one file: After reading one document, the model treats it as complete truth and ignores other files that provide different or more complete information.

The cost problem:

On Opus/Max plans, these bad answers consume significant tokens. The user pays for 3-4 rounds of corrections that wouldn't be needed if the model had read the docs first or if memory hadn't been corrupted.

Suggested improvements

1. Memory file protection: Allow users to mark MEMORY.md as read-only or require explicit user approval before any edits to memory files.
2. Memory editing rules: Respect rules written inside the memory file itself (e.g., "do not edit without verifying against docs"). Currently these are best-effort — the model sometimes ignores them.
3. Doc-first behavior: When a project has extensive documentation (50+ files in docs/), prioritize reading existing docs over generating answers from model knowledge. A simple heuristic: if the user asks about architecture/pricing/features and a docs/ folder exists, search it first.
4. Anti-anchor mechanism: When reading project context, flag when multiple documents might be relevant and cross-reference before answering, rather than anchoring on the first file read.

Environment

• Claude Code on Windows
• Model: Opus
• Project with 85+ documentation files across multiple folders