> 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 tells Kerno which entry points to list.

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

### The four scopes

| Scope                     | Meaning                                                |
| ------------------------- | ------------------------------------------------------ |
| `all`                     | Every entry point in the selected application          |
| `changed`                 | Only entry points affected by your current git changes |
| `file:path/to/handler.ts` | Entry points defined in that source file               |
| `endpoint:METHOD /path`   | A single route, 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. A new file counts once it is staged, and a change stops counting once you commit it. Kerno resolves which entry points your edits reach. It follows the call graph rather than just the file you edited, so a change to a shared helper surfaces every entry point downstream of it. Touched scenario files count too, not only handlers. It also reports the [user flows](/docs/core-concepts/user-flows.md) that cross those entry points, so they can be re-run too.
* **`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 entry point at a time, identified by an explicit `endpoint_method` and `endpoint_path`. `kerno_endpoint_test_many` takes an explicit list of entry points, also without a scope. The usual pattern is to list entry points with a scope to see what needs attention, then run a test against the ones you picked.
{% endhint %}

### How scopes work behind the scenes

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

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