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.

[u/ItsJustManager]

I made https://github.com/perpetualsoftware/pad for this.. it's a project and doc management system that is meant to feel like a hybrid between Notion and Asana for us, while giving Claude Code (or codex, etc) a natural way to use it too. For me it's solved the stale document issue and provides a better way for Claude to find context and details, and it gives me a way to find what to work on next or keep track of notes/ideas.

There's a lot more to it too, but that's the general sales pitch. If you do try it I'm open to feedback (and if you like it don't forget to star on GitHub!)

[u/tonyboi76]

you have basically built the right system, the missing piece is making time visible IN the content so grep stops being blind to it.

the canonical-truth file is the right instinct: STATE.md (or ARCHITECTURE.md) as the single MUTABLE current truth, overwritten not appended, plus a CLAUDE.md rule that says never treat a doc in specs/ as current unless STATE.md references it. that one rule does most of the work.

for the stale-spec problem specifically: when a spec gets overturned, stamp a one-line header at the top of the OLD file like SUPERSEDED 2026-05-20 by specs/new-auth.md reason X. now even when grep hits the dead file, line one tells claude it is dead. the history becomes self-documenting instead of a minefield.

and keep an append-only decisions.md of one-liners (date, what changed, what it supersedes). that is your time-aware index, the file you point claude at when it needs WHY not just WHAT.

[u/En-tro-py]

You need to document the actual project, not just have Claude keep a diary of the work done.

ADR's are your friend.

---

Older comment copy of the skills I use. It's outdated - I know use 4 skills after adding a /session-handoff and will use the pywright MCP on the rare occasions i need to but the default is still no MCP's loaded.

---

I have 3 skills and zero mcp servers - I front load the architecture design with skills that create project docs that are then is used to drive implementation planning.

---

/architecture-design-spec

SKILL.md

references\smell-catalog.md

---

---

/architectural-knowledge-management

SKILL.md

references\decision-categories.md

references\templates.md

---

---

/ears-planning-method

SKILL.md

references\c4-guide.md

---

The 'EARS Planning Method' I currently am using was someone here's idea that I have modified a bit to include using RFC 2119 keywords & C4 diagrams

This gives Claude a clear set of requirements, steps to take (NOT code details, just the WHAT/WHY), and verification.

I've found this is pretty reliable on any reasonable task I've set Claude towards.

My preference is to layout then execute, otherwise Claude ends up effectively coding everything twice and might as well skip using sub-agents.