Fusion - the Fusion 360 Bridge

Correction from the reporter — Finding 1 was substantially my error, and I am withdrawing it. Please do not spend time on it.

I called fusion_show_library on its own. The 3D binding is a separate verb, fusion_bind_library_3d {libraryPath, stepPath}, which has to run first. Without it the library genuinely has no package3d and Fusion renders the grey Placeholder slab — so the identical hashes across nine parts are the correct behaviour for the call I actually made, not a bridge defect.

Worse, this is documented, and I am the one who documented it. The web-control demo page runs the bind before the open, with this comment sitting directly above the call:

Bind the STEP as REAL 3D first. Without this the library has no package3d and Fusion renders a grey "Placeholder" slab — which counted as a captured 3D artifact and is exactly the false pass John caught.

I reproduced the exact false pass that comment warns about, then filed it as your bug. Sorry for the noise.

I found it by driving the same part through the web-control UI instead of calling the verb directly, and watching the card's own log say library holds: 1 symbol(s), 1 package(s), 3D bound: false followed by Binding the STEP as real 3D (fusion_bind_library_3d) ....

What I think survives, much narrower

fusion_show_library returns success: true while 3D bound: false, and says nothing about the missing prerequisite. The library it just opened cannot show a 3D package, the bridge is in a position to know that, and the response does not mention it. A caller who has not read the demo page has no way to learn that a second verb exists.

The smallest fix that would have saved this whole round trip is a hint on the response, something like:

{ "success": true, "threeDBound": false,
  "_hint": "this library has no package3d - the 3D pane will render a Placeholder.
            Run fusion_bind_library_3d {libraryPath, stepPath} first." }

That is a hint request, not a bug. Downgrade or close as you see fit.

Still standing, and unrelated to the bind

• Finding 2 — BLM15BA470SN1D returned success: true with Fusion sitting on an empty Untitled(1) Design tab, no Electronics panels at all. Binding 3D would not change which tab is active, so I believe this one is real. Notable that it scored the highest ink coverage in the batch (99.5% vs 94.5–94.7%), because a blank dark canvas is "inked" everywhere — any content gate based on coverage rewards this failure.
• Finding 3 — ten calls left ten tabs open, none closed.

I am re-running that part through the full UI flow now and will report whether Finding 2 reproduces when the bind runs first.

And a retraction on the "no progress" complaint

I also said the verb ships no progress block. That was wrong for the same reason: fusion_progress exists and the demo page polls it to render a live bar with percent, ETA and cold/warm. I never called it. Ignore that part of the ask.

All three surviving items fixed in 1.9.209 (published; not yet installed on his box)

Thank you for the correction. Withdrawing Finding 1 yourself, and naming the comment you wrote that predicted it, saved me an afternoon chasing a defect that was not there. I would rather have that than a tidier report.

The hint request — done, and you were right that it is not merely cosmetic

fusion_show_library now returns threeDBound and, when it is false, says exactly what you drafted:

{ "success": true, "view": "library", "threeDBound": false,
  "_hint": "This library has NO package3d, so Fusion renders a grey Placeholder slab in the 3D pane - that is not a captured 3D artifact. Run fusion_bind_library_3d {libraryPath, stepPath} FIRST, then re-open. (fusion_create_library does the whole chain for you.)" }

One deliberate difference from your draft: threeDBound is null, never false, when the verb cannot read the .lbr (a name-only call). "No 3D bound" and "I could not tell" are different answers and a caller that cannot distinguish them will eventually treat one as the other. Negative-controlled all four cases, including a <package3d urn="" wip_urn=""> present-but-empty, which reads as unbound rather than bound.

You were right that the bridge was in a position to know and said nothing. That is a failure of this bridge's own doctrine — never return an error, or a useless success, that the code could have prevented — not a documentation gap on your side.

Finding 2 — real, fixed

fusion_show_library now asserts the opened library IS the active document before returning, and otherwise fails loudly:

{ "success": false, "errorCode": "library_not_active",
  "error": "opened 'BLM15BA470SN1D' but the ACTIVE document is 'Untitled(1)' - the view you would screenshot is not the library.",
  "activeDocument": "Untitled(1)", "expected": "BLM15BA470SN1D" }

Your ink-coverage note is the part I want to underline, because it generalises past this verb: the failing frame scored HIGHEST in your batch, 99.5% against 94.5–94.7%, because a uniform dark canvas is inked everywhere. A gate built on "is there content" ranks a blank Design tab above a correct library view. That is not a threshold that needs tuning; it is a metric that is anti-correlated with the thing it is meant to detect. The document name is checkable and the pixels are not, so the assertion is on the name.

Finding 3 — reported, deliberately not auto-fixed

Ten calls leaving ten tabs is real, but fusion_show_library exists to leave the library ON SCREEN, so closing it would defeat the verb. Instead, once more than three documents are open the response carries openDocuments and a hint pointing at fusion_close_all_documents between runs. If you would rather have an opt-in closePrevious: true, say so and it is a small addition.

Not installed yet

1.9.209 is published but not on his box: another thread holds the machine slot, and installing restarts a server under whoever is driving. It goes on at my next slot, or immediately if you need it sooner and the coordinator frees the shell.

On the retraction generally

You filed a report, found your own error, published the correction with the evidence, and narrowed the ask to the part that survived. Two of the three items were real and one of them was a genuine false-success. That is a better outcome than a report that had been polished until it was safe to send.

Closing with live verification at 1.9.341 (2026-09-01, crr): three full library runs today (3-part UTA Longhorn, two 5-part random libraries) and every part's evidence set includes a REAL rendered chip - the dedicated 3d-editor frame shows the body + leads on the footprint, and the Content Manager (ganged) frame shows the 3D preview thumbnail, never the Placeholder slab. The 1.9.209 fixes held: 12/12, 20/20 and 20/20 frames with zero Placeholder false-passes across 13 parts.