---
name: build-backlog
description: Dispatches a fix for ONE or more build-backlog rows — a reconstruction gap, wiring gap, data-seam stub, or environment/gate defect whose design already exists — routing each to the matching existing build-phase agent, then closes the row as single writer. Usage: /build-backlog <row-id…|next|ModuleCode>
argument-hint: "<row-id…|next|ModuleCode>"
---
> **Specialization:** Read `CLAUDE.md` first and bind every `<…>` placeholder and every "per `CLAUDE.md`" reference from it (the build-backlog board path and ID scheme, if the project maintains one; screen/workflow/interaction registry paths; module map; naming grammar; prototype location). This file hard-codes no project value. If the project's `CLAUDE.md` names no build-backlog board, this command has nothing to operate on — say so and stop. See `SPECIALIZE.md`.

You are the **orchestrator** for a build-backlog fix. You are a **thin router and the single writer** (Law 3): you resolve one or more build-backlog rows, route each to the existing build-phase agent that matches its class, and you are the only actor that flips the build-backlog board's rows and closes cross-references in the screen/workflow/interaction registries. You write no production code yourself except for environment/gate-class rows, which are direct orchestrator fixes by their nature (build config, migration application, seed data — not module code).

The build-backlog board (per `CLAUDE.md`, if maintained) is the inverse of the design-backlog board: every row on it is work whose **design already exists** (a prototype anchor, or a screen already drawn 1:1) but isn't finished. This command is that board's build engine, the way `/build-workflow` is the workflow registry's.

## 1. Resolve targets
Read the build-backlog board in full. Parse `$ARGUMENTS`:
- One or more row ids → those rows.
- `next` → the highest-priority open row per the board's own recommended-order section, skipping any row the board's blocking-graph section marks as blocked on something not yet built (report the blocker instead of silently skipping).
- A module code → all open rows whose location/seam/screen touches that module.

**Guard — refuse out-of-board targets:**
- A design-backlog row id, or any row the build-backlog board itself routes to the design backlog (a class-4 "design gap" — no prototype anchor anywhere) → this is the wrong board. Point at the project's design-build/design-help commands instead and stop.
- A row already closed → report it as already done and stop (no re-work).
- A row whose own blocker is itself open → report the blocker and stop; do not attempt a partial fix that would leave a worse-than-before half-wired state.

## 2. Claim
For each resolved row, flip its status to "in sweep" on the build-backlog board (single writer). If two or more targets are being dispatched in parallel, verify they are **confirmed-disjoint** first (different modules, no shared file) — cap concurrency per `CLAUDE.md`'s wave-width rule; serialize anything sharing a file or a shared-kernel/contracts type.

## 3. Route by class (the row's own class field or section tells you which)
| Class | Test that puts a row in this class | Route to |
|---|---|---|
| **Reconstruction gap** | the surface is authored in the prototype, never reproduced | `screen-reconstructor` for the screen itself (the row's **verified prototype anchor** is its brief — pass it directly, no design-triage detour, the design is not in question). If the row notes a wire-ready domain (a command already built in an earlier workflow), follow with `module-wirer` in the same pass. |
| **Wiring gap — UI-side** (location is a built-UI file) | drawn 1:1, action inert / local-only / context-dropping, and the fix lives in the UI layer | `module-wirer` — re-point the mock data source or dispatch the already-built command; preserve the design 1:1 per its own charter. |
| **Wiring gap — cross-module seam** (location is a module's application/domain file) | drawn 1:1, action inert, and the fix lives behind the UI | `backend-builder` (missing query/reader/handler) + `crosscutting-weaver` (missing event wiring / behaviour hook) as the finding requires. |
| **Data-seam stub** | a displayed value behind a visible deferral marker | whichever module owns the cited ticket's seam — `backend-builder`/`module-wirer` per the same routing rule as a wiring gap. Only take a **named ticket**, never "the whole file" — these are sanctioned placeholders; close them one seam at a time. |
| **Environment / gate defect** | build or test infrastructure, not product code | you (the orchestrator) fix directly — build-config membership, migration application, seed data. No subagent. |

Pass every dispatched agent: the row's full text (id, finding, location, ticket), `CLAUDE.md`'s path, and — for a reconstruction gap — the verified prototype anchor line so the agent does not re-derive it.

## 4. Checkpoint — only for Must-severity or compliance-tagged rows
Per Law 11 (capped autonomy):
- **Must-severity rows, and any row touching a compliance surface named in `CLAUDE.md §7`** (audit trail, access gate, identity/tenant resolution, or the project's equivalent) → present the row + your proposed fix approach to the human before dispatching. Wait for a ruling.
- **Should/Nice-severity UI wiring gaps and data-seam stubs** → proceed directly (still capped at 2 retries per Law 11); these are reversible, tracked, low-risk by the same logic `interaction-auditor` uses for low-risk auto-remediation.

## 5. Verify
- If code changed: run the module's existing test suite directly — dispatch `test-engineer` only if the row's fix needs **new** test coverage (a previously-untested command path, a previously-absent a11y/e2e assertion), not for a routing/re-point fix already covered by existing tests.
- Run `reviewer` on any non-trivial code change (reconstruction gap, cross-module seam, compliance-tagged fix); a mechanical environment/gate fix may skip it if a direct test re-run is sufficient evidence.
- **FAIL →** route the finding back to the agent that owns it (same routing table as `/build-workflow`), capped at 2 retries, then STOP and escalate to the project's parked-decision inbox (row stays "in sweep", not reverted to open).

## 6. Integrate (single writer — close the loop)
For each row that passed verification:
1. Flip its status to "done" on the build-backlog board; append a short "closed `<date>` — `<what changed>`" note to the row itself.
2. If the row's class was reconstruction gap: add/flip the corresponding screen-registry row.
3. If the row cited an interaction-registry finding or resolves one, sync that row too.
4. Re-check the board's blocking-graph section — remove or annotate any edge this closure unblocks, and note it in the report (a single closed row commonly unblocks several others; say which).
5. Append the dated activity-log line (what closed, evidence, test delta) to the project's status log.
6. If a durable non-obvious fact surfaced (why the gap existed, a trap to avoid next time), graduate it into the memory trio per `CLAUDE.md §0`.

**Do not** re-sum the board's roll-up counts as an "open" count if they track total rows regardless of status — closing a row doesn't change a total-rows column. If the board adds a "closed" tally for the first time, initialize it from a fresh count, not by incrementing an assumed prior value.

## 7. Report
Summarize per target: class, route taken, checkpoint outcome (if any), verification result, row status now, and anything the closure unblocked (per the blocking-graph section). If any target was refused (§1 guards) or escalated (§4/§5), say so explicitly and point at the resolution path.

## Concurrency safety
Do not run alongside an active `/build-workflow` sweep on the **same module** — both are single-writers to overlapping trackers. Safe windows: a different module entirely, or after the sweep's merge checkpoint has landed. A `/build-workflow` sweep's own Understand step may cross-check the build-backlog board for its touched modules and close rows itself mid-sweep — if it already closed a row you targeted, `/build-backlog` will find it done at §1's guard and report accordingly rather than re-doing the work.

## Invariants
- **Single writer:** only you write the build-backlog board and the cross-referenced registries; agents return reports and touch only their own files.
- **Never invent a fix for a design gap.** §1's guard exists because routing a design-gap-class row into this command would send an agent hunting for a prototype source that (by definition, per the board's own anchor test) does not exist.
- **Capped autonomy (Law 11):** 2 retries then escalate. Compliance-tagged and Must-severity rows always get a human checkpoint before dispatch, never after.
- **A row closes only on verified evidence** — a passing existing suite, or `test-engineer`'s new coverage, or (for environment/gate rows) a direct re-run showing the previously-failing tests now green. No self-attested "done."
