---
name: build
description: >
  Plan-then-execute implementation loop against SPEC.md tasks. Operates single-threaded on main agent thread.
  Executes tasks in order, runs verification tests as external oracles, and triggers backprop on failure.
  Use when asked to "build", "implement spec", "build §T.n", "build next task", or "run the build".
concerns: [system-one-balance]
---

# Build — Implement Spec

Single-threaded native plan → execute loop against `SPEC.md`.

---

## Phase 0: Setup and Protocols

1. **Verify Prerequisites**:
   - `SPEC.md` must exist at the project root. If absent, defer to `spec` to author it first.
   - Read §R if present: external facts the build must honor, never contradict or re-derive.
   - For high-blast-radius changes (shared modules, auth, payments, database migrations), confirm `/review` has run.

---

## Phase 1: Ingest and Check

1. Parse invocation arguments:
   - `§T.n`: Target specific task row.
   - `--next`: Target the lowest-numbered row with status `.` or `~`.
   - `--all` (or empty): Execute every pending `.` row in sequential order.
2. Confirm verification oracle:
   - Identify the exact automated command (e.g. `pytest`, `cargo test`, `npm test`) that verifies completion.

---

## Phase 2: Processing (Core Logic)

### Step 1: Plan Task Implementation
For the chosen task(s):
1. Cite every §V invariant that applies; the implementation must satisfy all.
2. Cite every §I interface touched; preserve specified signatures and shapes.
3. List files to create or modify.
4. Establish the verification contract: specify which concrete test will prove each §V touched.

### Step 2: Sequential Execution
For each task in order:
1. Flip `§T.n` status cell from `.` → `~` in `SPEC.md`.
2. Edit code according to plan.
3. Run the verification command.
4. **Pass**: Flip `~` → `x` in `SPEC.md`. Create atomic commit: `T<n>: <task description>`.
5. **Fail**: Do NOT retry blindly; route to Failure Recovery.

### Step 3: Failure Recovery & Backprop
When a verification test fails:
1. Inspect failure output.
2. Determine failure classification:
   - **Code defect in task**: Fix code and re-test.
   - **Spec defect or unhandled edge case**: Invoke `backprop` with `bug: <cause>` to record in §B and draft §V before resuming.

---

## Phase 3: The System One Balance Pass

- **Augment, Don't Handcuff**:
  - Keep execution single-threaded on the main agent; avoid uncoordinated background subagent sprawl.
  - Flip only §T status cells in `SPEC.md` during build; leave architectural changes to `spec`.
  - Avoid speculative work beyond the assigned task.

---

## Phase 4: Output Execution & Verification

A task is verified as complete (`x`) only when:
1. The verification command exits with code 0.
2. Every §V touched has an automated passing test.
3. Full test suite passes with zero regressions.
4. `SPEC.md` reflects current completion state.