/commission

name: commission
description: >
  Phase 2 of AI Closed-Loop Programming — Commissioning: prove the project's
  OWN never-seen-working parts (its board, its wiring, its peers/simulators),
  so that a failing test means the code and not the setup. The testbench
  itself is never commissioned by a project — its quality is depended on, and
  fixed in its own repo only when DUT testing disproves it. Use this skill
  when the user mentions commissioning, bring-up, a new board or peer, wiring
  or polarity doubts, or wants to burn down the debugging agenda. Exit
  gate: DUT ready.

Commission — Phase 2 door

A door into the Method skill: **the driver, the chain, and the dispatch map live in `../build/SKILL.md`** — read that first. This door exists so the phase can be entered by its own name; the phase itself is always derived from state. If the debugging agenda is already burned down, say so and continue as `/build` — typing the "wrong" door costs nothing.

The law: no project tests the testbench

**A project depends on the testbench's quality; it never proves it.** The bench is infrastructure, like the compiler — nobody tests gcc before compiling. Its quality is the testbench repo's own responsibility: its FSD, its suite, its acceptance run. A project consumes the bench's declared capabilities at face value, `available: yes` as declared.

**If DUT testing disproves the bench, fix the bench — but only then.** When a red is exonerated of the product by evidence, the bench fault becomes a testbench change request, is fixed at its source, ideally lands as a test in the *testbench's own* suite, and every future project inherits the fix. Attempting to verify the bench upfront — when nothing yet exists that could expose its errors — buys ceremony, not trust. Real work is the only instrument that finds real bench faults.

What commissioning is, under the law

The debugging agenda (`../build/references/test-design.md` §5, first question) lists every **project-side** part that has never been observed doing its job *here* — whatever its reputation elsewhere:

• the DUT board itself — this unit, this slot, first flash, first boot
• project peers and simulators (an M-Bus simulator feeding telegrams)
• project-specific wiring and its polarity
• the project firmware's first contact with each path it uses

Until each is seen working, a failing test measures the environment. The testbench's instruments are **not** on this list.

• Work the agenda top-down; each item names *what proves it*. Drive known

patterns (`0x55` survives inversion detection), make the simulator emit one whole telegram.

• **Agenda items are debugging work, not test cases** — they never enter the

plan. The separator: does it discharge a requirement, or interrogate the setup? Setup measurements go on the **capability**, with their consequence ("two bursts in six arrive clean → assert across several cycles").

• The `unproven` capability state applies to **project-side equipment only** —

bench-declared capabilities are trusted by the law above.

• The bring-up work that *is* a test case (it discharges a requirement about

the device) is `standard` in kind, ordered ahead of the journey.

• The DUT and testbench are not always powered. An unreachable bench is an

unmet precondition — `not done` with the reason, never `failed`.

• **The operator's hands are for physical acts — plug, wire, power, swap.

Observations belong to instruments.** Never design a step where a human reads a measurement by eye. If no instrument can make the observation, that is a testbench change request.

The worked shape — a typical ESP32 project on the testbench

1. **Discover the testbench**; record hostname, last-seen IP and portal version as dated observations. Tests still select by identity — the record is memory, never a hardcoded address. 2. **Find the DUT and verify it is what the project expects** — slot, chip type and revision, flash size, MAC against the FSD's unit. Mismatch = stop: wrong board in the slot. 3. **Project peers**, if any (a meter simulator): present, answers one basic command; record its slot. 4. **Prove the forward path with a trivial known-good program** — CI compiles it, the artifact is flashed to the DUT's slot, and its output is observed. **Print alternating `ON` / `OFF` on serial rather than blinking an LED**: no GPIO need be wired, no camera or eye is required, and the bench observes it directly with a serial pattern match. One pass proves the whole pipeline — toolchain, artifact flow, flash, boot, observation — with code that cannot itself be the problem. When the project's first real build fails later, the pipeline is above suspicion.

Nothing else. Items 1–3 are seconds; item 4 is one CI cycle. Everything beyond this list is bench-side and covered by the law.

Running the four checks

Discover the bench, then hold its URL in `$WB` — never write an address into a committed file.

# 1 · testbench: answers, and in the mode the project needs
curl -s $WB/api/info                     # hostname, slots configured/running
curl -s $WB/api/wifi/mode                # wifi-testing, if the project uses WiFi

# 2 · DUT: the right board, in a free slot
curl -s $WB/api/devices                  # select by detected_chip, not by label
curl -s -X POST $WB/api/chip/info -H 'Content-Type: application/json' \
     -d '{"slot":"<SLOT>"}'              # chip, revision, flash size, MAC
# Compare with the unit the FSD records. A mismatch stops the phase.
# Check `debugging` as well as `state`: a live OpenOCD session holds the port
# while the slot still reads idle.  Every native-USB ESP32 enumerates as
# 303a:1001, so `detected_chip` is only trustworthy if the bench selects the
# board by USB topology; a bench that does not will confidently report one
# slot's chip for another.  Verify the MAC, which is per-board.

# 3 · project peers, if any: present, and answering one basic com