AI Flow

adom-aiflow 0.1.90, Linux x86_64. Production context: KiCad 10.0.6, KiCadBridge 1.0.53, Adom Bridge 2.1.168 on Windows. The synthetic reproduction needs no desktop bridge.

testplan check treats a B.Fab component body as an obstruction over an exposed F.Cu probe pad. This blocks the board workflow despite physical front-side accessibility. First observed 2026-10-13; earlier behavior unknown. Existing bug reports were checked for duplicates.

The attached Python script creates two isolated minimal runs and invokes the installed CLI. Each has a 1 mm front test pad at (10,10) and a rectangular body at the same XY. The only meaningful difference is body side: B.Cu/B.Fab versus F.Cu/F.Fab.

Expected: back-side body permits probing (exit 0), front-side body blocks probing (exit 2). Actual: both exit 2, with the same message:

ERROR: test plan (board): 1 measurements, 0 probe-able, 1 gap(s)
  probe      TEST         waveform  GAP: every landing on TEST is under a part body (e.g. TP1.1 under U1)

Run python3 reproduce.py in a writable directory containing adom-aiflow on PATH. The script only creates synthetic fixture directories beside itself; it does not alter a production run or desktop board. Full observed output is attached in results.json. No screenshot is necessary for this headless CLI reproduction.

Likely cause: crates/adom-aiflow/src/testplan.rs gathers both F.Fab and B.Fab rectangles in bodies, then checks front probe candidates against every rectangle in check_board, without consulting Footprint.layer. Suggested fix: filter obstructions to the probe side at the checking call site; preserve both-side geometry for other uses of bodies. Add the attached positive/negative side pair as a regression. This is a proposed fix, not compiled or validated here.

Production test points remain correctly on the front. We have retained the failed automated check instead of relocating valid hardware or marking the gate passed.

reproduce.py.txt

results.json