project-page KeyError on a stale parts record; pour plan vias overlap existing in-pad vias and land unchecked; land pours refusal without detail

Overview Files Skills Discover Packages Releases Dependencies Issues10 Breadcrumbs Pull Requests Activity

Closed PR #85 released in 0.2.66 on 11 Nov 2026 bug report

John Lauer · 25d ago ·closed by John Lauer

Seen with adom-aiflow 0.2.6 on a 2-layer KiCad 10 molecule board (TMC2226 driver). The board was built and routed offline, then adopted (adopt-board), with its zones taken over through verify-pours --adopt.

1. project-page crashes on a stale `parts` record

project-page --page <owner/slug> --create --private printed ERROR: project page: Traceback ... merge_project_parts ... KeyError: 'RC0402FR-0733KL'.

The run's parts outcome still listed a project-library part that the current BOM no longer uses. Its symbol was gone from the project library's .kicad_sym, but its footprint and STEP were still there. Rerunning parts --bom <current bom> --project-lib <dir> fixed it.

Expected: project-page compares the parts record with the current BOM and names the stale entry, instead of a bare KeyError ("part X is in the parts record but not in the BOM / its symbol is missing from : run parts again").

2. The pour plan adds vias on top of a pad's existing in-pad vias, and `land vias` lands them unchecked

spec.thermalVias: [{"pad": "U1.29", "net": "GND", "count": 12}] on a board whose exposed pad already carries 10 in-pad vias (0.5/0.25 mm, 2 x 5, datasheet pattern). pour planned 3 more 0.8/0.4 mm vias at (111.8, 82), (113.0, 82) and (114.2, 82). Their centres were 0.6 mm from existing vias, so each overlapped one.

Changing count to 10 still planned the same 3. Only removing the thermalVias entry gave "0 vias". land vias then landed the 3 overlapping vias live without a DRC preflight. They had to be removed with kicad_remove_route, after which DRC was 0 errors again. Meanwhile thermal-vias plan (spec.hot) correctly reported the part at its target with the existing 10.

Expected:

the pour plan counts the pad's existing vias (any size) against count, as thermal-vias plan does;
planned vias are checked against existing copper and holes before land vias, and refused with the clash named.

3. `land pours` refusal has no detail

After verify-pours --adopt matched all 3 zones exactly, land pours answered ERROR: pour for native-zone-plan refused by the preflight: "zone_plan_refused" {}. The details object was empty, and the hint lists generic causes (starved_thermal, zones_intersect, clearance). The ledger row has "itemIds":null and no reason.

Expected: the preflight's own reason, and the zone and place it refers to. Also say whether re-landing zones that were just adopted is expected to work. The step chain accepted the adopted pours and went on.

1 Reply

John Lauer · 25d ago

Fixed in adom-aiflow 0.2.15, all three.

1. Stale parts record. project-page compares the run's parts record with the recorded BOM and the project library before it builds anything. It refuses with a message naming each stale entry and the exact parts --bom ... --project-lib ... command to rerun. project-page.py also names a missing symbol instead of raising KeyError.

2. Vias stacked on in-pad vias. Your diagnosis held.

pour now counts a pad's existing vias of the same net toward count, at any size, whether board vias or the footprint's own through-hole pads. When a footprint repeats a pad name (an exposed pad plus its via pads all called "29"), it uses the largest pad. With your 10 in-pad vias, count: 10 plans nothing, and pour says how many were already there.
A second cause: same-net vias were only kept apart by the hole-to-hole minimum (0.2 mm). A 0.8/0.4 via 0.6 mm from a 0.5/0.25 via passed that even though the copper overlapped. Every planned via (thermal and stitch) now also keeps clearance copper to copper from every via and hole, whatever its net.
land vias already had a preflight before anything landed, but it only checked other-net touches. It now also checks every planned via against the live vias (with their drill), through-hole pads, drilled holes and the other plans, using holeToHole and clearance. A clash is refused with both items named (via_hole_clash) before anything lands.

3. land pours refusal detail. The {} was not the bridge's details: aiflow printed only a count of violation types (empty) and dropped the bridge's message.

The refusal now prints the error code, the message, the violation counts, the bridge's whole reply (clipped) and the zones sent (name, net, layers). The ledger row keeps the message and reply.
On your second question: re-landing zones you just adopted is not needed. When the latest verify-pours --adopt used the same plan (same sha256), owns every matched zone, and the saved zones still match exactly, land pours now answers OK with "adopted zones already match the plan; nothing to land". It makes no bridge call.

Upgrade: adom-wiki pkg install adom/adom-aiflow, then adom-aiflow --version says 0.2.15.

John Lauer closed this · 25d ago

Colby Knox mentioned this in pull request #85 · 3d ago

AI Flow