Fusion - the Fusion 360 Bridge

fusion-lane: confirmed, and the cause is on the bridge's side. Thanks, Andy; your "likely cause" is right.

Why every ADD fails.

1. fusion_board_seed embeds the library in Seed.sch, but it strips every deviceset that isn't in fixed (routing_script.py, board_seed). The imported design therefore holds only the fixed parts' devices.
2. schematic_run then relies on USE '<the .lbr on disk>' for every other ADD. On Fusion 2706, USE of a local .lbr is accepted, but ADD then finds nothing (we recorded that on 2026-10-28). ADD only works from a library the design already holds.

Result: "No part available to add" / "Unknown part", and Fusion's PlacePartWorker assetAdded assert.

Why it ran on. schematic_run doesn't check each ADD and doesn't stop at the first failure. The bridge's dialog etiquette also clicks OK on Fusion's "unexpected condition" asserts: that rule was meant for a harmless routing assert, and here it hid a fatal one.

Planned fix:

1. fusion_board_seed embeds the whole library in Seed.sch (every deviceset, its symbols and packages), so every later ADD is from a library the design holds.
2. schematic_run checks each ADD as it goes and stops at the first part that doesn't land, naming it, instead of retrying past your timeout.
3. During schematic_run, a PlacePartWorker or other unexpected-condition assert is reported as the failure, not silently dismissed.
4. The design-held check replaces the USE of the .lbr on disk, which avoids the two-libraries-with-one-name confusion you noted from Oct 29.

This needs a live check on our test laptop with a seed like yours. I'll post the result here when it ships. Until then there's no clean workaround in AI Flow's flow: ADD of a device the seed didn't embed will fail on this Fusion build.

Update: found the real cause, and it's different from my first guess. Tested live on Fusion 2706.1.14, with the same calls AI Flow makes.

Cause. Fusion raises the PlacePartWorker ... assetAdded error when an ADD's part has no 3D package Fusion can add to the design.

• The same ADD lands for parts whose footprints carry a saved cloud 3D package, in a new design or an imported one.
• It fails for parts with no 3D package, whatever the library's name, and whether or not the seed embeds it.

Your parts do have 3D packages, but, as you noted, they point at WIP cloud files in another project ("Adom AI Workspace"), marked locally modified. That's the likely reason Fusion can't add them. The seed's library was not the cause; I tested it and put it back as it was.

In fusion-bridge 1.13.46 (insiders):

• fusion_schematic_run refuses a part with no 3D package before any ADD (no_3d_package, naming the part), so Fusion never raises the error.
• It checks each ADD and stops at the first part that didn't land.
• An assert during the run fails it (fusion_assert, with the text) instead of being clicked away while the run carries on past AI Flow's timeout.

The rest is in AI Flow: https://wiki.adom.inc/adom/adom-aiflow/issues/114. Its library step needs each part's 3D package to be a saved cloud file, not a locally modified WIP file in another project. It should also pass the runId and the full replies through to the run folder.

1.13.46 goes public after a full test run on our laptop; I'll post here. Leaving this open until the AI Flow side lands and your run passes.

fusion-bridge 1.13.46 is public. The bridge side of this issue is fixed:

• fusion_schematic_run refuses a part with no 3D package before any ADD (no_3d_package, naming it).
• It stops at the first ADD that doesn't land.
• A Fusion assert during the run fails it with its text (fusion_assert), instead of being clicked away while the run goes on.

Checked with the full daily battery on our laptop: 236 pass. The remaining failures are the APS sign-in baseline and one unrelated panel test.

Andy: once your Fusion bridge updates to 1.13.46, the same run will stop at the first part Fusion can't add and say why, instead of running past AI Flow's timeout. The fix that lets those parts place is AI Flow saving their 3D packages: https://wiki.adom.inc/adom/adom-aiflow/issues/114. This stays open until that lands and your run passes.

Found the actual cause, and the fix is on insiders: fusion-bridge 1.13.47. It isn't 3D models.

Fusion 2706 raises PlacePartWorker.cpp, Line 23. Condition: assetAdded on every ADD from a library file (.lbr) whose XML elements have no line breaks between them (<packages><package ...> on one line). The same library with line breaks between its elements adds cleanly, including parts with no 3D package at all. I bisected it live on Fusion 2706.1.14 with the AI Flow lane (adom/adom-aiflow#114). One missing line break inside <devicesets> was enough to break every ADD. My 1.13.46 diagnosis (parts without a 3D package) was wrong, and its no_3d_package refusal is removed.

What 1.13.47 changes:

• fusion_schematic_run, fusion_sch_place_part and fusion_sch_swap_part rewrite a compact library in place before loading it: line breaks between elements, nothing else. The bridge compares the XML before and after and writes nothing if anything else would change. The reply says libraryReformatted: true.
• It still checks each ADD and stops at the first part that doesn't land, and a Fusion error during the run still fails it.

Tested live on 1.13.47 (signed): seeded a new design with one fixed part from a compact library, imported it, then ADDed two parts that have no 3D models. Both landed, with no Fusion error and no dialog. fusion_sch_place_part from another compact copy placed its part too. The full daily battery is running now.

Andy: once your Fusion bridge is on 1.13.47, the same AI Flow run should get through the schematic step. It's on insiders now; public follows once Colby signs off. This stays open until your run passes.

1.13.47's full daily battery on the test laptop: 236 pass. The only failures are the 5 APS sign-in checks (the laptop isn't signed in to APS) and one panel test that passed when rerun alone, the same baseline as 1.13.46. Next: AI Flow's end-to-end run on 1.13.47, then public.

fusion-bridge 1.13.47 is public, and AI Flow's end-to-end run on it passed (adom/adom-aiflow#114, now closed). On our test laptop, fusion library and then fusion schematic ran on a new design that includes a test pad with no 3D model. All four parts went in, with no Fusion error.

Andy, please update both, then rerun:

1. AI Flow to 0.2.29 (public): it now writes its project library one element per line, so Fusion takes it as written.
2. The Fusion bridge to 1.13.47 (public): it rewrites any library that still has no line breaks before adding parts from it (whitespace only), and stops at the first part that doesn't land, with Fusion's error text, instead of running past the timeout.

This stays open until your run passes. If a part still fails, please paste the fusion_schematic_run reply; its fusionAsserts and libraryReformatted fields say what happened.

Closing this too: your retest on 1.13.59, reported on #136, shows no more PlacePartWorker asserts or ADD failures.