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

# Validate code changes

Validation is the day-to-day loop. You change some code, Kerno re-runs the existing scenarios for the affected endpoint, and tells you whether behaviour moved.

### Prerequisites

* Tests already generated for the endpoint. See [Capture a baseline](/docs/guides/capture-a-baseline.md).
* Your application running with your changes applied.

### Step 1 — Sync the workspace

After changing code, ask your agent to sync the Kerno workspace so it is working against your current source. Then find what your change touched:

> "Which endpoints did my changes affect?"

Kerno maps your working-tree diff against `HEAD` to the endpoints it reaches, following the call graph rather than just looking at the file you edited. A change to a shared helper surfaces every endpoint downstream of it.

{% hint style="info" %}
This works off uncommitted changes. If you have already committed everything, there is nothing in the diff, so target the endpoint directly instead.
{% endhint %}

### Step 2 — Validate

> "Use Kerno to validate POST /users."

Kerno runs the scenarios already on disk for that endpoint. It does not plan anything new and does not pause for approval.

{% hint style="info" %}
If no scenarios exist for the endpoint, the run stops immediately and tells you to generate first. Nothing is created implicitly.
{% endhint %}

### Step 3 — Read the result

**Everything passed.** Your change did not alter the behaviour these scenarios cover. If the change added behaviour that nothing covers yet, that is worth an update.

**Something failed.** Kerno reports every assertion that did not match, each with a clue explaining what it was checking and a diff of expected against actual. You get the whole picture from one run rather than only the first mismatch.

Now make the call that only you can make:

* **The failure is a bug.** Fix your code and validate again.
* **The failure is intentional.** Your endpoint genuinely changed and the tests need to follow. Go to step 4.

**Something is blocked.** The scenario never ran, usually because a dependency it needs is not configured. That is not a pass and not a fail. See [Environment Setup](/docs/core-concepts/environment-setup.md).

### Step 4 — Bring the tests along

When the change was deliberate, update rather than regenerate:

> "Use Kerno to update the tests for POST /users — the response no longer includes the role field."

Update is conservative by design. It reads the failures from the previous run and the files your change touched, keeps every scenario that still applies, and edits only what your change requires. It will not quietly rewrite your suite or delete the happy path.

Tell it what changed and why. That description is what it uses to decide which scenarios need editing.

{% hint style="warning" %}
Reach for regeneration only when you want to start an endpoint's coverage over. Generating discards the scenarios on disk when your guidance changes, and you review a fresh plan from scratch.
{% endhint %}

### What Kerno ignores

Validation does not report differences in key ordering, array ordering, or numeric precision. Values that legitimately change between runs, such as generated ids, tokens and timestamps, are matched by shape rather than pinned to a literal, so they do not produce noise.

Conversely, a field that *appears* in a response where the tests did not expect one will fail the scenario, even though nobody wrote an assertion for it. That is deliberate: it is how an accidentally leaked field gets caught.

### Automating the check

Kerno can write the list of impacted endpoints to `.kerno/CHANGES_DETECTED.md` and install a git hook to keep it current, so your coding agent knows what to validate without being asked. Ask your agent to set this up if you want it.