The most useful distinction here is between code state and decision state. Git tells the next agent what survived, but it often cannot tell it which alternatives were deliberately killed along the way.

I’d take this one step further and treat rejected approaches as constraints with an expiration condition. A workaround may be rejected because of a production incident today, but that reason can become invalid after a dependency, architecture, or traffic pattern changes. Recording not just “don’t do this” but why, under which conditions, and when to revisit it would make project memory much more actionable.

That turns a simple Markdown file into something more valuable than context it becomes a lightweight record of architectural decisions and their assumptions.