> 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/guides/validate-code-changes.md).

# How to Review your Code Changes

Learn how to review a code change against your baseline tests, read the result, and update them when the change was intentional.

### Introduction

Reviewing your changes is the day-to-day loop. You change some code, Kerno re-runs the baseline tests for the affected entry points, and tells you whether their behaviour moved.

In this guide, you will trigger a review, read the result, and bring the tests along when a change was intentional.

### Prerequisites

Before you begin, you will need:

* Baseline tests already generated for the entry points you want to review. See [How to Create Baseline Tests for your Entry Points](/docs/guides/capture-a-baseline.md).
* Your application running with your changes applied.

### Step 1. Triggering a review

After changing code, ask your agent to review the entry points your change affected:

```
Use Kerno to validate the entry points and flows my changes affected.
```

Kerno maps your change through the call graph to every entry point it reaches, so a change to a shared helper is reviewed alongside the obvious ones. For each affected entry point, it re-runs the baseline tests already on disk against your current code and reports where behaviour moved. It also re-runs the [user flows](/docs/core-concepts/user-flows.md) that cross those entry points.

Kerno reviews the changes you have not committed yet, staged or unstaged, against your last commit. Run the review before you commit, and `git add` any new files first, since Kerno only sees files git tracks. See [Code Change Review](/docs/core-concepts/change-validation.md#detecting-diffs).

You can also review a single entry point:

```
Use Kerno to validate POST /users.
```

A review only re-runs tests that already exist. If an entry point has no tests yet, Kerno reports that it has none, so ask your agent to [create a baseline](/docs/guides/capture-a-baseline.md) for it first.

### Step 2. Reading the result

When a review finishes, Kerno re-runs each baseline test against your current code and checks whether the response still matches the one the baseline recorded. When you are signed in to Kerno, your agent also gives you a link to each review's page in the [Kerno Portal](/docs/portal/overview.md).

A diff is a difference between the response the baseline recorded and what your entry point returns now. Kerno matches values that legitimately change between runs, such as generated ids, tokens, and timestamps, by their shape, so a fresh id or timestamp never counts as a diff. A field that appears where the baseline had none does count, even without an explicit assertion for it, which is how an accidentally leaked field, like an internal flag or a password hash, gets caught. The same goes for response headers that describe behaviour, such as content type, caching, cookies, CORS and security headers, so a header that changes, appears or disappears is a diff too.

Each test comes back as one of four outcomes:

* **Passed.** No diff was detected. The behaviour this test covers matches the baseline, so your change left it unchanged.
* **Blocked.** The scenario never ran, usually because a dependency it needs is not configured. Nothing was tested. Kerno tells you what is missing, so you can ask your agent to fix it and run the review again. See [How to Configure the Kerno Test Environment](/docs/guides/start-the-environment.md).
* **Failed.** A diff was detected. The behaviour moved from the baseline. Kerno reports every assertion that did not match, each with a clue explaining what it was checking and a diff of expected against actual, so you see every change from one run.
* **Not implemented.** The test still holds the placeholder from its plan, because Kerno never finished writing it. Nothing was tested.

A diff does not always mean something is broken. It only tells you the behaviour changed, and it is up to you to decide:

* **The change is a bug.** Fix your code and review again.
* **The change is intentional.** Your entry point genuinely changed and the tests need to follow, so update the baseline (Step 3).

### Step 3. Updating baseline tests

Ask your agent to update when a diff is intentional, or when you have added logic that no test covers yet:

```
Use Kerno to update the tests for POST /users. 
The response no longer includes the role field.
```

Kerno reconciles the suite with your change:

* It re-baselines the tests that diffed, so their expectations match the new behaviour.
* It adds tests for new logic your change introduced that nothing covers yet.
* It keeps every test that still applies, and removes one only when you tell it that test is obsolete.

{% hint style="info" %}
When you add logic that none of the existing tests exercise, the review shows no diff. Ask Kerno to update the tests for that entry point and it adds coverage for the new logic:

```
Use Kerno to update the tests for POST /users.
```

{% endhint %}

### Conclusion

That is the loop. Change code, review the affected entry points, and update the tests when a change is intentional, so your baseline always reflects how your app should behave. From here, see [Custom Rules](/docs/core-concepts/custom-rules.md) to shape how Kerno tests, and [Memory and learning](/docs/core-concepts/memory-and-learning.md) to see how it improves over time.