rememberlisted

# Write down why The code says what. The git history says when. Neither says **why**, and why is the expensive part to reconstruct — usually at the moment somebody is about to undo it. ## When to write an entry Write one when the answer to "why is it like this?" took real work to arrive at, and would take real work to arrive at again. Good reasons to write: - a choice was made between two viable options and the loser is not obvious from the code - something was tried, failed, and the failure is not visible in the repository - a constraint exists that a newcomer would break without knowing Do **not** write an entry when: - the code already says it — a well-named function does not need a memory entry - the git history already says it — a good commit message is the right place for "what changed" - it is a task, not knowledge — that is `STATE.md` or a session record - it is a procedure — that is `/chamnan:capture` **This is not a conversation log.** Never paste a transcript. Write the conclusion. ## Pick a category The three are used differently, which is why they are separate: | | | | |---|---|---| | `decisions/` | A choice and its reasoning | *"Postgres over SQLite — two writers, and SQLite's locking showed up under load."* | | `lessons/` | Something that cost time once | *"Editing `src/` while the app runs throws an AttributeError. It is a hot-reload artifact, not a bug — restart clears it."* | | `rules/` | A standing constraint | *"Never add a Cloud fallback for em