Impact Simulator

Ask what breaks before you write the change. The Impact Simulator grounds a plain-English question against the real dependency graph, then reports the blast radius with the evidence behind every file in it.

Asking a question

Type the change you are considering. Four presets are offered, and your last five questions are kept locally so you can re-run one:

“What breaks if I remove the authentication middleware?”
“Which files depend on the UserService class?”
“Impact of changing the database schema for the orders table”
“What happens if I rename config.js?”

Direction matters

The same file list answers two opposite questions, so the wording changes with the question. A reverse question — what breaks if I change this — is headed Impact Summary and lists Affected Files. A forward question — what does this depend on — is headed Dependency Summary and lists Depends On. Calling the second list “affected files” would state the relationship backwards.

TIP

Arriving from a Code Map file card pre-fills the question for that file, so you can go from “this looks risky” to a full blast radius in one click.

The tab

mapnostics.com/repo/mapnostics-app/impact-simulator

Simulate a Change

⌕What breaks if I remove the authentication middleware?

Simulate

Remove auth middlewareUserService dependenciesDatabase schema changeRename config.js

Impact Summary

7 files potentially affected

3 High Risk3 Medium Risk2 Zombies in 1 file

Removing the middleware leaves every repository read to enforce access on its own. Three route handlers call the shared gate directly and would still be covered; the rest rely on the middleware running first.

Copy summary for GitHub PRUnlock detailed dependency graph — Upgrade to Pro

Reaches 4 API routes and 2 pages

Writes to 2 tables: repos, analysis_runs · reads code_chunks

3 of 7 changed source files have tests (43%) — 4 untested.

Depends on 1 undeclared env var: GITHUB_APP_SECRET — missing from the example env file.

Touches 2 feature flags — 1 permanently off (dead branch), 1 runtime.

Affected FilesWide blast radius

All (7)HighMediumLow

repo-access.tsHigh Risklib/supabase/repo-access.ts

Every repository read passes through this gate — removing the middleware leaves it unenforced.

High confidence · untested · unit tests only

route.tsHigh Riskapp/api/repos/[id]/dead-code/route.ts

Calls requireRepoAccess before every query in this handler.

High confidence · GET, POST /api/repos/[id]/dead-code

layout.tsxMedium Riskapp/repo/[id]/layout.tsx

Resolves the repo before rendering any tab; a failure here 404s the whole section.

Medium confidence · covered by e2e

The headlines

Above the file list, the simulator raises a banner for each kind of risk it can prove from the repository. Each one appears only when it has something to report:

API surface — the externally callable routes and pages the change reaches, with their signatures, and any that middleware does not cover.
Database writes — the tables the change modifies, listed apart from the ones it only reads.
Test coverage — how many of the changed source files have a matching test, and how many do not.
Unit-only coverage — files whose only tests are unit tests. A green suite there can still hide a broken integration path.
Undeclared environment variables — variables the change depends on that are missing from your example env file, so a fresh deployment may run without them.
Feature flags — flags the change touches, and whether each is permanently off, permanently on, or set at runtime.
Entry points and packages — the externally-triggered entry points inside the radius, and the declared packages it imports.

NOTE

The whole result copies to your clipboard as a markdown table with Copy summary for GitHub PR, so the blast radius can go into the pull request that causes it.

The file list

Blast radius

The list carries one overall classification — Localized, Moderate or Wide — beside its heading, and each file carries its own risk band. Filter the list by band with the pills on the right.

Per-file evidence

Every row explains why the file is in the radius, and adds what the other scans know about it: the confidence that it is really affected, whether it has tests and at what level, the route it serves if it is one, and any feature flags it references.

Truncation

Long results are capped at the files with the strongest evidence, and the tab says so where the list is, naming how many more files are affected but not shown. It is never presented as the complete radius.

NOTE

A general best-practices checklist sits below the results and is labelled as one. It is a fixed list — run the tests, review the dependants, consider a staged rollout — not something derived from your query.

What it cannot see

Calls made through a variable or a string. A dynamic dispatch has no static edge to follow.
Runtime values. The simulator can see that a feature flag exists, never whether it is on in production.
Behaviour. It reports which files are reached, not whether your change is correct.

TIP

Pair it with the Code Map inspector. The simulator answers “what does this reach”; the inspector answers “what else is known about each of those files”.