[ docs · concepts ]
The code map
The code map is a graph of your repository: files, symbols, and routes as nodes; calls, imports, and route bindings as edges. The agent reads the map to see the blast radius of a change instead of grepping blind.
How it's built
The map is generated by the Graphify provider and stored in the project at graphify-out/graph.json — a file in your repo, inspectable like any other artifact. Nothing about it is hidden server-side state.
How the agent uses it
- Seeded subgraphs. A query starts from a seed — a file, a symbol, or a route — and walks outward with a hop limit and a token cap. The agent gets the neighbourhood that matters, not the whole graph and not a pile of grep hits.
- Ranked by degree. When context is packed, nodes are ordered most-connected first. The landmarks of the codebase — the files everything touches — are the first thing the run learns.
- Routes are first-class. Symbol graphs miss framework routing: which handler actually serves an endpoint. The map includes a route graph, so route bindings are edges like any other.
Optional, and visible
If a project has no map, Grist works fine without one — the map is an accelerant, not a requirement. And it isn't agent-only plumbing: the desktop app shows the map's landmarks, its most-connected nodes, in the code-map card, so you can see the same picture the agent navigates by.
Grep finds text. The map finds consequences.