who_uses and impact_of: what a real call graph does that grep can't

Grep finds text. A resolved call graph answers "who calls this?" and "what breaks if I change it?" — across modules, ranked by confidence, without guessing.

Ask grep "who calls verifyToken?" and it finds every line with the text verifyToken — the definition, the imports, the comments, a variable that happens to share the name, and the actual callers, all mixed together. Useful, but it's text matching, not understanding.

What a resolved call graph knows

SecondOS parses your repo into real symbols and resolves the calls between them — across files and modules, honoring import aliases and re-exports. So it can answer questions grep can't:

• who_uses(verifyToken) — the actual callers, resolved across modules, ranked by confidence (exact / resolved / heuristic). Not text hits.
• impact_of(verifyToken) — the blast radius of a change: what will break vs what might break, following the graph outward.

This works across seven languages with full call-graph resolution: TypeScript/JS, Go, Python, Rust, Java, PHP and Ruby.

The honest part: it won't guess

Some calls genuinely can't be resolved without running your code — dynamic dispatch, an instance method whose receiver type isn't statically known. SecondOS marks those unknown rather than pointing you at a plausible-but-wrong caller. A lower resolution number is a precision stance, not a coverage gap: impact_of is only useful if you can trust it.

Why it matters for AI tools

When your AI tool reads the graph over MCP, its suggestions get better because it knows which function actually calls which — not which functions share a substring. And the graph is what lets SecondOS auto-write the dependency map and module docs no text-based tool can.

See how the graph fits together.