Fusion - the Fusion 360 Bridge

@@ -0,0 +1,84 @@+# Fusion 3D-package findings (live log, 2026-06-28)++Hard-won findings from cracking "attach the real 3D chip to a Fusion library package." Captured as we+go so the final MAKING_LIBRARIES.md + fusion-libraries skill are complete and correct. Newest insight+at the bottom of each section.++## 1. Use chip-fetcher's curated LIBRARY, not a raw /tmp download++`chip-fetcher/library/<MPN>/` is curated and carries **variant-specific** files. For Fusion, the right+inputs are the **`.fusion`** variant (generated by Adom's `adom-sfconvert`), paired with the curated+named 3D:++| File | Use |+|---|---|+| `<MPN>.fusion.kicad_sym` | symbol, Fusion-tuned -> feed to adom-lbr |+| `<MPN>.fusion.kicad_mod` | footprint, Fusion-tuned -> feed to adom-lbr |+| `<MPN>-named.step` | the curated 3D (part number etched on top; oriented). Pair this with the footprint |+| `<MPN>.kicad_mod` / `.manufacturer.*` / `.altium.*` | raw / other-EDA variants, NOT for Fusion |++MISTAKE made + fixed: I first built the `.lbr` from a raw `/tmp/adom-chip-fetcher-*/EAGLE/*.lbr` and+the thin 245KB `manufacturer.step`. That gave a footprint/3D size mismatch. Switching to+`.fusion.kicad_mod` + `-named.step` is the fix. (Convention confirmed in `chip-fetcher/src/thumbnails.rs`:+it builds the lbr with `--name <mpn>.fusion` from the `.fusion` files.)++## 2. adom-lbr is the right tool; pass it the .fusion files++`adom-lbr generate --sym <MPN>.fusion.kicad_sym --fp <MPN>.fusion.kicad_mod -o <MPN>.lbr --name <MPN>`+then `adom-lbr validate <MPN>.lbr`. adom-lbr has no 3D/URN flag (it is symbol+footprint only); the 3D+is attached separately in Fusion (sections 4-6). The VENDOR EAGLE `.lbr` must NOT be fed to+`Create3DPackage` - it fails Fusion's XML parser ("File doesn't contain valid XML data"); an+adom-lbr-generated `.lbr` parses fine.++## 3. Getting the .lbr / .step onto Windows++The pipeline runs in the cloud container; Fusion runs on Windows; there is NO container->Windows push+verb. Serve the files (`python3 -m http.server 8931`) and pull them with `shell_execute` ++`Invoke-WebRequest -OutFile C:\Users\<user>\adom-lib\...`. Build the shell JSON with `json.dumps`+(Windows paths need `\\`).++## 4. Opening the footprint in the 3D viewer (Package3DEnvironment)++- `fusion_open_lbr` the `.lbr` so the **library document is ACTIVE** (required).+- `fusion_execute_text_command {"command":"Electron.Create3DPackage C:/.../<MPN>.lbr"}` opens the+  **`Package3DEnvironment`** workspace showing the footprint (green courtyard + pads + `>NAME`/`>VALUE`).+  ERROR if the library is not active: "Please run the command in library document."+- Command defs in that env: `Package3DCmd`, `Package3DCreateCmd`, `Package3DStop` (Stop = FINISH).++## 5. Placing the real 3D chip via the API (works)++Inside the env, with `fusion_run_modeling_script`:+```python+d = adsk.fusion.Design.cast(app.activeProduct); root = d.rootComponent+im = app.importManager+im.importToTarget(im.createSTEPImportOptions("C:/.../<MPN>-named.step"), root)   # the real body+oc = root.occurrences.item(root.occurrences.count-1)+# auto-orient: rotate the smallest bbox dimension to Z so it lies flat+# (named.step is usually already Z-thin; raw STEP often imports Y-up and needs +90 about X)+```+The chip imports at correct scale and sits on the footprint.++## 6. The library-context commands (the proper in-library path)++Enumerating command defs while the **library** is active surfaced the real in-library commands:+- `Electron::AddCustom3DModel` - opens a design to add a custom 3D model to the selected package.+- `AttachToFootprintCmd` - attaches the modeled body to the footprint (this is what maps it back ++  mints the eagle URN). It is INTERACTIVE (holds the main thread waiting for a footprint-align confirm),+  so it resists pure-API completion; recover with Escape if it wedges.+- also: `Electron::EditCustom3DModel`, `Electron::PackageFromWeb`, `Electron::RemoveCustom3DModel`.++## 7. THE URN SCHEME (the crux)++A library `.lbr` references a 3D package by **`urn:adsk.eagle:package:NNNNN/V`** (managed-library scheme),+NOT the **`urn:adsk.wipprod:...`** scheme that `fusion_aps_upload` / `save_to_cloud` produce. So you+cannot just paste an uploaded-STEP URN into the `.lbr`. The eagle URN is minted only when Fusion's 3D+Package Generator FINISHes mapped to the package. The `.lbr` markup (from the EAGLE spec + Autodesk+forum): `<packages3d><package3d urn="urn:adsk.eagle:package:N/V" type="model">...</package3d></packages3d>`+and the device carries `override_package3d_urn` / a `<package3dinstance package3d_urn="...">`.++## 8. Open item++The one step not yet automated end-to-end: minting + mapping the eagle URN (the FINISH inside the+in-library generator). Current plan: open the footprint env with the chip placed (sections 4-5), let+the human align + FINISH/save once, then export that `.lbr`, read the exact `package3d` markup + eagle+URN, and from there automate the edit-and-reupload for every future chip.