> 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/capture-a-baseline.md).

# Capture a baseline

A baseline is Kerno's record of how an endpoint actually behaves against your running stack, and the reference point it uses to detect changes later.

You create one by generating tests for an endpoint. Kerno analyzes the endpoint, plans a set of scenarios, shows you the plan, and only writes anything once you approve it.

### Prerequisites

* Your application running, and Kerno pointed at it. See [Start the environment](/docs/guides/start-the-environment.md).
* Environment status reporting `ready_for_endpoint_test`.

### Step 1 — See what is testable

Ask your agent:

> "Use Kerno to list the endpoints in this app."

You get the HTTP routes Kerno discovered, grouped by the file they are implemented in, with a flag showing which already have tests.

### Step 2 — Generate tests for an endpoint

> "Use Kerno to generate tests for POST /users."

Kerno works out how the endpoint authenticates, plans a set of scenarios covering the happy path, error handling, edge cases and authorization, and then stops to show you the plan.

### Step 3 — Review the plan

This is the point of the whole flow. Read the plan before approving it: it tells you what Kerno believes your endpoint does.

Approve it:

> "Looks good, go ahead."

Or send it back with instructions:

> "Drop the pagination scenarios and add one for a duplicate email."

Rejecting re-plans with your feedback and shows you a new plan. You can iterate as many times as you need.

{% hint style="info" %}
**Nothing is written to your repository until you approve.** A plan you reject, abandon, or that fails partway leaves your existing scenarios untouched.
{% endhint %}

### Step 4 — Let it implement and run

Once approved, Kerno writes each scenario, runs it against your application, and repeats until they pass. Scenarios land under `.kerno/scenarios/endpoints/` as TypeScript files.

{% hint style="info" %}
Kerno always writes scenarios in TypeScript, whatever language your application is written in. They talk to your app over HTTP, so the language of your service does not matter.
{% endhint %}

By default Kerno uses its most thorough mode: each scenario is run twice to prove it is genuinely repeatable, and a second reviewing pass rejects weak or hollow assertions. This takes longer but produces tests worth keeping. See [Testing modes](/docs/references/testing-modes.md) if you want to trade thoroughness for speed.

### Step 5 — Read the result

Kerno reports each scenario as:

* **passed** — the scenario ran and the endpoint behaved as expected.
* **failed** — the endpoint did something the scenario did not expect.
* **blocked** — the scenario could not run, usually because a dependency it needs is not configured. Blocked is neither a pass nor a fail; nothing was actually tested.
* **not implemented** — Kerno could not write a working scenario for this case.

You may also see a **potential bug**. This is attached to a scenario that *passes*: Kerno found the endpoint doing something the plan did not expect, confirmed it against your source, and wrote the test to document the real behaviour. The annotation explains the root cause and what a future change would mean. If it is known or intended, tell your agent to ignore it and Kerno will stop flagging it on that endpoint.

### Covering more than one endpoint

Generate tests one endpoint at a time. Each run pauses for plan approval, which is the part worth your attention, and reviewing a hundred plans in one sitting defeats the purpose.

### Editing scenarios

Do not hand-edit files under `.kerno/scenarios/`. To change what a scenario does, run an update with instructions instead:

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

### What's next

Continue to [Validate code changes](/docs/guides/validate-code-changes.md) for the day-to-day loop.