> 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/references/scopes.md).

# Scopes

A scope narrows Kerno's view of your application to a subset of endpoints. It is a required argument on `kerno_list_endpoints`.

### The four scopes

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

### When to use each

* **`all`** — surveying an application, or checking overall coverage.
* **`changed`** — the everyday one. Kerno compares your working tree against `HEAD`, including both staged and unstaged changes, and resolves which endpoints your edits reach. It follows the call graph rather than just the file you edited, so a change to a shared helper surfaces every endpoint downstream of it. Touched scenario files count too, not only handlers.
* **`file:`** — focused changes to one handler file.
* **`endpoint:`** — a single route you already have in mind.

### Syntax

`file:` paths are interpreted relative to your workspace root.

`endpoint:` expects exactly one space between the method and the path, as in `endpoint:POST /api/orders`. The method is uppercased for you and the path normalized, but both must be present.

### Where scopes apply

Scopes are used by **`kerno_list_endpoints`**, where the argument is required.

{% hint style="info" %}
`kerno_endpoint_test` does not take a scope. It targets one endpoint at a time, identified by an explicit `endpoint_method` and `endpoint_path`. The usual pattern is to list endpoints with a scope to see what needs attention, then run a test against a specific one.
{% endhint %}

### How scopes work behind the scenes

Kerno's dependency graph maps every endpoint to the code that produces it. When you pick a scope, Kerno resolves it to a concrete list of endpoints and works from that list.

See [Change Validation](/docs/core-concepts/change-validation.md) for how the `changed` scope fits into the everyday loop.