Code Change Review

Understand how Kerno reviews your code changes and catches breaking changes and unintended side effects before they ship.

When you make a code change, Kerno re-runs your existing baseline tests against your running application and reports whether behaviour changed. If nothing changed, you get a clean run. If something did, Kerno shows you exactly what changed.

The review is targeted. Kerno traces your change to the entry points it affects and re-runs only their baseline tests, so each run stays focused on what you actually touched. It also reports the user flows that cross those entry points, and your agent re-runs them too, so a change that breaks a journey is caught.

Each entry point and user flow Kerno reviews gets its own run report in the Kerno portal. Your agent shares the link as soon as the review starts.

Detecting diffs

A review starts from the blast radius of your change, every entry point the change can reach. Kerno runs those entry points' baseline tests and reports every diff in one run, so you see the full impact of your change.

Kerno finds the blast radius by comparing your working tree against HEAD, covering both staged and unstaged changes, and mapping the changed files to the entry points they reach. It follows the call graph across your whole codebase, so a change to a shared helper surfaces every entry point downstream of it.

See Baseline tests for what a baseline checks and what counts as a diff.

Review scope

Use a scope when asking Kerno which entry points need attention:

Scope	Meaning
all	Every entry point in the selected application
changed	Only entry points affected by your current git changes
file:path/to/handler.ts	Entry points defined in that source file
endpoint:METHOD /path	A single route, identified by HTTP method and path

See Scopes for the full reference.

Responding to a diff

When Kerno reports a diff, it's up to you to decide whether it's a bug or an intended change.

• It's a bug. Your change broke something. Fix the code and validate again.

• It's intentional. The entry point is meant to behave this way now. Accept the diff, and Kerno updates the affected tests to match the new behaviour.

Sometimes a run ends without a verdict on your change. Kerno then says where the fault lies:

• Your environment. The app was unreachable, a configuration value was missing, or a dependency such as the database was down. Fix the setup and review again.

• Kerno itself. Kerno's sandbox failed to start or answer. Review again.

When you accept an intended change, Kerno also finds any new logic your change introduced and adds baseline tests to cover it, so your coverage grows with your code.