Fusion - the Fusion 360 Bridge

@@ -1,6 +1,6 @@ --- name: fusion-multipart-libraries-description: How to build ONE Fusion 360 .lbr library that holds MANY parts where EACH package has its real 3D model attached - the cracked recipe for per-package 3D in a multi-deviceset library. Covers the reorder-file trick (Electron.Create3DPackage always targets the FIRST package, so rewrite the .lbr to put the target package first), the build-up-one-by-one alternative, merging per-part .lbr files, the pre-merge connect/pad validation that stops one bad part poisoning the whole library, and the per-part attach loop with orient + save. Read this when attaching 3D to more than one part in a single library, or building a parts-library sampler. Trigger words - multi part library, multiple 3d packages, attach 3d to many parts, combined lbr, merge lbr, basic parts library, parts sampler, Electron.Create3DPackage first package, reorder lbr, build up library, per package 3d, package3d loop, deviceset library 3d, attach all 3d.+description: How to build ONE Fusion 360 .lbr library that holds MANY parts where EACH package has its real 3D model attached. The single-part mechanism is CONFIRMED (Electron.Create3DPackage binds the OPEN library's FIRST package; the binding commits on save); binding ALL parts in one library is UNDER DERIVATION - read this for the proven primitive, the dead end to avoid (passing reordered files to one open library binds only 1/N), the two candidate paths (build-up+reorder, bind-then-merge), merging per-part .lbr files, and the pre-merge connect/pad validation that stops one bad part poisoning the whole library. Read this when attaching 3D to more than one part in a single library, or building a parts-library sampler. Trigger words - multi part library, multiple 3d packages, attach 3d to many parts, combined lbr, merge lbr, basic parts library, parts sampler, Electron.Create3DPackage first package, reorder lbr, build up library, per package 3d, package3d loop, deviceset library 3d, attach all 3d. ---  # Building a many-part Fusion library with real 3D on every package@@ -19,16 +19,41 @@ selects a package in the editor but does NOT change which one Create3DPackage ta the 2D `.lbr` between parts **resets the document**, so naive looping attaches nothing that sticks. That is why "attach 3D to part 5 of 10" had no obvious path. -## ✅ The reorder-file trick (the crack, verified 2026-06-28)+## ⚠️ Per-package binding: CONFIRMED mechanism, multi-bind UNDER DERIVATION (2026-06-28) -Since Create3DPackage targets the FIRST package, **make your target the first package.** Rewrite the-combined `.lbr` so the target's `<package>`, `<symbol>`, and `<deviceset>` sort first, then call-Create3DPackage on that reordered file. It opens the target's generator **while your ONE combined-library stays open**, and FINISH binds the 3D into that open library. Loop, reordering for each part.+Be honest about the state of this: the single-part attach works, but binding 3D to MANY packages in+ONE library is **not yet reliably solved.** Here is exactly what is and isn't known, so the next+session does not repeat the dead end. -Verified: R_100R_0402 bound as a real per-package 3D inside a 10-deviceset library (the non-attached-R_0R correctly stayed `Placeholder`), proving it is one combined library with a genuine per-package-binding, not ten standalones.+**Confirmed:** `Electron.Create3DPackage` binds the 3D to the **FIRST package of the currently OPEN+library**, and the binding **commits when you SAVE the library.** Proven: opening the combined `.lbr`+(R_0R first), attaching, and saving bound R_0R.++**What does NOT work (do not repeat):** keeping ONE combined library open and calling+`Create3DPackage ro_<part>.lbr` with a different reordered file per part. Passing a reordered FILE+does **not** redirect the binding - it still targets the OPEN library's first package. A 10-part run+this way bound only **1/10** (R_0R, the open lib's first package); the other 9 imported correct+geometry but their bindings did not land on their own package. An export-count confirmed it:+`devicesets=10, package3d=1, bound_names=R_0R_0402`. (An earlier "verified R_100R" claim did NOT+reproduce - treat it as retracted.)++**The unsolved piece:** to bind part N, part N must be FIRST in the OPEN library, which means+re-opening a part-N-first file as the library - but re-opening resets in-memory bindings, so+accumulating all 10 in one library is the open problem. Two candidate paths, both UNVERIFIED:++- **build-up + reorder:** each step, export the CURRENT bound library, reorder THAT (preserving its+  `<packages3d>` bindings) to put the next part first, reopen, attach, save. Open question: do prior+  `wip_urn` bindings survive the reopen and still let you add one more?+- **bind-then-merge:** attach each part in its own one-part library (part first), then merge the+  per-part `<package3d>` + `<package3dinstance>` XML into the combined `.lbr` directly (see+  [LIBRARY_FINDINGS](../fusion-libraries/LIBRARY_FINDINGS.md) section 11-12). Open question: does+  Fusion resolve N hand-merged `wip_urn` refs on open?++Until one path is verified end to end, do NOT claim multi-part 3D works. Re-derive empirically, save+the library after every attach (the binding only commits on save), and note Fusion may reset the+session between calls.++### The reorder helper (still the right primitive for either path)  ### Reorder helper (put one package first) @@ -49,20 +74,22 @@ for tag in ('packages','symbols','devicesets'): open('ro_R_100R_0402.lbr','w').write(xml)   # R_100R now first; Create3DPackage opens IT ``` -### The per-part attach loop+### The single-part attach (CONFIRMED working - the building block) -Open the combined library ONCE. Then for each part (do NOT re-open the library between parts):+This is the proven primitive (one part, first in the open library):  ```-Electron.Create3DPackage  C:/.../ro_<part>.lbr      # opens the generator on <part> (it's first)-import <part>.step + orient                          # importToTarget, then rotate 90 about X (below)-Package3DStop  (FINISH)                               # binds the 3D into the open combined library-handle the Save dialog (3D package)                  # read it (fusion-driving), click Save-WAIT for the Hub upload to drain                     # fusion-cloud-save Rule 3 - do NOT race ahead+open the library (target package FIRST in it)        # fusion_open_lbr+Electron.Create3DPackage  C:/.../<lib>.lbr           # opens the generator on the FIRST package+import <part>.step + orient                           # importToTarget, then rotate 90 about X (below)+Package3DStop  (FINISH)                               # binds the 3D onto that first package+handle the Save dialog (3D package)                   # read it (fusion-driving), click Save+WAIT for the Hub upload to drain, then SAVE the lib   # the binding COMMITS on save (fusion-cloud-save) ``` -After all parts, `saveAs` the library with the poll-until-uploaded recipe in-[fusion-cloud-save](../fusion-cloud-save/SKILL.md).+⛔ Do NOT then loop `Create3DPackage ro_<otherpart>.lbr` against the same open library expecting each+to bind - it does not (see the box above; you get 1/10). Extending this to all 10 is the UNDER-+DERIVATION problem above; pick one of the two candidate paths and verify it before relying on it.  ### Orient the imported STEP