Fusion - the Fusion 360 Bridge

From the Adom Bridge web-control library-import test campaign (the same campaign that surfaced the Untitled-docs buildup you fixed in 1.9.210 with fusion_reset_workspace, and confirmed clean on 1.9.211: a 10/10 Fusion pass).

The gap

There is no single verb that imports a library and returns its evidence. Today the caller has to orchestrate the whole thing, and that orchestration knowledge lives in our web-control demo page, not in the bridge. A normal Adom user (or their AI) who calls the Fusion bridge directly gets nothing automatically for "import this library" - they'd have to know the exact multi-verb dance and collect each screenshot themselves.

Here is what a caller must run today, in order, to prove one library import (straight from web-control-demo.html):

1. fusion_bind_library_3d { libraryPath, stepPath } - bind the STEP as real 3D. Mandatory, or the 3D comes back a grey "Placeholder" slab (the false pass John caught). This is a real trap: the caller must know to do this FIRST.
2. fusion_show_library { libraryPath } - open the library.
3. fusion_show_symbol { name, libraryPath } - returns the symbol screenshot.
4. fusion_show_footprint { name, libraryPath } - returns the footprint screenshot.
5. fusion_show_3d_package { name, libraryPath, stepPath } - returns the 3D screenshot.

Each fusion_show_* returns only its own screenshot. The caller collects them. Five verbs, a mandatory ordering, and a placeholder-3D trap - all of which every consumer has to re-implement.

What we need

1. One verb that returns the full FOUR-artifact evidence bundle

A single verb (e.g. fusion_import_library { libraryPath, stepPath }) that does the bind and captures all four required artifacts. All four are part of the contract - a pass is 4/4, and the ganged view is required, not optional.

2. It must stream the four artifacts INCREMENTALLY, IN THIS EXACT ORDER

An import takes roughly 370s in our runs. The bridge must emit each artifact the moment it captures it - never go silent for ~6 minutes and then dump all four at the end. The caller/UI should watch the evidence build up live, in the order a library is actually assembled:

1. Symbol shows up FIRST - the schematic symbol (labels placed clear of the body)
2. Footprint shows up SECOND - the PCB land pattern / pads
3. 3D chip shows up THIRD - the 3D package, bound and placed on the footprint (never a placeholder slab)
4. Ganged view shows up LAST, as the final proof - the combined library view showing symbol + footprint + 3D together. It comes last on purpose: it is the culmination that proves the library assembled as a unit, not just three isolated opens. This is generally the way a library is set up, so the evidence should arrive in that same order.

The ganged view must NOT be the only thing that shows up at the end - the first three each appear as they are gathered, and then the ganged view lands as the closing proof.

Please deliver this through the measured-progress contract (the active[] poll shape / progress emit), so a web renderer (and any AI caller) can show each artifact landing as it happens, with the phase it's on. Each emitted frame should carry the artifact it just finished (its screenshot + a label: symbol -> footprint -> 3d -> ganged, in that order), so a poller assembles the bundle progressively and sees the ganged view arrive last.

3. A REAL, measured progress bar across the whole import

Each of those steps takes real time (bind, then symbol, then footprint, then 3D, then the ganged view - ~370s total in our runs), so the user must see a genuine progress bar advancing the whole way through, not a spinner and not a 0-then-100 jump at the end.

Use the measured-progress contract honestly:

• confidence: "measured" - the percent must reflect actual progress through the known phases, not a guess. If a phase's duration is only estimable, say so (confidence other than measured) so a renderer can dim it rather than present a guess as fact.
• phase - a human label for the step currently running (e.g. "binding 3D", "capturing symbol", "capturing footprint", "capturing 3D package", "capturing ganged view").
• percent - advances across the five phases (bind + the four captures). The bar should visibly move as each phase completes; the four artifact emits above are the natural checkpoints.
• etaSec where you can estimate it, so the user knows roughly how long is left.
• If a phase blocks on something (e.g. a signed-in Autodesk session for the 3D bind), set blockedBy so the bar goes amber and stops rather than sliding while nothing is happening.

Net: one verb, five measured phases, four artifacts streamed in order (symbol -> footprint -> 3D -> ganged), and a real bar the user can watch the entire ~6 minutes.

Why this matters

The whole goal is that any Adom user who imports a Fusion library "just works" and can see the proof. Right now the proof only exists because our demo page happens to know the 5-verb sequence. Moving that into one bridge verb - with incremental evidence delivery - means every user and every AI gets the four-artifact proof for free, watching it build in real time, with zero coupling to our demo.

Happy to test a fusion_import_library (or whatever you name it) through the web-control matrix the moment it ships, across symbol / footprint / 3D / ganged for a batch of real components, and report back here.