# 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

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

### Step 2: Extract missing entries (if any)

```bash
# 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:
```bash
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

```bash
# 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`