Docs

What Hatch is, the one rule behind it, and where each of the five sections starts.

From a clean machine to a first `hatch work`, in the order you do it.

Installing Hatch as an app on a phone, and what it can and cannot do there.

The seven columns a stock board ships with, and who moves work out of each.

What hangs under what, and what the board does with each field on a ticket.

The columns a ticket crosses from idea to shipped, and who moves it out of each.

The line between what the board decides from its own shape, for nothing, and what needs a session, bought by the increment.

What a playbook row says, how one is matched to a move, and what its model, effort, budget and brief limit control.

How a session asks for a decision it should not make, what an open question holds up, and where the answer is kept.

Where a branch stops being one session's and becomes the project's, and what the pull request recorded on an issue is for.

How the WIP limits, the fold, stalls, the battery and preemption keep a loop that can work any ticket from working all of them at once.

Who may do what in Hatch: the wall, the three roles, project owners and approvers, and API keys.

Getting the runner onto your machine, pointing it at a board, where its settings and its name live, and the commands that read and drive the board by hand.

What `hatch work` and `hatch go-to-work` do, every flag they take, and how a night ends.

The runner packaged as a container beside the stack, for a Hatch with its wall off - what it can and cannot do, where its credential comes from, and how to let it push.

The prompt a session is handed, section by section - what each part is for and when it appears - and how the agent CLI is started around it.

Where to see the loop working, what it landed, and what it is waiting on you for.

Turning on a column the runner merges approved pull requests from, with no session.

What a running Hatch is made of - the five Compose services and which of them exits on purpose, how to start it, move its port and stop it, and how to run from the published images instead of building.

What each of the wall's three postures - off, on and required - changes about who may reach a Hatch, and how.

What the API expects of a cluster, since no manifests, chart or Helm values ship with Hatch.

Pulling new source or new images, what the migration does on the way up, how to tell from its log that it worked, and how to roll back.

Where a Hatch keeps its data, how to dump it every night and restore it, and what replication means for it.

Find the symptom, then the service log that shows it.

Every hatch command, what it takes, what it prints, and what it leaves on the board.

Every route under /api/hatch, grouped by resource, with who may call it and what it answers.

Every variable Hatch reads - the stack's, the runner's and the container's - with its default and what reads it.

The block to paste into a repository's `CLAUDE.md` or `AGENTS.md` so its agents know how to reach the board.