# Playbook 04 — Build handoff

**Trigger.** A to-be design is settled and work is about to start in a code repository.

**Who runs it.** Whoever starts the build.

## Steps

1. **Confirm the design is settled.** Its frontmatter reads `status: designed`, and every
   claim in it traces to a record in [`02-DECISIONS/`](../../02-DECISIONS/). An open question in the text is a
   reason to run playbook [01](01-research.md), not to start building around it.
2. **Name the owner.** Set `code:` in the design's frontmatter to the repositories from
   [`repos.md`](../repos.md). If the repository does not exist yet, add it to `repos.md` in
   the same change.
3. **Check the as-is.** Read the matching `03-DESIGN/00-as-is/` document. What is being
   replaced is stated there; if it is not, write it before changing it. Building against an
   undocumented as-is is how a shipped behaviour gets lost.
4. **Flip the status.** `status: in-progress`, `updated:` today.
5. **Build in the code repository.** HQ is not a code repository and never carries
   implementation.
6. **On completion**, run the "when something ships" section of playbook
   [02](02-graduation.md).

## Rules

- Every merge is a human checkpoint, without exception.
- Never open a pull request unprompted. A permissions list saying it is allowed is not a
  request.
- Work in an isolated worktree, never a shared checkout. A failed `cd` in a shared checkout
  commits to the wrong branch, and the error scrolls past.