Keeping memory from going stale: what's your pruning / consolidation loop?

[manja316]

Once you've been running claude-code-memory for a few weeks, the failure mode flips. Early on the problem is "Claude forgets everything." Later it's the opposite: the memory grows stale and starts actively misleading you.

A few ways I've watched this bite:

• A memory file names a function/flag/file that got renamed or deleted three commits ago. Claude recalls it and confidently recommends something that no longer exists.
• Two files end up describing the same fact slightly differently, and recall surfaces whichever one matched the query — sometimes the wrong one.
• MEMORY.md (the index that loads every session) bloats to the point where it's eating context budget for facts that are no longer load-bearing.

So the question for people running this in anger: what's your hygiene loop?

Specifically:

1. Cadence — do you prune on a schedule (weekly?), on a trigger (every N new memories), or never until it hurts?
2. Staleness detection — anything automated? e.g. a pass that greps each memory for the symbols it references and flags the ones whose targets no longer exist in the repo.
3. Merge vs delete — when two memories overlap, do you consolidate into one canonical file or just delete the weaker one?
4. The index — how do you keep MEMORY.md from becoming a second source of truth that drifts from the files it points at?

My current rule of thumb: treat every recalled memory as true-when-written, not true-now — if it names a concrete file/function/flag, re-verify it still exists before acting on it. That's a band-aid though; it pushes the cost to read-time instead of fixing the rot.

Curious whether anyone has a cleaner pattern — a reflective "consolidate" pass that merges duplicates, fixes stale facts, and prunes the index in one go feels like the right shape, but I'd like to hear how others are actually doing it.