Follow one change through the engine.

ChangeGuard accepts up to three inputs: the patch, a snapshot of the repository before the change, and a coverage report. All three are present here: a git patch touching 3 files (+24 −5), a 6-file snapshot, and a Cobertura report from the test suite.

The patch is parsed strictly. A stray line after a hunk is an error, not something to skip. The parsed patch is then applied to the snapshot in memory to rebuild both revisions. Nothing is written to disk, no archive is extracted, and no script, hook, or test from the repository runs. Every later stage reads these two in-memory revisions.

Before going further, read the diff yourself. Which lines would you stop at? When you have an answer, reveal what the engine flagged; the markers sit on the exact lines its findings point at.

A line diff knows which lines moved. It does not know that format_price is a function, that it had a defaulted currency parameter, or that the new version requires a locale. ChangeGuard parses both revisions with tree-sitter and compares them symbol by symbol: parameters, with their order, kinds and defaults, and return annotations.

Two signatures changed. apply_discount gained a parameter with a default, so every existing call still binds. format_price lost currency and gained a required locale, and the structural diff marks it breaking. Whether that matters depends on who calls it, which is the next stage.

For each changed signature, ChangeGuard resolves imports across the snapshot to find the call sites. Here those are from billing.pricing import … in invoice.py and in the tests. It then replays each call against the new parameter list using Python’s binding rules: positional slots, keywords, defaults, *args and **kwargs.

6 call sites were checked and 2 no longer bind. render_line passes currency=, a keyword the function no longer accepts, and a test calls format_price with no locale at all. Both would raise TypeError when they run. Together they make one deterministic, high-severity finding, with the call sites as its evidence.

A linter run over a whole repository buries a reviewer in findings that predate the change. ChangeGuard runs Ruff on both revisions of each changed Python file and keeps only the diagnostics that are new in the head revision. Ruff reads the source through stdin with repository configuration ignored, so nothing in the repository can change how the tool behaves, and the analysed code is never executed.

5 diagnostics are new. Two of them, E722 and S110, describe the same bare except: pass on line 28. The report merges them into one finding and records the second rule as corroboration instead of counting the problem twice.

Read the two pricing findings together. REGIONAL_RATES on line 27 is never defined, so the lookup raises NameError, and the bare except on the next line swallows it. Nothing crashes. Every non-EU invoice silently loses its regional tax.

Some risks have no linter: credentials pasted into code, text written to steer a language model, a migration that drops a column, a test whose assertions were deleted. ChangeGuard’s rule set reads the added lines for these. On this change every family came back clear except one.

percent > 50 became percent >= 50. The docstring above it still says discounts above 50% need approval; now exactly 50% does too. Whether that is a fix or a regression is a business question, so the rule makes a heuristic finding with medium confidence, and the suggested check is a boundary-value test.

There are two independent signals here. Test mapping is static: it looks for test files that import a changed symbol’s module and reference the symbol. 2 of the 5 changed symbols have such tests. The others, including the new loyalty_bonus and the async handler, have none.

Coverage is measured. The uploaded report records hit counts per line, and ChangeGuard intersects them with the changed lines of the head revision: 4 of 19 changed executable lines ran, which is 21.1% patch coverage. The report gets a plausibility check first. Hits on blank lines, comments, or lines past the end of a file mark it as stale, and that lowers the confidence of every coverage finding instead of being trusted at face value.

With AI enabled, ChangeGuard sends a model a fenced evidence pack containing the findings, their evidence, and the changed code, with each excerpt wrapped as untrusted data. Secrets are masked before the pack is built, and any line that reads like an instruction to the model is withheld. The model must answer in a closed JSON schema in which every claim cites evidence IDs, and the schema has no file or line fields to fill in.

The output then goes to a verifier. It rejects a claim outright, and never repairs it, if the claim cites evidence that does not exist, names a path outside the change, gives a line number outside the cited evidence, attributes a function the evidence does not contain, uses a number the evidence does not support, or reports a test result. ChangeGuard runs no tests, so no model may say one passed.

In the recorded run below, llama3.2:3b, running locally, made 2 claims and 2 passed. One became a note on the call-site finding. It also wrote a free-text summary that puts the condition change in format_price. The change is in apply_discount. That summary is kept in the trace and never shown as analysis.

Findings are de-duplicated, every evidence reference is checked to exist, and each finding gets a stable ID derived from its rule and location, so the same change produces the same IDs on every run. Severity and confidence are separate categorical judgements, defined per rule. They are not probabilities.

The review priority is a written rule, not a score, and the figure lists it in full. Here 2 high-severity deterministic findings set it to high. A model’s findings could never have pushed it past elevated.

The CLI runs the identical pipeline on a git range. It writes Markdown for a pull-request comment, SARIF for code scanning, or the full JSON report, and it can fail the build at a severity threshold. AI findings never fail a build. Only deterministic and heuristic findings count.