Auto-memory system is ineffective: memories not reliably read or acted on across sessions

Summary

The auto-memory system (file-based memory at ~/.claude/projects/.../memory/) does not reliably influence model behavior across sessions. Memories are written but not acted on, making the system effectively useless for enforcing behavioral constraints.

Observed failure pattern

1. User corrects a behavior (e.g. "always read source data before writing a DB schema")
2. Model writes a memory file capturing the constraint
3. In subsequent sessions, the same mistake recurs — identical correction needed again
4. Model acknowledges the memory exists but did not apply it

This has been observed repeatedly in this project. Specific examples:

• Memory written: "read source data before writing any DB migration" — violated in the same and subsequent sessions, requiring the user to raise the same schema gaps 4-6 times per data type
• Memory written: "show full test output" — intermittently ignored
• Memory written: "own your code, never use passive voice to deflect authorship" — periodically reverts

Root causes (as observed)

1. Context compression — the MEMORY.md index is loaded but individual memory files are not pre-loaded; after context compression, previously-read memory files are gone and the model does not re-read them
2. No enforcement — memories are advisory; the model can acknowledge a memory exists and still not apply it
3. The index is what gets loaded, not the content — MEMORY.md is a one-line summary per memory; the actual constraint is in the file body, which may not be read
4. No verification step — nothing checks whether a relevant memory was consulted before a tool call that the memory governs

What actually works in this project

The user has a hook system at ~/.claude/hooks/ (PreToolUse, PostToolUse, Stop hooks) that blocks tool calls and enforces constraints mechanically. Hooks work. Memories do not.

Expected behavior

If a memory says "do X before writing migrations," the model should not be able to write a migration without having done X. The memory system needs either:

• Mandatory pre-tool-use enforcement (not advisory loading)
• Automatic re-injection of relevant memories before tool calls that the memory governs
• Or honest documentation that memories are best-effort hints, not behavioral constraints — so users know to use hooks instead

Impact

Users write memories expecting behavioral change, get none, and lose trust in the system. The recourse is to rebuild the enforcement using hooks, which requires technical knowledge most users don't have.