Fusion - the Fusion 360 Bridge

@@ -97,17 +97,39 @@ FINISH saves a 3D package to the cloud (the Save dialog Name/Location are confir  ![The real nRF54L15 3D chip placed + oriented on the footprint, entirely via the API](lib-03-chip-on-footprint.png) -### The remaining wall (being honest)--`Electron.Create3DPackage <file>` builds a **standalone** 3D package. It does **not** map back onto the-open library's deviceset, and it does **not** write `package3d` into the `.lbr` (verified: the file is-byte-unchanged, the package still shows **Placeholder**). The deviceset-to-3D mapping is done in the-**Content Manager** (select the package -> Generate 3D Package -> Finish), which is Qt-UI and exposed by-neither a text command (the `addvariant`/`queryvariant` family is for schematic assembly variants, not-3D) nor the public API found so far. So `fusion_attach_3d_package` can automate everything up through-*placing + saving the model*; the final **deviceset re-map** needs Content Manager UI automation or a-deeper API, and is the open item. Launching the generator **from the selected package inside the open-library** (not from the `.lbr` file) is the most likely path to make the map stick.+### SOLVED - the 3D binds, end to end++Launched from the **open library**, `Electron.Create3DPackage` -> import the model -> orient ->+`Package3DStop` (FINISH) -> Save **does bind the 3D onto the deviceset**. Proven on ADS8588SIPM+(LQFP-64): the Content Manager tree shows the 3D nested under the package under the deviceset, the+Packages panel's `Package` column flips from `Placeholder` to the part name, and the 3D preview becomes+the real chip. First time the full Fusion electronics 3D attach is automated via the bridge.++![3D bound: Content Manager shows the real chip under the package, Package column = part name](lib-09-3d-bound-moneyshot.png)++GOTCHA: the right-panel preview LAGS after FINISH (still shows the gray placeholder for a moment) - the+Content Manager tree / `Package` column is the source of truth; re-grab the window after a beat.++### How Fusion stores it (the ground-truth `.lbr` markup)++Export the bound library (`fusion_export_source` to a `.flbr` ZIP; the EAGLE XML is in+`electron.BlobParts/ExtFile<uuid>`) and you see exactly how the 3D is referenced for a CUSTOM model:++```xml+<packages3d>+  <package3d name="<PKG>" urn="" wip_urn="urn:adsk.wipprod:fs.file:vf.<id>?version=1"+             locally_modified="yes" type="model">+    <packageinstances><packageinstance name="<PKG>"/></packageinstances>+  </package3d>+</packages3d>+<!-- inside the <device>: -->+<package3dinstances><package3dinstance package3d_urn="urn:adsk.wipprod:fs.file:vf.<id>?version=1"/></package3dinstances>+```++Key: `urn=""` is empty (that slot is for managed `urn:adsk.eagle:package` parts only); the real link is+**`wip_urn=`** with the **versioned file URN** `urn:adsk.wipprod:fs.file:vf.<id>?version=1` (NOT the+`dm.lineage` form), plus `locally_modified="yes"`. With this exact shape the binding can be written+directly given the model's versioned file URN. Full detail: [FUSION_3D_FINDINGS.md](FUSION_3D_FINDINGS.md) §11-12.  ## Pitfalls