/harness

name: harness
description: >
  Phase 1 of AI Closed-Loop Programming — harness the AI for a project: the
  one-time setup that straps the AI to this particular load so the loop can
  run. Sequences Definition (via /define) when no FSD exists, then installs
  the three planes, the testing standard, the test plan seeded with the
  journey tests, declared testbench capabilities, firmware integration, CI
  with release verification, and the devcontainer with its per-repo runner.
  Use this skill for a new project, "set up this project", "harness this
  project", "integrate with the testbench", or when a project has an FSD but
  none of the machinery to build against it. Exit gate: AI harnessed.

Harness — Phase 1 sequencer

Runs **once per project**. This skill owns only the **order** and the checklist of what "harnessed" means; every step delegates to the skill that does the work. A harness is the coupling between horse and load: after this phase, a `/build` session can open, state its position, and act.

The sequence

| # | Step | Delegate to | |---|------|-------------| | 1 | **Definition first.** No FSD → run Phase 0 now: `/define` (grill → create). FSD exists → verify every Must/Should carries a verification contract; missing ones are the first act | `/define` | | 2 | Three planes installed or bound: FSD home, `docs/Method/`, `docs/UserDocumentation/` + `docs/00-Overview.md` at the docs root | `/define` planes mode | | 3 | Testing standard stamped (setup/teardown/evidence rules + shared procedures, one file) | `/define` templates | | 4 | `testing/test-plan.yaml` created; **capabilities declared** — bench capabilities copied from what the bench reports (`available: yes` as declared — a project never proves them), plus this project's own peers and equipment. Blocked is computed from these, never typed | this skill | | 5 | Firmware integration — **only the modules the FSD requires.** UDP logging always (the loop's eyes inside the DUT); WiFi provisioning, OTA, BLE hooks only when the FSD carries the corresponding requirements. A module the spec never asked for is silent pack adoption | `testbench-integration` | | 6 | CI: build on push, release on tag **plus the release-verify job** (flash the released artifact to the testbench, run the journey; red journey = no release) | `setup-action` | | 7 | Devcontainer and toolchain, with the **GitHub Actions runner inside it** — see below | `esp-idf-handling` / `esp-pio-handling` (project + toolchain setup) | | 8 | **Generate this project's gate checks** — one file per gate under `testing/gates/`, filled with this project's paths, ids, DUT, capabilities, markers and CI. A generic checklist cannot catch a project-specific omission | this skill · `../build/references/gate-checks.md` | | 9 | **Close with the two questions only the user can answer** — see below | this skill |

Step 5 — a skeleton, and the DUT is not touched

**The DUT is completely out of Phase 1.** Not flashed, not reset, not read. No `chip/info`, no serial monitor, no esptool, no slot claimed. The board belongs to `/commission`, which discovers it, verifies it is the unit the FSD names, and proves the forward path to it. A harness session that has touched the DUT has done Phase 2's work without Phase 2's gate watching.

**The firmware is a skeleton that proves the pipeline, nothing more.** It compiles, it produces an artifact, and it emits one marker. It implements no requirement and verifies no requirement — those are `/build`'s waves, run against the journey. The gate asks only that CI went green once and that no module exists which the FSD never asked for; both are satisfied by a composition root and a printed marker.

The pull that breaks this is always the same shape: **the skeleton needs a hardware fact to compile.** Flash size, partition offsets, a pin, a clock. The answer is never to go and read it off the chip — that is Phase 2 arriving early because Phase 0 left a hole. **Send it back to `/define`**: a constraint the build depends on belongs in the FSD, and a spec that omits one will pull hardware work forward into whichever phase first hits the wall.

Symptoms that Phase 1 has drifted:

• a capability whose `observed:` evidence could only have come from the board
• a host test that asserts product behaviour rather than that the tier runs
• a build fixed by measuring the hardware instead of by amending the spec

Step 7 — the runner lives in the project's devcontainer

One project, one container — no separate infrastructure. The devcontainer already holds the pytest bench tier, TestbenchDriver, discovery, and slot config, which is everything the verify job needs (it downloads an artifact and speaks HTTP; it never builds). **Installation is automated; registration is a human grant** — a registered runner accepts and executes workflow code that then physically drives the bench, a standing outward-facing authority like the release tag itself. This skill installs the runner and the registration script, states what registering means, and waits for the user's yes. Register **per-repo**, labels `[self-hosted, testbench]`, ephemeral registration in a restart loop, verify job triggered by tag push only, approval required for outside contributors. Declare it as a capability:

release-verification:
  what:      tag-triggered journey run against the released artifact
  available: yes   # the container runs 24/7; the bench may not — an absent
                   # bench at verify time is an unmet precondition (not done)

Step 9 — the two unharvestable questions

Asked at the end, when the user knows the system's shape — and never harvestable from any document:

1. **What has to be debugged before testing starts?** Which **project-side** parts — this board, its wiring, its peers and simulators — have never been observed doing their job here. Becomes the **debugging agenda** that `/commission` burns down. **The testbench is not on this list**: a proje