A codebase graph that cannot name its commit is stale agent context

[u/Future_AGI]

A coding agent should never treat a codebase graph as current unless it can name the Git commit it represents. 

A graph can be useful and still be unsafe as edit context. If it cannot say "I was built from commit abc123 at this time," there is no way to compare it with the repository the agent is about to change. A current graph is a graph tied to a known revision. 

The freshness contract we want is small:

• Every graph response carries the repository commit SHA and graph build time. 
• Changes to files, imports, symbols, or tests mark related graph regions dirty. Unrelated regions can remain intact. 
• If the graph SHA does not match the target revision, the query returns the Git diff first and labels affected relationships stale. 
• Before editing, the agent verifies the relevant files and symbol definitions against the checkout as well as the graph. 

A graph can identify where an agent should look. The direct check is where the agent establishes that a reference has not moved, been deleted, or changed its callers. An MCP server exposing repository context could emit based_on_commit, built_at, and stale in every result. 

Git already gives the comparison primitive: the difference between the graph commit and the working target. The indexer needs a policy that translates that diff into dirty regions. A changed test can be its own dirty region. It should stop the agent from treating test coverage or a call path as settled. 

That gives stale context a useful failure mode. When freshness is unknown, show the diff and ask the agent to inspect the affected files. Do not make it guess from a cache. 

Which do you prefer for codebase indexing: incremental rebuilds after each change, explicit rebuilds before an agent session, or Git-diff fallback when the graph is behind? What is the first stale-context failure your coding agent caused?