A code map is only trustworthy if it reflects your current code. vg status tells you whether it does — reporting freshness, size, staleness, and how the map was resolved. This article explains each part of the output and how to act on it.
Overview
vg status compares the committed (or built) graph against your current working tree. It reports node and edge counts, whether the graph is stale relative to your code, and the resolver rungs that were used to build it. In short, it answers: “Is my code map current, and how big is it?”
Prerequisites
A code map should exist. If not, build one:
vg build
Check status
vg status
Read the output as a health check:
- Node and edge counts describe the size and connectivity of the map.
- Staleness tells you whether the graph lags behind your working tree. A stale graph means recent edits are not yet reflected.
- Resolver rungs indicate how thoroughly the code was resolved when the map was built.
Acting on staleness
If vg status reports the graph is stale, rebuild it so downstream queries are accurate:
vg build
Then re-run vg status to confirm it is current. Keeping the graph fresh ensures that vg map, vg hubs, vg ask, vg impact, and the rest operate on up-to-date structure.
Using status in workflows
vg status is a natural gate. Before you rely on graph output — in a review, a refactor, or a pipeline — run it to confirm the map matches the code. For automated use, see graph status in CI.
Related
- Build or update the map with
vg build. - Make the map committable with
vg share. - Get a structural overview with
vg map.
Status is computed entirely from local artifacts and your working tree.