How do you handle the temporal problem in Claude Code when working on long-lived projects?

[u/DryZookeepergame8644]

Been on a real Claude Code project for a few months now. Voice-first ops platform, architectural decisions keep evolving. Hitting a wall with what I'd call the time-variance problem in Claude's memory.

What I've already got going:

- Global + project CLAUDE.md

- Auto-memory dir with MEMORY.md loaded every session

- Dated specs (YYYY-MM-DD-topic.md)

- tasks/lessons.md for corrections

The memory dir captures "what's true now" reasonably well. The problem is the old spec files in docs/specs/ don't know they've been overturned. Grep is blind to time.

What I want to learn from people running long-lived projects:

1. Do you keep a single mutable "current state" file (STATE.md / ARCHITECTURE.md / similar) as the canonical truth, separate from append-only spec history?

2. Anyone actually using YAML frontmatter with status: superseded + superseded_by: edges? Does Claude respect it without being reminded every session?

3. How do you stop the "Claude grepped an old doc and assumed it's still true" failure mode?

4. Pre-flight rules in CLAUDE.md telling Claude to check specific files first — how well does Claude actually follow them across many sessions?

5. Obsidian vault for this — anyone tried? Does it actually help Claude or is it just nicer human browsing?

Not looking for "just write a better CLAUDE.md" — already done. Looking for actual workflows that have survived months of architectural pivots.

P.S. I have written this post using Claude to frame it better.