Fusion-saved pours have no uuid, so `verify-pours --adopt` / `land pours` fail, and pours can't be replaced in the Fusion lane

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

Closed bug report

Andy Engevold · 7d ago ·closed by Colby Knox

Target wikis: adom/fusion-bridge and adom/adom-aiflow

Versions

AI Flow 0.2.47
Fusion Bridge 1.13.67
Hydrogen on a Windows laptop, WSL Adom-Workspace

What happened

Thanks for the Fusion lane. Getting a board through Fusion end to end has been really nice. I ran into a few things with pours and would like your advice.

The board is a small 4-layer design with parts on both sides.

Pours that the Fusion bridge saves show up in the KiCad snapshot without a uuid. Because of that, verify-pours --adopt can't take ownership of them.
After that, land pours reports an ownership conflict between the planned GND pour and the unowned Fusion pour.
In the Fusion lane, land pours only adds pours (through fusion_apply_pours) and never removes them. Changing a pour outline therefore leaves a duplicate pour. I saw that docs/fusion-lane.md mentions this behavior.

Exact error text

"unnamed zone": the saved zone has no uuid to own

zone_ownership_conflict: planned zone "GND pour" conflicts with unowned live ID fusion-pour-0

Steps to reproduce (generic)

Land pours on a board through the Fusion lane, then save.
Take the KiCad snapshot and run verify-pours --adopt. It fails with the uuid error.
Run land pours again. It fails with zone_ownership_conflict.
Separately, change a pour outline in the plan and run land pours again. A second pour appears next to the old one.

Expected vs actual

Expected: Pours saved from Fusion can be adopted, or have a stable ID, and re-landing a changed pour replaces the old one.
Actual: Adopting fails because the zone has no uuid, landing hits an ownership conflict, and changed pours end up duplicated.

Local workaround

We have two local patches and can share them privately if they're useful:

adopt maps zones with no ID to fusion-pour-<index>. This only happens when an environment flag is set.
A second patch removes owned pours before landing new ones.

What is the recommended way to replace or update pours in the Fusion lane? I'd rather follow the intended approach than keep these patches.

Thank you!

— Andy Engevold

3 Replies

Colby Knox marked this in progress · 7d ago

Colby Knox · 7d ago

Thanks for this, Andy. It's a clear report, and your two patches pointed right at the problem.

What to do today. To change a pour, remove the old one first, then land the new one. That's what your second patch does, and it's the intended approach. The bridge already has the verb: fusion_remove_pours {pours:[{net, layer, points}]}, then fusion_apply_pours. land pours should do this for you, and today it only adds, which is why you see the duplicate.

Be careful with your first patch. fusion-pour-<index> isn't a stable ID. Fusion stores no ID on a pour, and the index shifts whenever a pour is added or removed, so adopting by index can end up owning the wrong pour.

What we're changing.

Bridge: each pour gets a stable id made from its net, layer and outline, so it stays the same across saves and when other pours change. fusion_pour_state will report it, and fusion_remove_pours and fusion_edit_pours will accept it. This is written but not released, because I still need to test it on Fusion.
AI Flow: verify-pours --adopt and land pours need to use that id, and land pours needs to replace a pour it owns. That's being passed to the AI Flow side now.

I'll post here when the bridge part is out. Keep your second patch until then. You don't need to send the patches unless the replace step still misbehaves afterwards.

Colby Knox · 7d ago

An update, Andy: the bridge part is out in fusion-bridge 1.13.72, which is public. Fusion needs one restart to load the new add-in.

Each pour now has a stable id from its net, layer and outline. fusion_pour_state reports it, and fusion_remove_pours and fusion_edit_pours accept it. The id stayed the same when another pour was added, and removing by id took only that pour.

land pours and verify-pours --adopt don't use this yet. That's the AI Flow part and it isn't done, so keep your second patch for now. I'm leaving this open until it is.

Colby Knox · 6d ago

Andy, the AI Flow part is out in adom-aiflow 0.2.52, so you can drop your second patch. Use it with fusion-bridge 1.13.74, which is public.

What changed:

Pours saved from Fusion now have a stable id in the run's board, so verify-pours --adopt can own them, and land pours no longer reports the ownership conflict once they're adopted.
When an outline changes, land pours removes the old pour, draws the new one and reads both back by id. If the new one doesn't land, the old one is put back.
A pour the run doesn't own is never removed. It stays beside a new outline until you adopt it.

Bug found during testing, now fixed: when two pours shared an edge, removing one could delete the other. Fusion bridge 1.13.74 fixes that, and it refuses when it can't pick a pour safely. land pours then stops with nothing new landed.

How it was tested: live on new boards with no schematic. On 1.13.74, a pour landed, grew and shrank, with the right pour removed each time. On 1.13.73, the same plan landed twice added nothing, a hand-drawn pour was left alone, then adopted and replaced. Putting the old pour back after a failed landing is covered by a unit test only.

Your existing run: verify-pours reads the run's board, so it needs a fresh copy from the live board first. route makes one, and so does adopt-board. verify-pours also compares settings exactly, and it names any that differ.

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

Colby Knox removed the in progress marker · 6d ago

Colby Knox closed this · 6d ago