> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qlane.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# QLANE.md

> QLANE.md, the file your team writes for qlane: your critical flows, your accounts and roles, and the parts that matter least.

A `QLANE.md` tells qlane what matters when it tests your application: the flows that must not break, the accounts and roles your users have, and the parts that matter least. Your team writes it and commits it with your code.

## Where it goes

* **At the root of your repository**, named `QLANE.md` exactly, in capitals, as `AGENTS.md` and `CLAUDE.md` are.
* **Or in a `.qlane` folder**, as `.qlane/QLANE.md`. If both exist, the one at the root is read and the other is not.
* **As committed.** A QA baseline reads the file at the commit it tests. A pull request is tested against the file as it is on the branch the pull request starts from, so a change to `QLANE.md` applies to pull requests opened after it merges, never to the pull request that makes it. In an environment with several repositories, each repository the pull request changes is read the same way, as it is on the branch its change starts from; the others are read as they are on their configured branch.

## What to put in it

* **Critical flows, by priority.** The things a user does that must keep working, most important first, such as P0 for flows whose failure stops your users and P1 for the next tier. Write each as a goal with a result you can see: “refund an order; its status then reads Refunded”, not “the refunds page”.
* **Accounts and roles.** Which kinds of user your application has, what each may do, and what a flow needs: a second account, an admin, an email inbox. Describe them; never write a password or a token here. Qlane reads this section only to decide what to test first. Listing an account here does not create it or sign in with it.
* **Areas to skip.** Parts of the application that matter least to test, and why: static help pages, or internal tools your users never see. Listing an area here lowers its rank and never excludes it, so a baseline can still explore it, for example when your application has only a few areas or a run’s focus names that area.

> [!WARNING]
>
> **Keep anything harmful out of the test environment itself**
>
> `QLANE.md` cannot keep a run away from a page. If exploring a part of your application could do real harm, such as charging a card or emailing real customers, make it harmless in the environment qlane tests: use test accounts, and integrations in a sandbox or test mode.

A short example, for an application that takes orders:

```markdown QLANE.md theme={null}
# QLANE.md

## Critical flows

### P0
- Place an order from the cart, and see it at the top of Order history.
- Refund an order from its detail page; its status then reads "Refunded".

### P1
- Invite a teammate from Settings > Team; they are listed as pending.
- Export the order list as a CSV file.

## Accounts and roles
- Admin: can refund orders and manage the team.
- Staff: can place orders, but cannot refund them or see Settings.
- Signing up needs an email inbox, so a new account needs one too.

## Areas to skip
- Help center: static pages, low priority.
- The internal pages under /debug: only our own team uses them.
```

## How Qlane uses it

* **When it plans a QA baseline.** Qlane reads your code to list your application’s areas and rank them, and a baseline explores the highest-ranked ones. What your `QLANE.md` says matters most weighs in that ranking ahead of what any other file in your repository says, such as an `AGENTS.md` or a README.
* **When it tests a pull request.** Qlane plans the cases the change calls for. Your `QLANE.md` tells it which flows matter most, so a change that reaches a critical flow is more likely to be tested, and that flow is tested first. The account and role notes help Qlane choose which account to test with; what you wrote on an account itself in Qlane wins. The browser tester reads it too, to know which flows matter and which accounts exist.
* **`AGENTS.md`, when you have no `QLANE.md`.** Pull-request testing reads one file per repository: your `QLANE.md`, or, when your repository has none, its `AGENTS.md`, and no other file. If a `QLANE.md` exists, `AGENTS.md` is not used, even when the `QLANE.md` cannot be read (for example when it is a link, or empty once hidden text is removed). A QA baseline reads both, and your README and other context files besides.
* **As a description, never as commands.** Qlane treats the file as information about your product. Where it and your code disagree, the code wins: an area or a flow is planned only when qlane finds it in the code. An area you list to skip still appears in the plan, ranked below the areas to test, and a baseline can still explore it.
* **Keep it short, most important first.** The plan is shown the first 12 KiB of the file, and at most 24 KiB of context files in all, shared across your repositories, with `QLANE.md` read first; pull-request testing shows only that one file per repository, within the same limits. Before that, anything a rendered Markdown page hides, such as an HTML comment, is removed, so write everything you want read as visible text. A file whose cleaning takes too long is withheld whole, and the plan is told it was.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.