Fusion lane: Kelvin keepouts in the pour plan make verify-pours --adopt impossible

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

Closed PR #48 released in 0.2.27 on 31 Oct 2026 bug report

Glenn Jones · 15d ago ·closed by Colby Knox

adom-aiflow 0.2.26, Fusion lane, fusion-bridge 1.13.44

With "kelvin": {"R5.1": "R1.1", "R6.1": "R1.2"} in the spec, pour adds two "Kelvin sense pad keepout" zones (F.Cu+B.Cu) to plan-pours.json. docs/fusion-lane.md says keepout zones are not landed in Fusion ("pours are drawn clear of them"), so the board can never contain them.

verify-pours --plan <the plan pour wrote> --adopt requires a one-to-one match of every plan zone, so on a Fusion board with Kelvin pairs it always fails on these two keepouts:

7: Kelvin sense pad keepout SW1 (R5.1): expected one exact geometry/settings match, found 0 ...
8: Kelvin sense pad keepout SHUNT_L (R6.1): expected one exact geometry/settings match, found 0 ...

That leaves no honest way to adopt hand-drawn Fusion pours in the pours step without weakening the spec's Kelvin intent.

Expected (either): on the Fusion lane, keepouts are left out of the zone matching in verify-pours (and checked as "no other-net copper inside" instead), or pour writes them to a separate list that verify does not require on the board.

Related: verify-pours read an older board snapshot that predates zones added during the thermal-vias step (the two new B.Cu pours showed as missing). It may be worth having verify-pours refresh fusion_board_source on a Fusion run, as route and analyze do.

Run folder available on request.

2 Replies

Colby Knox linked pull request #48, which closes this when it merges · 14d ago

Colby Knox closed this in pull request #48 · 14d ago

Colby Knox · 14d ago

Fixed in adom-aiflow 0.2.27 (PR #48, published today). I took your first option.

On a tool that doesn't land keepout zones (Fusion, and Altium, which cuts them out of its polygons), verify-pours no longer requires a plan keepout to match a zone on the board. It checks the keepout's area is clear instead. Any saved pour fill of any net inside it on its layers fails, naming the zone and the layer. So does a pour that reaches into it with no saved fill, since nothing then shows it clear.
Only a pour keepout (copperPour alone, which is what the Kelvin keepouts are) can be judged this way. A track or via keepout is refused in words rather than passed.
The proof lists these under keepoutsCheckedClear. --adopt owns only the matched pours, and KiCad runs are unchanged.

So verify-pours --plan <pour's plan> --adopt --why … can pass on a Fusion board with Kelvin pairs, provided your hand-drawn pours really do stay out of the sense-pad areas.

Still open (your side note): on a Fusion run, verify-pours reads the run's current board, not a fresh fusion_board_source, so zones added after that board was recorded show as missing. Pulling fresh changes which board the proof is bound to, which finish checks too, so it needs its own change; I'm treating it as a follow-up. Your run folder would help me test that change.

Upgrade: tell your AI "give me the latest adom-aiflow" (or adom-wiki pkg install adom/adom-aiflow); adom-aiflow --version says 0.2.27.

Glenn Jones · 14d ago

Confirmed on 0.2.30, thanks Colby. The Kelvin keepout check does what it should on Fusion, and it caught something real.

On the 772 power module (LM251772), verify-pours listed both keepouts under keepoutsCheckedClear. The SHUNT_L one (R6.1) first failed because the SHUNT_L pour's copper reached about 0.08 mm into it. We moved R6 up 0.3 mm in Fusion, and it now passes alongside the SW1 one (R5.1). We're past the pours step.

On the side note about verify-pours reading the run's saved board instead of a fresh fusion_board_source: running route before verify-pours refreshes the board, and that worked fine for us in the meantime. Thanks again for the quick fixes.