I told Claude Code to keep a running log file of its own decisions and my compaction problems mostly went away

Sharing a small habit that changed how long I can stay in one Claude Code session before things fall apart.

The problem I kept hitting: on a longer task, once the context gets compacted, Claude forgets the reasons behind choices it made earlier. Not the code, the code is still there. The reasoning. Why we picked the queue over cron, why a certain field is nullable, why we backed out of an approach that looked obvious. After a compaction it would happily suggest the exact thing we'd already ruled out two hours ago, and I'd have to relitigate it.

What I do now is tell it, in the CLAUDE.md, to append to a DECISIONS.md file every time we make a non-obvious call. One line per decision: what we chose, what we rejected, and the one-sentence reason. Not documentation for humans, more like a scratchpad for future-Claude.

The trick that makes it actually work is that I also tell it to read DECISIONS.md at the start of any planning step. So after a compaction, when it's lost the conversational memory, the reasons are sitting in a file it reloads on purpose. The file survives what the context window doesn't.

Concrete example from this week. Mid-migration, four hours in, post-compaction, it started to "helpfully" reintroduce an ORM call we'd deliberately dropped for a raw query because of a lock issue. Instead of me remembering and explaining, it checked the log, saw the line "rejected ORM here, holds a lock too long under batch, use raw query," and just kept going correctly.

It's not a memory system. It's the model writing its own notes to a place the compaction can't reach, and being told to look there. Cheap, no MCP, works today.

Anyone doing something similar with a structured format for the entries? Mine is freeform and I suspect a stricter shape would help it parse its own history faster.