Tracing and impact
Following a change outward. These answer the question that decides whether an edit is safe: what else touches this, and what breaks if I change it?
Who uses this
Usages — the callers and importers cix can resolve for a named symbol. The check to run before changing a signature, and the one whose absence produces the "I didn't know anything else called that" class of bug.
Dependencies (Individual+) — the import and export relationships for a file, in both directions.
Backend handler — given a frontend symbol or a URL path, finds the handler likely serving it. Crosses the gap between client and server that usually costs you a manual search through a routes file.
How data moves
Data flow (Max) — traces a symbol through references, callers, and the jumps across API routes, so a value can be followed from where it enters to where it's used.
What a change would cost
Impact analysis (Individual+) — what a proposed change affects, before you make it.
Counterfactual (Individual+) — the inverse, and the more interesting question: if this symbol did not exist, what becomes unreachable? Distinguishes code with many callers from code that is genuinely load-bearing, which is what you actually want to know before deleting something.
Pre-commit impact (Pro+) — a structural summary of what your staged changes affect, at the moment where it's still cheap to reconsider.
Note — impact analysis is a structural signal, not a proof. It sees calls the index can resolve; reflection, dynamic dispatch, and string-built imports don't appear in a call graph. Treat an empty caller list as "nothing obvious" rather than "nothing at all."
Using these well
The productive pattern is narrow, then widen:
- Find the symbol by name.
- Read just that symbol.
- List its callers.
- Ask what breaks if it goes away.
Each step is a question with an exact answer, which is what keeps the reasoning anchored — instead of opening files until the picture feels complete and then acting on the feeling.
Next: Validation and writing.