A missing UUID in the placeholder exporter caused finalize to skip every footprint. The PCB had 0 pads. KiCad's DRC reported 0 unconnected because there was nothing to be unconnected. The real baseline, with embedded pads, is 0 shorts / 10 unconnected.
A background agent traced why the router was emitting layer transitions without vias. It surfaced three loose ends to clean up: (1) route_one_net_3d_test.rs had pre-existing compile errors from offset_twin signature drift; (2) collect_net_pins fell back to component centers with layer=None, which the router treats as PTH (any layer); (3) extract_pads.py produced an empty pad map for some runs. We started with #3 because it was the most concrete.
On a recent /tmp/kvm-bench run, board.pad_positions.json had 0 routable nets, 0 obstacle entries, and 2 metadata keys. Re-ran extract_pads.py manually against the same PCB: same result. Counted (pad ...) blocks in the .kicad_pcb itself — zero. The PCB had 57 footprints but no pads at all. extract_pads.py was working correctly; there was nothing to extract.
pcb_finalize.py runs embed_footprints_in_pcb to swap each placeholder footprint for a full library definition (with pads). Inside that function: `if not fp._uuid: continue`. The placeholder PCB had 14 (uuid …) entries — but every one of them belonged to a cartouche on F.SilkS, not a footprint. Zero footprints had UUIDs, so the embed loop skipped every single footprint silently. Finalize ran to "completion" reporting "Embedded 0 footprints" but no one was reading that line.
crates/designgraph/src/export/kicad_pcb.rs:write_footprints emits the placeholder block (footprint name, position, layer, Reference, Value) but never a (uuid …) line. The Python finalize step was anchored to a UUID that the Rust exporter never wrote. This had been the case the entire time the "0/0 baseline" was being celebrated.
Added one line to write_footprints to emit (uuid "fp-<ref>") per footprint. Deterministic — same TOML + same code + same seed = same UUIDs, so benchmark reproducibility is preserved. Verified end-to-end: pipeline:zero 42 1 200 went from 0 pads in the finalized PCB to 302 pads embedded; pad_positions.json grew from 0/0 routable nets to 43 routable + 71 obstacle entries.
Re-ran pipeline:zero 42 1 2000 on the post-fix code. Result: 0 shorts / 10 unconnected / 203 vias / 201 routes in 752s. The previous "0/0 / 17 vias / 43 traces / 665s" was the score of a router connecting component centers on a PCB that contained no pads. KiCad's DRC reported 0 unconnected because there were no pads to be unconnected. The post-route via validator inserted vias to bridge layer transitions in routes that were not connecting anything physical.
The yardstick for "is the design routed?" needs to look at the PCB, not just the DRC report. We were checking DRC.json for shorts/unconnected and counting traces and vias. None of those numbers tell you whether the pads exist. Adding a finalize-pad-count assertion (or just panicking when embed_footprints_in_pcb returns 0) would have caught this on the first phantom run instead of two weeks in. Going to bake that check in next.
mise run pipeline:zero 42 1 2000
# Real baseline (commit d722830):
# 201 routes, 203 vias, 0S/10U, 752s
# pad_positions.json: 43 routable nets, 71 obstacles, 73 metadata keys
# Embedded pads in /tmp/kvm-bench/<run-id>/board.kicad_pcb: 302