diff --git a/.ceremony/AGENTS.md b/.ceremony/AGENTS.md
new file mode 100644
index 0000000..b8af0fa
--- /dev/null
+++ b/.ceremony/AGENTS.md
@@ -0,0 +1,49 @@
+# AGENTS.md — start here
+
+You are an agent working in a repo governed by
+[heavy-duty/ceremony](https://github.com/heavy-duty/ceremony). This file is
+the router: find your role below, read its file, then act. The role files
+sit beside this one — in ceremony itself at the repo root, in a governed
+repo under `.ceremony/` (a machine-managed mirror; never edit those files
+in place — they are changed in heavy-duty/ceremony, through its own flow).
+
+## Your role
+
+You were told your role when you were pointed at this repo ("you are a
+reviewer here"). That one word is your whole onboarding:
+
+| you are the… | read | your job in one line |
+|---|---|---|
+| **triage** agent | [TRIAGE.md](TRIAGE.md) | turn discussions into buildable issues — or refuse well; you are the only door issues come through |
+| **builder** agent | [BUILDER.md](BUILDER.md) | turn one `ready` issue into one PR that meets its acceptance criteria |
+| **reviewer** agent | [REVIEWER.md](REVIEWER.md) | verdicts on PRs — approve or request-changes, converge, hand to the human |
+
+Everyone, whatever the role, also reads [LABELS.md](LABELS.md) — the labels
+are the shared state machine, and misusing one lies to every other agent on
+the board.
+
+**Not told a role?** Infer it from the task: asked to review a PR → reviewer;
+asked to implement an issue → builder; asked to process discussions or the
+backlog → triage. Still ambiguous → ask before acting. Do not free-lance
+across roles in one session: a builder reviewing its own PR, or a reviewer
+pushing fixes, breaks the separation the pipeline depends on.
+
+## The pipeline you are part of
+
+```
+discussion ──▶ triage ──▶ issue ──▶ build ──▶ review ──▶ human merge ──▶ release
+ (anyone)     (agent)   (queue)    (agent)   (agents)     (human)      (ceremony)
+```
+
+Two rules bind every role:
+
+- **Only triage mints issues.** Found work? Open or extend a discussion.
+- **Only humans merge.** Convergence ends at `state:needs-human`, never at
+  a merge button.
+
+## Repo specifics
+
+What is true only of *this* repo — the review panel roster, the `scope:*`
+label set, what a drill means, code conventions — lives in the repo's own
+`CONTRIBUTING.md`. Read it after your role file; where it and the role file
+disagree on a repo-specific fact, the repo's CONTRIBUTING wins.
diff --git a/.ceremony/BUILDER.md b/.ceremony/BUILDER.md
new file mode 100644
index 0000000..a1680f1
--- /dev/null
+++ b/.ceremony/BUILDER.md
@@ -0,0 +1,76 @@
+# BUILDER.md — the builder role
+
+You turn one issue into one PR. The issue is your contract: triage wrote it
+so you can succeed without asking anyone anything — if you can't, that is a
+triage bug, and the move is to say so on the issue, not to guess.
+
+## Picking
+
+- Pick from issues labeled **`ready`** — never `blocked`, never `claimed`,
+  never an `epic` (epics organize; their children are the work).
+- Respect dependency order: inside an epic, take the earliest unblocked
+  unclaimed child. Between epics and strays, prefer the issue that unblocks
+  the most other work.
+- **One issue at a time.** Finish or release your claim before taking
+  another.
+
+## Claiming
+
+- Assign yourself, swap `ready` → `claimed`, and comment that you are
+  starting. The claim is a promise of a draft PR soon — a claim with no PR
+  and no activity is what the staleness sweep reclaims.
+- **Abandoning is fine; ghosting is not.** If you stop, say where you got to,
+  push the branch if it holds anything useful, unassign, and restore
+  `ready`.
+
+## Building
+
+- Branch per issue; open the PR **as a draft early**, `Closes #N` in the
+  body. Drafts are invisible to the reviewer panel on purpose — the draft
+  phase is yours.
+- **The issue's acceptance criteria are your definition of done.** Reproduce
+  them as a checklist in the PR body and check them honestly as you go. If
+  one turns out to be wrong or unreachable, say so on the issue and get it
+  amended by triage — do not silently ship less than the issue says.
+- Every behavior change adds one line to `CHANGELOG.md` under
+  `## Unreleased` — insert **above** the heading below it, never over it
+  (the monotonic guard's whole reason to exist).
+- Follow the repo's conventions file and match the code you touch. Tests are
+  not optional: the issue's test plan is the floor, not the ceiling.
+- **Scope discipline: the PR does the issue — whole, and nothing else.**
+  Adjacent problems you discover go to a **discussion** (or a comment on the
+  relevant issue), where triage will do its job. You do not mint issues —
+  nobody but triage does — and you do not fix drive-by findings in the same
+  PR; a reviewer cannot converge on a moving, widening target.
+
+## The review round
+
+(If you are reading this as `.ceremony/BUILDER.md` in a governed repo: the
+panel roster and any repo-specific flow notes live in that repo's own
+CONTRIBUTING; everything below is the shared flow.)
+
+1. Mark ready-for-review; request **the whole panel** (the roster is in the
+   repo's CONTRIBUTING).
+2. **Wait for every verdict, then answer the round whole** — one reply
+   covering every point, then push the fixes, then re-request exactly the
+   reviewers who did not approve. Prefer verification over argument: when a
+   reviewer doubts behavior, add the test that settles it.
+3. Never dismiss a review, never merge, never mark your own work as passed.
+   A blocking point you disagree with is answered with evidence or escalated
+   in the PR — a maintainer can be asked for a ruling; silence and
+   force-forward are not options.
+
+## Handoff
+
+When the round passes — every panel verdict approves the **current head**,
+and no `blocker:*` stands (conflicts rebased, CI green, drill recorded if
+this is a release PR) — hand it to the human, in order:
+
+1. post the round summary (what changed per round, what was verified);
+2. request the human's review;
+3. set `state:needs-human` yourself.
+
+The label write is optimistic — the reconciler validates it, and takes it
+back if the PR is not actually mergeable-right-now. Then stop: the PR is the
+human's. Address what comes back (`state:addressing`) and re-hand-off the
+same way.
diff --git a/.ceremony/LABELS.md b/.ceremony/LABELS.md
new file mode 100644
index 0000000..4be1fb3
--- /dev/null
+++ b/.ceremony/LABELS.md
@@ -0,0 +1,98 @@
+# Labels
+
+The taxonomy shared across the heavy-duty repos. Only the `scope:` set
+differs per repo (each repo's `.github/labels.conf` names its actual
+surfaces); everything else below is core and identical everywhere, created by
+the labels workflow's bootstrap dispatch (issue #10).
+
+Two state machines share the taxonomy: the **PR machine** (proven in
+box/rig/cast, reconciled by machinery) and the **issue flow** (the
+triage → build queue, doctrine-enforced today, machinery to follow —
+issue #18). One rule joins everything: **states are machine-owned, intent
+labels are hand-set** — a hand-moved state label is a lie waiting to happen,
+and the reconciler recomputes it from GitHub's own facts.
+
+## PR state — who is the ball with? (exactly one per open PR)
+
+| Label | Color | Waiting on |
+|---|---|---|
+| `state:building` | `#FBCA04` | the builder — PR is a draft |
+| `state:bots-reviewing` | `#1D76DB` | the reviewer panel to finish the round (a request is live) |
+| `state:addressing` | `#D93F0B` | the builder — round complete without full approval, or nobody was asked, or a blocker is up |
+| `state:needs-human` | `#8250DF` | the human — **this PR could be merged right now**: zero blockers, whole panel approved the current head |
+
+`bots-reviewing` vs `addressing` is deliberate: staleness in the first means
+*poke the reviewers*, in the second *the builder dropped the ball*. And
+`state:needs-human` means exactly one thing — a human could merge this now —
+so it requires zero blockers and head-current approvals; anything less and
+the reconciler takes it back. The author sets it at handoff (the one
+hand-set state); the `labeled` event fires the sweep that validates the
+write within seconds.
+
+## PR blockers — what is in the way? (facts, as many as apply)
+
+| Label | Color | Means |
+|---|---|---|
+| `blocker:conflict` | `#B60205` | does not merge — the builder owes a **rebase** |
+| `blocker:ci-red` | `#B60205` | a check failed — the builder owes a **fix**, which a rebase will not provide |
+| `blocker:unrequested` | `#E99695` | this head has no verdict from somebody, and nobody was asked |
+| `blocker:drill-pending` | `#B60205` | a `release` PR whose version has no `drills/X.Y.Z.md` record — correct but unevidenced (maintainer-created label; the bot bootstrap 403s on it) |
+
+States answer *whose ball*; blockers answer *what's in the way*. They are
+separate axes because the single-label version kept lying — independent facts
+projected onto one totally-ordered label meant one always won and the losers
+vanished off the board (box's `state:needs-rebase`, retired: the reconciler
+strips it on sight).
+
+## Issue flow — the work queue (exactly one per open, triaged, non-epic issue)
+
+| Label | Color | Means | Set by |
+|---|---|---|---|
+| `needs-triage` | `#FBCA04` | an issue that did not come through triage — it owes normalization or conversion back to a discussion | anyone who spots one; cleared by triage |
+| `ready` | `#0E8A16` | triaged, spec complete, unblocked — a builder can start now and succeed | triage |
+| `claimed` | `#1D76DB` | a builder owns it: assignee set, a draft PR expected shortly | the claiming builder |
+| `blocked` | `#6A737D` | waiting on another issue or PR (`Blocked by #N` in the body names it) | triage; anyone may correct it |
+| `epic` | `#5319E7` | organizes other issues via a dependency-ordered task list; **builders never pick an epic** | triage |
+
+The invariant a board scan relies on: every open issue is either
+`needs-triage`, `epic`, or carries exactly one of `ready` / `claimed` /
+`blocked`. A `claimed` issue with no open PR and no activity is what the
+staleness sweep will reclaim (issue #18); until that machinery exists,
+[TRIAGE.md](TRIAGE.md) owns the hygiene by hand.
+
+## Cross-cutting (PRs and issues)
+
+| Label | Color | Meaning |
+|---|---|---|
+| `stale` | `#B60205` | no activity for 48h — sweep-managed, never hand-applied |
+| `blocked` | `#6A737D` | (see above — same label serves PRs waiting on another PR/issue; legitimately quiet, the staleness sweep skips it) |
+| `release` | `#0E8A16` | release flow, versioning, packaging work — and the ceremony PR itself |
+| `merge-next` | `#0E8A16` | head of the merge queue — merge this one next. Queue order is *intent*: never set by the reconciler, only cleared by it |
+
+## Scope — which surface? (PRs and issues, any number)
+
+All scopes share one calm color, `#C5DEF5` — scopes locate, states alert. The
+set is per-repo (`.github/labels.conf`); PRs get theirs from changed paths via
+actions/labeler, issues get theirs from triage. This repo's set:
+
+| Label | Covers |
+|---|---|
+| `scope:release-flow` | the reusable release workflow, decide, the doors |
+| `scope:guards` | changelog-armed / changelog-monotonic / drill-recorded |
+| `scope:labels` | the labels workflow, reconciler, this taxonomy |
+| `scope:docs` | README doctrine, CONSUMERS.md, the role files |
+
+## Issue types
+
+`bug`, `enhancement`, `documentation` — issues only, set by triage. PRs carry
+their type in the conventional title (`feat:`, `fix:`, `docs:`); a type label
+on a PR would say the same thing twice and drift.
+
+## Maintenance
+
+The labels workflow (issue #10) recomputes PR state statelessly on PR events
+plus a 15-minute advisory cron, and bootstraps this taxonomy idempotently on
+manual dispatch. Issue-flow labels are doctrine-owned until #18 lands
+machinery for them. Default GitHub labels (`duplicate`, `invalid`,
+`question`, `wontfix`, `help wanted`, `good first issue`) are deleted at
+bootstrap — a `question` is a discussion, not an issue.
diff --git a/.ceremony/README.md b/.ceremony/README.md
new file mode 100644
index 0000000..34bc9c4
--- /dev/null
+++ b/.ceremony/README.md
@@ -0,0 +1,14 @@
+# .ceremony/ — the vendored doctrine mirror
+
+Machine-managed by heavy-duty/ceremony's `actions/docs-sync`. Never edit
+these files here: they are byte-identical copies of
+[heavy-duty/ceremony](https://github.com/heavy-duty/ceremony) at this
+repository's pinned ref, and CI re-diffs them on every PR — a hand edit
+goes red. They are changed in heavy-duty/ceremony, through its own flow,
+and arrive here when the pin moves.
+
+The pin lives in `.github/workflows/release.yml` — the single
+`uses: heavy-duty/ceremony/.github/workflows/release.yml@<ref>` line. One
+pin governs machinery and doctrine alike: bump it and re-sync this mirror
+in the same PR (`docs-sync --fix`, or let the red check on the bump PR say
+what is stale).
diff --git a/.ceremony/REVIEWER.md b/.ceremony/REVIEWER.md
new file mode 100644
index 0000000..17ac893
--- /dev/null
+++ b/.ceremony/REVIEWER.md
@@ -0,0 +1,70 @@
+# REVIEWER.md — the reviewer role
+
+You are one voice on a panel. The panel's job is to converge — on an
+approval the human can trust, or on a precise statement of what is wrong.
+The machine reads only your **verdict**; humans read your reasons.
+
+## The verdict doctrine
+
+- **Every review ends in a verdict**: approve, or request changes. A
+  comment-only review is a non-verdict — it does not say whether the round
+  passed, the state machine treats it as not-approved, and the PR simply
+  stalls. If you have an opinion, you have a verdict; commenting without one
+  only wedges the flow.
+- **The verdict carries blockingness only; the body carries the feedback.**
+  Non-blocking nits ride an **approval**, and the builder addresses them at
+  their discretion. Anything blocking — including a question whose answer
+  gates your approval — is **request changes**, saying exactly what
+  unblocks it.
+- An approval you would not defend to the human is a defect. You are not
+  being asked to be agreeable; you are being asked to be right.
+
+## What you review against
+
+In order of authority:
+
+1. **The issue's acceptance criteria** — the PR's `Closes #N` names your
+   spec. Check every criterion; a PR that ships less than the issue says is
+   a request-changes even if the code is beautiful.
+2. **The repo's load-bearing constraints** — the rules bought with
+   incidents (in ceremony itself: issue #1's constraint list; in a governed
+   repo: its own CONTRIBUTING plus ceremony's README). A change that
+   "simplifies away" a constraint gets request-changes with a link to the
+   incident that made the rule.
+3. **The code itself** — correctness first, then tests (does the test plan's
+   floor exist? do the failure cases actually fail?), then conventions.
+   Changelog line present for behavior changes; comments carry why, not
+   what.
+
+**Verify over opine.** Run what can be run; construct the failing input; a
+test settles what a comment thread can't. A review that says "I ran X and
+saw Y" outranks one that says "this looks like it might".
+
+## What you do not do
+
+- **Re-litigate the spec.** The issue's decisions were made in triage and,
+  above it, in a discussion where humans had their say. If you think the
+  spec itself is wrong, say so with reasons — as a comment pointing at the
+  discussion, while still reviewing the implementation against the spec as
+  written. Spec changes go through triage, not through a review round.
+- **Merge, or tell the builder to merge.** Convergence hands the PR to a
+  human; only humans merge.
+- **Approve a moving target.** Your approval is of a specific head. If the
+  builder pushes after your approval, GitHub stales it — that is correct,
+  and the builder owes a re-request, not an assumption.
+
+## The round rhythm
+
+- Review the **whole PR at the current head** each round, not just the diff
+  since your last comments — the fix for someone else's point can break
+  yours.
+- The builder answers rounds whole and re-requests you; until re-requested,
+  the ball is not yours (`state:addressing` is the builder working — pile-on
+  reviews mid-address just churn the target).
+- Convergence = every panel verdict approves the current head, no
+  `blocker:*` standing. Then the builder hands off (`state:needs-human`) and
+  the panel's job is done.
+- If a round exposes a disagreement **within the panel**, argue it in the PR
+  with evidence until one side concedes or the builder escalates to the
+  maintainer for a ruling. Two reviewers pulling a builder in opposite
+  directions without resolution is a panel failure, not a builder failure.
diff --git a/.ceremony/TRIAGE.md b/.ceremony/TRIAGE.md
new file mode 100644
index 0000000..3dcf655
--- /dev/null
+++ b/.ceremony/TRIAGE.md
@@ -0,0 +1,95 @@
+# TRIAGE.md — the triage role
+
+You are the only door issues come through. Humans and agents open
+**discussions**; you decide what becomes work. The quality of every
+downstream stage — a builder succeeding without asking, a reviewer having a
+spec to review against — is set here, by you, and nowhere else.
+
+## Why this door exists
+
+Discussions are allowed to be ambiguous; issues are not. An issue is a work
+order a builder must be able to execute **without asking anyone anything**.
+Keeping one accountable role between the two is what keeps the bar from
+eroding — the moment anyone can mint an issue, the backlog fills with
+"improve X" entries nobody can build, and builders start guessing. Guessing
+is the failure this whole flow exists to prevent.
+
+## Your inputs
+
+- **Every open discussion** in the repo you serve.
+- **Stray issues** — anything filed directly, by anyone. Label it
+  `needs-triage`, then either bring it up to contract (below) or convert its
+  substance back into a discussion and close it, saying why. Do not shame the
+  filer; do route the work correctly.
+
+## For each discussion, converge on exactly one outcome
+
+1. **Answer.** The question has an answer, the bug is not one, the idea is
+   already shipped or already tracked. Reply with the answer (link the code,
+   the doc, the existing issue), mark answered.
+2. **Ask.** Real work is hiding behind ambiguity you cannot resolve from the
+   repo, its history, or its docs. Ask the 2–3 pointed questions whose
+   answers would let you write the issue — then stop and wait. Do not mint an
+   issue that carries the ambiguity forward; that just moves your job onto
+   the builder.
+3. **Escalate.** The blocker is a *decision* only a human owns — scope,
+   money, product direction, breaking a public contract. Say precisely what
+   the decision is, list the options with your recommendation, and name the
+   decider. The discussion is where humans decide; wait there.
+4. **Decline.** Real idea, wrong repo or wrong time. Say why plainly, link
+   where it belongs if anywhere, close. A refusal with reasons is a good
+   outcome; a zombie discussion is not.
+5. **Accept.** It justifies work → mint the issue(s). The contract below is
+   the bar.
+
+## The issue contract
+
+Every issue you mint carries, in this order:
+
+- **A title that names the deliverable** — "lib/version.sh — one version
+  abstraction, two backends", never "improve version handling".
+- **Context**: why this exists, with links — the discussion it came from,
+  the code it touches (permalinks at a pinned SHA, so line references cannot
+  rot), prior art in sibling repos.
+- **The spec**: decisions made, not options listed. If the spec still has an
+  open question, the issue is not ready to exist — go back to outcome 2 or 3.
+- **Tasks**: the steps, checkboxed, in order.
+- **Acceptance criteria**: checkboxed, verifiable, and honest — these become
+  the builder's definition of done and the reviewer's review spec, verbatim.
+- **Test plan**: what proves it, including the cases that must fail.
+- **Dependencies**: `Blocked by #N` / `Blocks #N`, and `Part of #E` when an
+  epic organizes it.
+- **Labels**: type (`bug`/`enhancement`/`documentation`), `scope:*`, and
+  exactly one of `ready` / `blocked` (see [LABELS.md](LABELS.md)).
+
+The bar, stated once: **a competent builder who has read only this issue and
+the repo can succeed.** The release-ceremony epic and its children
+(heavy-duty/ceremony#1–#16) are the house exemplars — that is the density
+expected.
+
+## Multi-issue work
+
+When an acceptance produces more than one issue, mint an **epic** (`epic`
+label): the approach, the decisions, the constraint list, and a
+dependency-ordered task list of child issues. Children reference the epic;
+the epic's checklist is the progress view. Builders never pick the epic
+itself. Keep the checklist current — a stale epic misleads every scan.
+
+## Backlog hygiene (yours until #18 automates it)
+
+- **Dedup before minting** — search issues *and* closed issues; extend or
+  reopen before duplicating.
+- **Flip `blocked` → `ready`** when the named dependency lands.
+- **Reclaim abandoned claims**: `claimed` + no open PR + no activity →
+  comment, unassign, restore `ready`.
+- **Close obsolete issues** with the reason and a link to what obsoleted
+  them. Every label on every open issue stays true; the board is only worth
+  scanning if it does not lie.
+
+## What you never do
+
+- Write code, review code, or build the thing yourself.
+- Assign a builder — builders pick and claim ([BUILDER.md](BUILDER.md)).
+- Make the human's decisions (outcome 3 exists for those), or soften a
+  refusal into a vague issue to avoid saying no.
+- Mint an issue to "discuss" something — that is a discussion.
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 0000000..e047dee
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,7 @@
+# AGENTS.md — start at .ceremony/
+
+This repository is governed by
+[heavy-duty/ceremony](https://github.com/heavy-duty/ceremony). Read
+`.ceremony/AGENTS.md` first — it routes you to your role file, vendored
+beside it. Repo specifics (the review panel roster, the scope labels, what
+a drill means here, code conventions) live in CONTRIBUTING.md.
diff --git a/LABELS.md b/LABELS.md
deleted file mode 100644
index b589208..0000000
--- a/LABELS.md
+++ /dev/null
@@ -1,182 +0,0 @@
-# Labels
-
-How this repo uses GitHub labels. The taxonomy is shared across the
-heavy-duty repos (box, rig, cast) — only the `scope:` set differs per repo,
-because it names this repo's actual surfaces.
-
-## State — who is the ball with? (PRs, exactly one)
-
-Every open PR carries exactly one `state:` label, and it answers the only
-question a board scan actually asks: *who is this PR waiting on?* The states
-mirror the review loop this repo runs — PRs open as drafts, three reviewer
-bots pick up ready PRs with reviews requested, each round is answered in a
-single reply, and a human takes the final review.
-
-| Label | Color | Waiting on | Enters when | Leaves when |
-|---|---|---|---|---|
-| `state:building` | `#FBCA04` | the coding agent, still building | PR opened as draft | marked ready + bot reviews requested |
-| `state:bots-reviewing` | `#1D76DB` | the reviewer bots to finish the round | ready with reviews requested, or fixes pushed and reviews re-requested | all three bots have reviewed the round |
-| `state:addressing` | `#D93F0B` | the coding agent to reply, fix, or ask | all bots reviewed and not all approved; or nobody was asked; or a blocker is up | the round-reply is posted and fixes pushed — and any blocker named alongside is cleared |
-| `state:needs-human` | `#8250DF` | the human reviewer | the PR **could be merged right now**: no blockers, three formal head-current approvals — and the human review is requested | merged — or changes requested, which cycles back to `state:addressing` |
-
-`bots-reviewing` and `addressing` are deliberately distinct: staleness in the
-first means *poke the bots*, staleness in the second means *the agent dropped
-the ball*. Collapsing them loses exactly the information a sweep needs.
-`bots-reviewing` therefore means strictly *a request is live and an answer is
-coming* — a PR nobody was asked to review is the agent's ball, not the bots'.
-
-## The second axis: `blocker:*`
-
-State answers *whose ball is it*. Blockers answer *what is in the way*, and
-unlike states they are *facts about the branch* — mutually independent, so a
-PR carries as many as apply.
-
-| Label | Color | Means | Clears when |
-|---|---|---|---|
-| `blocker:conflict` | `#B60205` | GitHub says `CONFLICTING` — the agent owes a **rebase** | it merges cleanly |
-| `blocker:ci-red` | `#B60205` | a check failed — the agent owes a **fix**, which a rebase will not provide | checks are green |
-| `blocker:unrequested` | `#E99695` | this head has no verdict from somebody — never reviewed, or staled by a push — and **nobody was asked** for one | reviews are requested |
-| `blocker:drill-pending` | `#E99695` | a `release` PR whose version has **no drill record** at [`drills/<version>.md`](drills/README.md) — the ceremony is correct but *unevidenced* | the record (or a recorded maintainer waiver) lands for that version |
-
-`blocker:drill-pending` is the only blocker that says nothing is *wrong* with
-the code. The version bump, the stamp, the re-arm can all be perfect; what is
-missing is the evidence that anyone ran the real-hardware drill against the
-tree about to ship. It clears on a RECORD, not on a pass — a recorded waiver
-clears it too, which is the point: skipping the drill stays possible and stays
-visible. `.github/scripts/drill-recorded.sh` is what turns CI red meanwhile.
-
-**The label does not exist in the repo yet.** Creating a label needs push
-access and the bot account gets a 403, so a maintainer account has to run the
-`gh label create` line below (or the workflow's manual dispatch) once. Until
-then the reconciler cannot apply it, and plain `blocked` stands in — coarser,
-but it keeps an unevidenced release off the merge path, which is the job.
-
-One rule joins the axes: **`state:needs-human` requires zero blockers.** Any
-blocker means the work is the agent's, whatever the review round says.
-
-This split exists because the single-label version kept lying. Independent
-facts were projected onto one totally-ordered label, so one always had to win
-and the losers vanished off the board: a PR that was *both* conflicted and red
-could only say one of them, and `needs-rebase` told an agent to rebase when
-what it actually owed was a bug fix. Precedence between two blockers is not a
-question a set has to answer, which is why every ordering bug this machine has
-had — `needs-human` surviving a conflict, `MISSING` swallowing `STALE` — lived
-on the axis that had to be totally ordered.
-
-`state:needs-rebase` was the first attempt at this and is **retired**; the
-reconciler strips it on sight so no PR is left carrying a label nothing
-recomputes.
-
-**`state:needs-human` means one thing: a human could merge this right now.**
-The label is the only signal a maintainer scanning the board (or a phone)
-actually reads, and one that says "your turn" on an unmergeable PR is worse
-than no label at all. So beyond the blockers, one review fact also outranks an
-explicit human request:
-
-- **nobody reviewed *this* head** — every approval staled by a push → `state:addressing`,
-  because the agent owes a re-request
-
-That case is more dangerous than any blocker: a blocked PR at least shows an X
-or a disabled merge button, while a staled-approval PR reads green, mergeable
-and "waiting on the human" over code no reviewer has seen.
-
-`UNKNOWN` mergeability is deliberately **not** treated as a conflict. GitHub
-reports it for about a minute after every merge while it recomputes, and
-flapping every open PR through `blocker:conflict` on each merge would be worse
-than the bug this fixes. A failed read of either branch fact degrades to the
-same "do not know" value, for the same reason.
-
-An *unfinished* round still yields to an explicit human request — a maintainer
-pulling a PR to themselves early is a deliberate act. `MISSING` (nobody has
-reviewed yet) and `STALE` (everyone reviewed something else) are different
-facts and are treated differently.
-
-## Cross-cutting (PRs and issues)
-
-| Label | Color | Meaning |
-|---|---|---|
-| `stale` | `#B60205` | No activity for 48h. Sweep-managed, never hand-applied. `state:building` + `stale` is precisely a forgotten draft. |
-| `blocked` | `#6A737D` | Waiting on another PR or issue to land first. Quiet *legitimately* — the staleness sweep skips it. |
-| `release` | `#0E8A16` | Release flow, versioning, and packaging work. |
-| `merge-next` | `#0E8A16` | Head of the merge queue — **merge this one next**. Queue order is *intent* (which PR lands first, given how they conflict), so the reconciler never sets it: you or the agent maintaining the queue do. The reconciler only **clears** it, the moment the PR stops being something a human could merge — so it cannot go stale the way `state:needs-human` did. |
-
-## Scope — which surface? (PRs and issues, any number)
-
-All scopes share one calm color, `#C5DEF5` — scopes locate, states alert.
-
-| Label | Covers |
-|---|---|
-| `scope:capture` | `draft.ts`, `capture.ts` — reading the live world into a manifest |
-| `scope:apply` | `apply.ts`, `diff.ts`, `destroy.ts` — reconciling the manifest onto Coolify |
-| `scope:secrets` | `secrets.ts`, age handling, the encrypted state repo |
-| `scope:fleet` | `fleet.ts`, `inventory.ts`, `server.ts` — placement and the server side |
-| `scope:manifest` | `manifest.ts`, `resolve.ts`, `envtemplate.ts` — the manifest language itself |
-| `scope:coolify-api` | `coolify.ts`, the OpenAPI reference — the client surface |
-
-## Issue types
-
-`bug`, `enhancement`, `documentation` — issues only. PRs carry their type in
-the conventional title (`feat:`, `fix:`, `docs:`), so typing a PR with a label
-would just say the same thing twice, drifting apart eventually.
-
-## Maintenance
-
-State labels are machine-owned, with exactly one exception. Every state above
-is derivable from GitHub's own facts — the draft flag, requested reviewers,
-review states, push timestamps — so the labels workflow
-([.github/workflows/labels.yml](.github/workflows/labels.yml)) recomputes the
-state and reconciles labels statelessly, on PR events (label changes included)
-plus a 15-minute cron. A hand-moved label is a lie waiting to happen; the
-workflow asserts the effective state instead.
-
-The exception is `state:needs-human`, which the author sets at handoff
-([CONTRIBUTING.md](CONTRIBUTING.md), step 6). That is an optimistic write, not
-a transfer of ownership: because `pull_request_target: labeled` wakes the
-workflow, the author's own label write fires the sweep that validates it, and
-a handoff that had not earned the label is corrected within seconds.
-
-It exists because the wake signal was missing. There is no
-`pull_request_review_target` — on fork PRs, which is all of them here,
-`pull_request_review` runs read-only and cannot label anything — so the moment
-the label becomes true, the third approval landing, fired nothing at all. What
-was left was the `*/15` cron, and GitHub deprioritises short intervals hard
-enough that the delivered rate is closer to hourly. The label could therefore
-lag the round it described by hours, worst on the quietest repo: every sweep
-reconciles the whole board, so a busy repo stays fresh by piggybacking on
-unrelated PR events, while a quiet one depends on the cron most and receives
-it least. `scope:` labels on PRs are applied from the changed
-paths by actions/labeler ([.github/labeler.yml](.github/labeler.yml));
-[CONTRIBUTING.md](CONTRIBUTING.md) says who sets what.
-
-The same workflow bootstraps the taxonomy: a manual dispatch creates any
-missing label idempotently. To create them by hand (needs push access):
-
-```sh
-gh label create "state:building"       --color FBCA04 --description "PR is a draft — the coding agent is still building" --force
-gh label create "state:bots-reviewing" --color 1D76DB --description "Waiting on the bot reviewers to finish the round" --force
-gh label create "state:addressing"     --color D93F0B --description "All bots reviewed — coding agent owes the single reply + fixes" --force
-gh label create "blocker:conflict"     --color B60205 --description "Does not merge — the branch conflicts and the agent owes a rebase" --force
-gh label create "blocker:ci-red"       --color B60205 --description "A check is failing — the agent owes a fix (not a rebase)" --force
-gh label create "blocker:unrequested"  --color E99695 --description "Somebody still owes a verdict and nobody was asked for one" --force
-# needs a MAINTAINER account — the bot 403s on label creation, and until this
-# runs the reconciler cannot apply it and `blocked` stands in.
-gh label create "blocker:drill-pending" --color E99695 --description "Release PR with no drill record at drills/<version>.md — ceremony correct, unevidenced" --force
-# retired — the reconciler strips it; delete it once no PR carries it
-# gh label delete "state:needs-rebase"
-gh label create "state:needs-human"    --color 8250DF --description "No blockers, all bots approve — waiting on the human reviewer" --force
-gh label create "merge-next"           --color 0E8A16 --description "Head of the merge queue — merge this one next (set by hand/agent, cleared here)" --force
-gh label create "stale"                --color B60205 --description "No activity for 48h — needs a poke (sweep-managed)" --force
-gh label create "blocked"              --color 6A737D --description "Waiting on another PR or issue to land first" --force
-gh label create "release"              --color 0E8A16 --description "Release flow and version/packaging work" --force
-gh label create "scope:capture"        --color C5DEF5 --description "draft/capture — reading the live world into a manifest" --force
-gh label create "scope:apply"          --color C5DEF5 --description "apply/diff/destroy — reconciling onto Coolify" --force
-gh label create "scope:secrets"        --color C5DEF5 --description "secrets, age, the encrypted state repo" --force
-gh label create "scope:fleet"          --color C5DEF5 --description "fleet/inventory/server — placement" --force
-gh label create "scope:manifest"       --color C5DEF5 --description "manifest/resolve/envtemplate — the manifest language" --force
-gh label create "scope:coolify-api"    --color C5DEF5 --description "coolify.ts + OpenAPI reference — the client" --force
-# delete is not an upsert: a label that is already gone exits non-zero. Swallow
-# that, so this block converges on re-run instead of erroring after first success.
-for L in duplicate invalid question wontfix "help wanted" "good first issue"; do
-  gh label delete "$L" --yes 2>/dev/null || true
-done
-```