Repository Memory That Survives Code Changes

Repository memory becomes useful when it helps an agent find the reason behind the code. It becomes harmful when an old summary is treated as a current description of files that have moved or APIs that have changed.

Store durable rationale separately from snapshots of implementation. A decision can remain relevant after a refactor, while a remembered file path may become invalid within hours.

Anchor a note to evidence

For a repository fact, retain a source path, revision reference, and the question the note answers. For a design decision, link to the maintained record or change that explains it. Make the distinction visible: “this file contained the handler at revision A” is narrower than “this is always the handler.”

Do not copy secrets, credentials, or large private logs into memory merely because the coding agent encountered them. Capture the minimum useful explanation under the repository's access rules.

Revalidate before acting

When a task depends on an old note, inspect the current repository. If the path moved, follow the code and update the reference. If the old decision conflicts with a new implementation, preserve the conflict rather than silently assuming the note is correct.

Memory should reduce the search space, not replace reading the source. The coding-preference guide covers a related problem: old conventions being applied to the wrong project or task.

Handle branches and projects deliberately

A note derived from an experimental branch may not describe the default branch. Preserve the relevant revision and project scope. Shared team decisions and one developer's temporary investigation notes need different visibility and authority.

If several agents work on the same repository, capture the result of a completed change separately from an intention to make that change. “Patch prepared” and “merged” are different states; a later agent should not skip required work because a summary blurred them.

Test the refresh behavior

Create a harmless fixture with a function that moves, a renamed configuration key, and a rejected design alternative. Start a new session after changing the code. Check whether the assistant verifies the path and still recovers the useful rationale.

Then ask an unrelated project the same question. Repository memory that leaks across scopes can be confidently wrong even when every stored note was accurate at capture time.

If the agent accesses memory through files, review the filesystem memory design for path, permission, and provenance behavior.

For setup, use the Supermemory Claude Code integration alongside maintained project instructions. Begin with one repeated investigation and measure whether the next session finds current evidence with less reconstruction.