reader/skills/reader-digest-flow/references/memory-drift-recovery.md

Memory Drift Recovery

Symptom

store_memory(action="add", ...) fails with:

Refusing to write MEMORY.md: file on disk has content that wouldn't round-trip through the memory tool...

A .bak snapshot is created: /root/.hermes/memories/MEMORY.md.bak.<timestamp>

Root Cause

The MEMORY.md file format doesn't match what the memory tool expects — likely because the file was modified externally (by patch, write_file, shell >> append, or a concurrent session). The tool uses a § (section sign) delimited format internally and its serialization/deserialization doesn't match the on-disk content.

Recovery Procedure

Step 1: Read the backup and the current file

diff /root/.hermes/memories/MEMORY.md.bak.<timestamp> /root/.hermes/memories/MEMORY.md

Step 2: Extract missing entries (if any)

# List entries from the backup
grep '^§' /root/.hermes/memories/MEMORY.md.bak.<timestamp>

Step 3: Re-add each missing entry via store_memory

For each entry that was in the backup but is now gone from the current file:

store_memory(action="add", content="<entry text>", target="memory")

Step 4: Reset to a clean state

If the file is completely corrupted, the cleanest path is:

1. Save any new entries from the backup you want to keep
2. Rewrite the file as a clean §-delimited list (one entry per § line)
3. The format is: §<content>\n per entry, with --- or blank line separators

# Example clean format:
echo '§当前重要条目一
§当前重要条目二
§当前重要条目三' > /root/.hermes/memories/MEMORY.md

Prevention

• Do NOT use write_file or patch to modify MEMORY.md directly — always use store_memory()
• Do NOT use shell >> to append to MEMORY.md
• If you must bulk-import, use store_memory per-entry, not file-level operations

Environment

• Host: Linux (5.15)
• Hermes home: /root/.hermes
• Memory files: ~/.hermes/memories/MEMORY.md, ~/.hermes/memories/USER.md