The code graph

The analysis turns the source code into a graph. Nodes are symbols and files, edges are calls and imports. The Graph View never draws the whole graph. It draws one perspective: the part of the graph that answers one question, such as "who calls parse_current?" or "which files depend on client.ts?".

Nodes

A node is one of these:

Symbols are identified by file and name, for example src-tauri/src/providers/openweather.rs::parse_current. Two symbols with the same name in different files are different nodes. When a query names only parse_current, the Graph View asks which one is meant.

Edges

• A call edge points from the caller to the callee. Every symbol has two directions: its callers (who calls it) and its callees (what it calls).
• An import edge points from the importing file to the imported file. Impact follows import edges backwards (which files depend on this one), dependencies follows them forwards (what this file needs).

Call edges are resolved from names and the types the parser can see. Calls through a trait, an interface or a function stored in a variable may be missing, and two functions with the same name can produce an edge that does not exist at runtime. ✦ Sharpen checks the visible call edges with a language server, see Sharpen call edges.

Perspectives

A perspective is a query with a fixed meaning. Some take a symbol or a file as their starting point (callers, callees, call tree, impact, dependencies, imports, path). Others look at the whole project (dead exports, orphan files, circular dependencies, complexity hotspots, entry points, recent changes). Perspectives and queries lists them all.

Every perspective can also be opened from a link of the form ce://graph-perspective?kind=callers&symbol=parse_current. The assistant answers questions about calls and dependencies with such links, so a click on the answer draws the graph.

Findings are hints

Three perspectives report structural findings:

• Dead Exports: exported symbols that no file imports.
• Orphan Files: files that no file imports and that are not entry points.
• Circular Dependencies: files that import each other, directly or over several steps.

The first two rest on static imports only. A framework that loads files by path or name (routes, Tauri commands, test runners, plugin registries), a public library API that other projects import, or a dynamic import() all produce entries that are in use. A long list of orphan files in a Tauri or Next.js project is normal. Check an entry before you delete code: open the file and look for the framework convention or the external consumer.

Semantic domains

The structural graph shows how code is wired. The Semantic Domains perspective groups files by meaning instead. It uses local embeddings of the code and its text, so two files about the same subject land in one domain even if they never call each other. Edges between domains summarise the structural dependencies that cross them.

Use the structural perspectives for questions about change and impact. Use the domains to get an overview of an unknown project by subject. The first run downloads the local embedding model (about 130 MB).

Other projects in the graph

If the exploration has reference projects with the purpose Linked, the call perspectives can continue into them: a call that sends GET /forecast ends in the handler of the other project. See Calls between linked projects.