Dependency Graph.

ShardStitch maps file relationships, impact radius, and central god nodes so the next AI knows which files are dangerous to touch.

Practical use.

The graph is a review aid for estimating impact around changed files. It helps widen a handoff from what changed to what else may depend on it.

What it carries.

  • Impact radius around touched files
  • God-node and high-centrality warnings
  • Related files the next AI should inspect
  • Dependency risk notes inside the recovery packet

How it fits ShardStitch.

This feature focuses on impact: it helps identify related files and dependency risk so the next AI does not treat an isolated diff as the whole task.

How it helps before the next edit.

Use the graph when a stuck session left a broad or uncertain change surface. ShardStitch can point from touched files toward related files, high-centrality nodes, and likely impact areas so the next AI has a bounded inspection list.

This is a risk map, not a substitute for tests or a complete language-server call graph. Confirm the suggested relationships against the repository and run the project’s own checks before accepting a change.

Use the graph to choose the next review files.

After identifying the changed files, inspect their nearby relationships and use the result to build a short review list before asking another agent to continue.

  1. Start from files in the current diff, not from a global graph view with no task boundary.
  2. Inspect the most connected or central nodes and follow only relationships relevant to the change.
  3. Add likely callers, tests, configuration, and interfaces to the receiving session review list, then verify those paths exist in the repository.

Worked example.

For example, if a changed file defines a shared request type, use its graph neighborhood to find likely consumers and tests. Inspect those files before changing the interface, then run the focused tests that cover the consumers. If the graph shows no relationship but code search finds one, trust the code and update the review list; the graph is a lead, not an exhaustive dependency oracle.

Limits and verification.

A repository graph is an approximation of dependencies, not a proof of runtime behavior or a complete call graph. Dynamic imports, generated files, reflection, build-time wiring, and external services can be absent. Use it to ask better review questions, then confirm with code search and tests.