Impact Analysis

Before changing code, you should understand what will be affected. Synapses’ get_impact tool traces through the code graph to show the blast radius of a change — direct dependents, indirect consumers, and peripheral connections.

Basic Usage

{
  "tool": "get_impact",
  "arguments": {
    "entity": "internal/auth/jwt.go:ValidateToken"
  }
}

Returns an impact report organized by distance from the changed entity.

Impact Tiers

Direct Impact

Entities with a direct edge to the changed entity. These will almost certainly need review or updates.

ValidateToken
  ├── CALLED_BY: AuthMiddleware (internal/middleware/auth.go)
  ├── CALLED_BY: RefreshHandler (internal/handlers/refresh.go)
  ├── TESTED_BY: TestValidateToken (internal/auth/jwt_test.go)
  └── IMPLEMENTS: TokenValidator (internal/auth/interfaces.go)

Indirect Impact

Entities two hops away. These may need changes depending on what you modify.

AuthMiddleware
  ├── CALLED_BY: Router.Setup (internal/router/setup.go)
  └── CALLED_BY: TestAuthFlow (internal/integration/auth_test.go)

Peripheral Impact

Three or more hops away. Unlikely to need changes but worth knowing about for large refactors.

Using scope=“review” for PRs

When reviewing a pull request, use the review scope to analyze all changed files at once:

{
  "tool": "get_impact",
  "arguments": {
    "files": [
      "internal/auth/jwt.go",
      "internal/auth/middleware.go"
    ],
    "scope": "review"
  }
}

Review scope aggregates impact across all specified files and deduplicates, giving you a unified view of the PR’s blast radius.

Cross-Domain Impact

Some edges represent cross-domain relationships:

DEPLOYS — deployment configurations that reference the entity
CONSUMES — API consumers (other services, clients)
CONFIGURES — configuration files that affect the entity

{
  "tool": "get_impact",
  "arguments": {
    "entity": "internal/api/v2/users.go:ListUsers"
  }
}

ListUsers
  ├── CALLED_BY: UserHandler.ServeHTTP (direct)
  ├── CONSUMES: frontend/src/api/users.ts (cross-domain)
  └── DEPLOYS: deploy/k8s/api-deployment.yaml (cross-domain)

Cross-domain impact helps you catch breaking changes that span service boundaries.

Example Workflow

A typical pre-change workflow:

1. Identify the entity to change
   search(mode="exact", query="ValidateToken")

2. Check impact
   get_impact(entity="internal/auth/jwt.go:ValidateToken")

3. Review the report
   - 4 direct dependents → must update
   - 2 indirect dependents → check after
   - 1 cross-domain consumer → coordinate with frontend team

4. Get full context for the change
   get_context(mode="intent",
     task="Change ValidateToken to accept Ed25519 keys",
     intent="modify",
     files=["internal/auth/jwt.go"]
   )

5. Make the change with full awareness of blast radius

Impact with Architectural Rules

If any entity in the impact chain has associated architectural rules, those rules appear in the impact report. This helps you spot potential violations before they happen:

{
  "violations_at_risk": [
    {
      "rule_id": "no-handler-to-db",
      "entity": "internal/handlers/user.go:CreateUser",
      "reason": "If ValidateToken changes force CreateUser to add a DB call, this rule would be violated"
    }
  ]
}

Filtering Impact Results

For large codebases, you can limit the depth of analysis:

{
  "tool": "get_impact",
  "arguments": {
    "entity": "internal/store/store.go:Store.Close",
    "max_depth": 1
  }
}

This returns only direct impact, which is useful for entities with many callers (Store.Close has 96 callers in the Synapses codebase itself).