/build

name: build
description: >
  Phase 3 of AI Closed-Loop Programming — the Build phase, and the driver of the
  whole loop: locate the project on the chain, name the next act, design and
  declare tests, dispatch code/flash/verify, correct until the tests run clean.
  Owns the test plan, test design, audit, reconcile, and the change-request
  procedure. Use this skill whenever the user wants to build or continue building
  a harnessed project, asks "what's next" or "where are we", wants a feature
  added (change request), mentions test design, the test plan, xfail, audit,
  coverage gaps, reconciling drifted code, or "run the loop" — and for Phase 2
  work when invoked via /commission.

Build — the loop's driver (Method skill)

**AI Closed-Loop Programming**: open-loop AI coding generates and hopes; AICLP feeds back reality — the code runs on real hardware, tests derived from the FSD measure it against the spec, the error corrects the next iteration. The loop exits at zero: tests green.

| Control loop | Here | |---|---| | Setpoint | The FSD — what must be true | | Plant | Firmware on the real chip | | Sensor | Tests derived from the FSD, run on the testbench | | Error signal | Failing tests | | Controller | The AI, correcting until error = 0 |

This skill drives Phases 2 and 3 of the journey. `/commission` and `/build` are two doors into it; the phase is **derived from state, never chosen by the command typed**.

Each phase ends at a **gate** — not a milestone. A milestone is a marker you pass; a gate has to open, and it can send you back. Every gate is **derived, never declared**, and every one is *checked*: the owning skill states its deliverables and the check that opens it.

> **Run the check in a fresh checker that did not author the work** — the > project's generated gate file plus the repo, nothing else, and **never > memory or a summary of the session's own work** (`references/gate-checks.md`). **If any requirement of the gate is unmet, > name it, loop back to the step that owns it, fix it, and re-run the whole > check with a new checker** — not only the part that failed. Never carry a > known deficiency forward, and never enter a phase whose predecessor's gate > is still shut.

This is the loop's own discipline applied to itself: a deficiency waved through is found later at many times the cost, and every result produced after it is suspect — nobody can tell whether a red belongs to the new work or to what was let past. "Mostly done" is a shut gate.

| Phase | Gate | Checked by | |---|---|---| | 0 · Definition (`/define`) | **Load defined** — every Must/Should carries a verification contract; three planes exist | `/define` §12.5 + `finalisation.md` §1 | | 1 · Harness (`/harness`) | **AI harnessed** — a `/build` session opens, states its position, and acts without asking | `/harness` Exit — dry run of the next session | | 2 · Commissioning | **DUT ready** — the testbench is commissioned, the DUT is connected and verified, and the forward path delivers code to it; a failing test means the code, not the setup | `/commission` Exit — four checks, six records | | 3 · Build | **Ready for shipment** — every requirement met, journey green, reconcile empty | this skill §4 audit + §5 reconcile | | ⚑ Shipment | **Shipped** — release published *and* the journey green on the released bytes | the release-verify job (§6) |

What each gate demands of the four artefact layers

The layers are not all produced in one phase, and a gate only demands what its phase owes:

| Layer | Lives in | Produced in | Demanded by | |---|---|---|---| | **Verification contract** | the FSD, beside the requirement | Phase 0 | **Load defined** — every Must/Should has one | | **Test case (declaration)** | `testing/test-plan.yaml` | journey tests in Phase 1; each requirement's own during Build | **AI harnessed** (journey tests present) · then per requirement in the chain | | **Executable** (`impl:` filled) | `tests/{host,target,bench}/` | Phase 3, before the code | **Ready for shipment** — every declared test executable | | **Result** (status + commit) | back in the plan entry | every run in Phase 3; once more at release | **Ready for shipment** (all successful) · **Shipped** (journey green on the released bytes) |

A declaration without an executable is the backlog; an executable without a result is `not done`; a result without a commit is not evidence. The gate that demands each is the one that will not open without it.

0. Open every session by saying where the project is

Read `testing/test-plan.yaml` and the FSD, derive the position, and open with it — unprompted. The user asking "so what do I do next?" means this skill failed to lead.

• **Debugging agenda has open items** → Phase 2. Lead commissioning: next

unproven **project-side** part, how to prove it (`../commission/SKILL.md` owns the phase and its four checks; the testbench is depended on, never proven by a project).

• **Agenda burned down, requirements unmet** → Phase 3. Derive the **wave**

first, then name the next act from the chain below, per requirement — never an average that hides the requirement that has nothing.

• **All requirements met, reconcile empty, journey green** → announce **Ready

for shipment** and stop; the tag is the user's act, never this skill's.

**Phase 3 runs in three waves, and the wave is derived from the plan** — gates, authoring lock, and the capability-declaration exception in `references/test-design.md` §5:

| Wave | Writes | Open while | Locked behind it | |---|---|---|---| | 1 · Build the running prototype | `standard` tests + features | any standard test red or unwritten | deviations, negatives | | 2 · Cover the normal variants | `deviation` tests | journey + all standard green | negatives | | 3 · Build the error handling | `negative` + adversarial `security` | all standard + deviation green | — |

The position report names the wave and what the gate is waiting on: *"Wave 1 — 12/15 standard green,