Skip to content
AnchorsAnchors
EN · PT

The Graph & Dependency Map

Modern software systems are not flat lists of files. They are interconnected webs of dependencies: a database query depends on a domain model, an API handler depends on a service, and a user interface depends on an API contract.

Anchors models your entire repository as a Directed Acyclic Graph (DAG) of anchors and files.

1. What is the Anchors Graph?

Section titled “1. What is the Anchors Graph?”

When you run anchors analyze or evaluate gates, Anchors scans your project and builds an in-memory graph where:

  • Nodes are project artifacts: specs, feature files, test files, source code files, doctrine guides, plans, and feature flags.
  • Edges are formal relationships between artifacts:
    • governs: Spec -> Code (the spec dictates how the code behaves).
    • covered-by: Spec -> Feature (the feature file tests the spec).
    • tested-by: Feature -> Test (the test code executes the feature scenario).
    • depends_on: Code -> Code (import/call dependency between modules).
    • realizes: Spec -> Doctrine (the spec realizes a higher-level product doctrine).
    • flagged-by: Unit -> Flag (the unit is governed by a feature flag).
  [ Product Doctrine ]
           │
           │ (realizes)
           ▼
    [ Order Spec ] ──────(governs)───────► [ Order Code ]
           │                                      │
           │ (covered-by)                         │ (depends_on)
           ▼                                      ▼
   [ Order Feature ] ──(tested-by)──► [ Payment Service ]
           │
           ▼
     [ Order Test ]

2. Why the Graph Matters

Section titled “2. Why the Graph Matters”

Traditional linters only look at one file at a time in isolation. They cannot detect systemic architectural issues.

Because Anchors maintains a project-wide graph, it can execute relational gates:

  1. Detecting Circular Dependencies: The circular gate traces topological cycles across layers.
  2. Boundary Enforcement: The layer-boundary gate prevents domain entities from importing infrastructure or UI layers.
  3. Change Propagation: When an anchor changes, Anchors traverses downstream edges to identify all impacted units that must be re-verified.
  4. Ghost Detection: The revision-orphans gate discovers specs that were removed or renamed while leaving orphaned test code behind.

3. Querying the Graph with the CLI

Section titled “3. Querying the Graph with the CLI”

You can inspect the dependency graph directly using the Anchors CLI:

Terminal window
# Visualize the topological order of all units
anchors graph --format=tree


# Check impact wave if a specific unit changes
anchors wave src/services/billing/invoice.spec.md


# Inspect inbound and outbound edges for an anchor
anchors inspect BILL-B01
Section titled “4. Related Concepts”