Change Risk & PR Review: Catch the PRs That Break Things Before You Merge

Why does change risk matter?

Most breakage hides in files the diff never touched. A reviewer reading the diff sees the lines that changed; they do not see the importers, the co-change partners, or the test that quietly went missing.

A diff cannot tell you what it might break, what usually changes alongside it, or whether the tests went missing. repowise reads the change and the graph and turns that into one score plus a checklist of exactly what to look at.

• The risky PRs look like the safe ones, until something fails in production.
• Import-based blast radius is invisible in a diff: your change can break a file you never opened.
• Co-change coupling has no import link at all, so no static tool will warn you.

How does change risk work?

repowise fuses two signals static analysis cannot blend on its own: graph topology (who imports what) and git history (what moves together over time). The result is one score plus a directive block.

The engine runs the same way every time, with no model in the loop.

In PR mode the score ships with a directive block — read it first. Each directive points at a verifiable thing.

Three things to know about the engine:

• Deterministic, zero-LLM. The score is computed from the diff and the graph; no model in the loop, no drift, no token bill, no prompt-injection surface.
• Reverse-dependency BFS. Blast radius walks the graph edges from the changed set outward to depth 3, collecting every file that imports your change.
• Co-change from git. Partners come from the co-change history mined from your repo, so the hidden coupling no AST sees is still caught.

How does change risk help you?

Three outcomes: safer merges, faster review triage, and catching the co-changes and tests a diff silently dropped. Each maps to a directive.

will_break: dependents the change is likely to affect

will_break lists the files downstream of your change in the dependency graph — the importers you did not open. It answers "what else touches this?" from real edges, not a guess.

• Computed by reverse-dependency BFS over the import graph to depth 3.
• Each dependent is ranked by centrality, so the high-PageRank consumers surface first.
• Doubles as reviewer routing: the top owners of affected files become suggested reviewers.

missing_cochanges: files that usually move together but didn't

missing_cochanges flags a changed file's historical co-change partners that are not in your PR. This is hidden coupling — the kind with no import link, the kind AST analysis cannot see.

• Partners come from git history: files that change in the same commit, repeatedly, without importing each other.
• Often the most expensive coupling, because no static tool warns you about it.
• Each warning carries the co-change count, so you can judge how load-bearing the pairing is.

missing_tests: risky code with no accompanying test

missing_tests flags affected files that lack a corresponding test in the change set. Test files themselves are never reported as having a gap.

Guardrail: coverage here is an input that sharpens risk, not a dashboard.

• Feed a coverage report and the test-gap weighting tightens around genuinely untested lines.
• Accepts LCOV, Cobertura, Clover, or normalized JSON.
• No coverage report is required: risk still scores without it; coverage just makes the signal more precise.

Silent by default

The Repowise PR Bot posts one comment per pull request, and only when there is something worth saying.

• A green PR gets no comment at all, so the signal stays trusted.
• Zero LLM calls, so the same PR twice produces the exact same comment.
• That is the opposite of LLM review bots, which comment on every PR regardless of signal.

Walkthrough: from a diff to a risk verdict

Step 1 — Point at a diff. Run get_risk in PR mode (or let the Repowise PR Bot do it) on any commit or base..head range. Nothing is sent anywhere; scoring is local and deterministic.

Step 2 — Read the score. A 0-10 band is computed from the shape of the diff with Kamei-style just-in-time metrics: size, entropy, scatter, and the history of the files it touches.

Step 3 — Trace the blast radius. A reverse-dependency BFS over the graph to depth 3 lists every dependent of your change, ranked by centrality so the high-PageRank consumers surface first.

Step 4 — Read the directives. PR mode returns will_break, missing_cochanges, and missing_tests. Each points at a verifiable thing, so review is a checklist instead of a guess.

Step 5 — Merge or fix. A green PR gets no comment. Otherwise, work the directive checklist — add the missing co-change partner or test — before you merge.

Proof: a deterministic verdict, not a guess

Every signal below is computed from the diff and the graph, with no model in the loop, so it reproduces on your own repo.

Try it on your repo

Score a commit, a branch, or a PR before you merge — every signal is deterministic and runs locally.

pip install repowise
repowise init                          # builds graph, git, and health layers
repowise risk HEAD                     # score a single commit
repowise risk main..my-feature         # score a base..head range

Or install the Repowise PR Bot on a public repo and let it score every PR — silently, until there is something worth saying.