> For the complete documentation index, see [llms.txt](https://kerno.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kerno.gitbook.io/docs/core-concepts/change-validation.md).

# 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.

{% code expandable="true" %}

```mermaid
flowchart LR
    A[Code change] --> B[Sync workspace] --> C[Find impacted endpoints] --> D[Run baseline tests]
    D --> E[No Diff Detected]
    D --> F[Diff Reported]
```

{% endcode %}

The review is targeted. Kerno traces your change to the endpoints it affects and re-runs only their baseline tests, so each run stays focused on what you actually touched.

### Detecting diffs

A review starts from the blast radius of your change, every endpoint the change can reach. Kerno runs those endpoints' 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 endpoints they reach. It follows the call graph across your whole codebase, so a change to a shared helper surfaces every endpoint downstream of it.

See [Baseline tests](/docs/core-concepts/scenarios-and-baselines.md) for what a baseline checks and what counts as a diff.

### Review scope

Use a scope when asking Kerno which endpoints need attention:

| Scope                     | Meaning                                               |
| ------------------------- | ----------------------------------------------------- |
| `all`                     | Every endpoint in the selected application            |
| `changed`                 | Only endpoints affected by your current git changes   |
| `file:path/to/handler.ts` | Endpoints defined in that source file                 |
| `endpoint:METHOD /path`   | A single endpoint, identified by HTTP method and path |

See [Scopes](/docs/references/scopes.md) 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 endpoint is meant to behave this way now. Accept the diff, and Kerno updates the affected tests to match the new behaviour.

{% hint style="info" %}
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.
{% endhint %}

{% code expandable="true" %}

```mermaid
flowchart LR
    A[Diff reported] --> B{Bug or intended?}
    B -->|Bug| C[Fix the code]
    C --> D[Review again]
    D --> A
    B -->|Intended| E[Update tests]
```

{% endcode %}