---
title: "Lanes and stops: Kotharo"
version: v0.8.3
canonical: https://kotharo.com/docs/lanes-and-stops/
---

# Lanes and stops

At intake the team sizes each ticket into a lane. The lane sets the stages the ticket goes through and the stops where the team waits for you. A stop is a decision that is yours; everything between stops runs without you.

## The lanes

| Lane | Fits | Stages |
|---|---|---|
| Small fix | About 1 to 3 files, with no schema, contract or tenant data change | build, QA, merge, deploy, close-out |
| Clear ticket | Has acceptance criteria, or criteria the team can derive from the ticket and the code | plan, build, review, QA, merge, deploy, close-out |
| New feature | A new API, schema, integration or work across repos | scope, design, build, review, QA, merge, deploy, close-out |
| Hotfix | Production is broken. Branches from the release branch and skips dev | build, QA, merge, deploy, close-out |

Moving a ticket to a bigger lane needs your OK. A migration, a public contract change, a new path for tenant data or a second repo each call for one.

## Where each lane stops

The [autonomy level](https://kotharo.com/docs/autonomy-levels/) sets the stops. At `balanced`, the default:

| Lane | guided | balanced | autonomous |
|---|---|---|---|
| Small fix | plan, merge | merge | merge |
| Clear ticket | plan, merge | merge | merge |
| New feature | scope, design, plan, merge | scope, merge | scope, merge |
| Hotfix | plan, merge | merge | merge |

- At `balanced`, the merge stop is the end card: what the change is for and its riskiest area, the tests and reviewers that ran, the diff and the follow-ups, most severe first. One yes commits, pushes and opens the pull request, and once you merge it the team sees the merge and goes on without being told, even from an idle session: while it waits at merge, its band reads the pull request every few minutes and wakes it once you merge.
- At `guided`, a separate **Ship it?** card comes before the pull request, and the merge stop after it.
- At `autonomous`, the team commits, pushes and opens the pull request without asking, so the merge stop comes after the pull request.

The merge stop can't be dropped. Every lane ends with close-out.

## What each stop asks

- **Scope**, on a new feature: the problem, the users, the acceptance criteria and what is out of scope, with the main design decisions.
- **Plan**: the criteria, examples, how the work splits into tasks, the gates and the estimate.
- **Design**: the design and its decisions.
- **Merge**, the end card: **Ship**, **Commit only** or **Not quite...**. **Ship** reviews again only if the code changed since the team's review, then commits, pushes and opens the PR. A small fix or hotfix folds its close-out in, with **Ship and close**. It shows the top three follow-ups with a count of the rest. An answer such as "all" covers Major findings and below only: each Blocker comes first on a card of its own, where you choose **Fix it**, **Accept with a reason...** or **Defer to a ticket...**, and the close-out record notes how each was resolved.
- **Close-out**: your verdict on the ticket: **Success**, **Partial** or **Off target**, or **Keep open...**.

A stop card is short: one decision, asked as a question on its first line, in at most 3 lines, with its evidence and up to 5 choices. The first stop plays back what the team understood and offers **Not quite...** so you can correct it before any work. See [The band and stop cards](https://kotharo.com/docs/band-and-stop-cards/).

## The only other interruptions

Besides a lane stop, the team interrupts you only for:

1. Something only you can fix, such as a cloud login, a VPN or access. The message gives the exact command.
2. A question about behavior the ticket and the code can't answer.
3. A fix loop that hasn't converged: 2 review fix rounds, or 3 pushes to fix CI.
4. An outward-facing action, such as a push or a deploy, that your autonomy level doesn't let it take on its own.

Questions that can wait are parked for the next stop, each with the answer the team proposes, so one press can accept them all.

## Kinds of work

Not every ticket is code. The team names the kind at intake, and you can change it at the first stop.

- **Code**: the lane's stages and stops, as above.
- **Requirements**: the PM writes the requirements. Stops at scope and close-out.
- **Design**: stops at design and close-out.
- **DevOps**: a deploy or infrastructure change. Stops at plan, deploy and close-out, plus build and merge when it changes files in the repo. A deploy always asks.
- **Mixed**: runs as a new feature, or split into one ticket per kind.

## Plan without building

To have the team stop before any code is written, give it the last stage to run:

```
/kotharo:team ABC-123 --until design
```

`--until` takes `scope`, `design` or `plan`. A yes at that stage ends the run, and close-out asks whether to commit the documents, post a summary, or both. `/kotharo:team ABC-123` later picks up where it paused.

## Close-out

Every lane ends with close-out against its definition of done: the criteria verified, the change merged and deployed, the deploy verified and watched, the ticket move proposed and the record written, plus a release note and cleanup for clear tickets and new features. When everything is met after a **Ship and close**, it records the result without stopping you again. Otherwise the close-out card asks the move that fits and names what is still open, such as the deploy or cleanup, and your verdict covers the work so far.

## The watch after a deploy

Before a deploy, the team takes a baseline from your errors and logs tool: the error count and the known-noise lines, for the last `limits.watch_minutes` (15 by default). After the deploy is verified, it watches that long again, compares against the baseline and runs the repo's After checks. The verdict is **healthy**, **regressed** or **unproven**, with its evidence. A regressed watch opens an incident review and offers **Roll back**, which asks again at its plan. An unproven watch, such as one with no errors and logs tool connected, waits for you to accept it.

## Release windows

`/kotharo:release-cut` ships one service or several in one window. It keeps one run sheet per window, outside the repos, with the order and the reason for each dependency, such as an API before the service that calls it. Prep, such as change tickets, branch cuts, test runs and dev deploys, can run the day before.

On the day, it takes every service's baseline, then deploys them in order. Each service starts only when the one before it is deployed and its watch is healthy, and any stop halts the services after it. Every trigger asks you first, and a manual approval stage is never approved for you.

Checks that only real traffic can prove go to a read-only morning check. The run sheet names each check and its time. The job reports pass, fail or unproven for each, and never deploys, rolls back or changes a ticket. Each repo sets these in the `### Deploy` section of its `CLAUDE.md`, one line each:

```
### Deploy
- watch-query: `service:orders-web level:error`
- noise: HealthCheckTimeout
- deploy-after: orders-api (the web app calls the new orders endpoint)
- after-check: checkout: a test order completes
- morning-check: first payment at 06:15: a real payment settles without a retry
```

`noise`, `after-check`, `morning-check` and `deploy-after` can repeat.

Next: [The band and stop cards](https://kotharo.com/docs/band-and-stop-cards/). [All docs](https://kotharo.com/docs/)

Written for Kotharo v0.8.3.