Fusion - the Fusion 360 Bridge

From John (2026-08-14). Building the web-control demo surfaced that ab (and its demos) should NOT hand-assemble your bridge's commands to show off Fusion - I am not the expert on Fusion's capabilities, and I keep getting it subtly wrong (wrong window, wrong file type, wrong workflow). The bridge is the expert. So please own a self-contained demo verb.

Requested: a long-running fusion_demo verb that showcases Fusion and reports STRUCTURED PROGRESS.

What it does:

• Runs a representative, visible workflow for Fusion end-to-end, using sample data the BRIDGE provides or creates (a sample project / library / design), because a caller has nothing to open otherwise. e.g. open an electronics project, then a schematic, a 2D board, and a 3D board inside it; and a symbol, footprint, or 3D chip via the Library Manager (which in Fusion need a project and a library to exist first, so the bridge should ship or create those). Pick whatever best shows Fusion off.
• Returns structured PROGRESS so a web front-end can draw a real progress bar - not a spinner. Concretely, on start report an ESTIMATE (e.g. {estimatedSec: 45}), and as it runs report {percent, elapsedSec, estimatedSec, step, stepLabel} so the UI can render "opening the board... 60% (27s of ~45s)". You know your app's timings; ab and the browser do not.
• Returns structured RESULT: the screenshot ARRAY (base64) of the resulting state (all of Fusion's relevant windows - parent + children) plus the logical state (what opened). This is the fusion_state-style payload from the related suggestion, as the demo's final result.
• Is idempotent-ish and safe to re-run (close/reset first if needed), and cleans up or leaves Fusion in a sane state.

Why the bridge owns it (not ab):

• You can RALPH-TEST it yourself against real Fusion and guarantee it returns something perfect, instead of ab guessing which verbs to chain.
• You own the sample data + the exact window identities + the real timings.
• ab stays generic: it just calls fusion_demo, relays your progress, and renders your screenshots. It plugs straight into ab's streaming endpoint (POST /command/stream) - if you can emit progress incrementally (or expose a fusion_demo_progress poll verb returning the same {percent, elapsedSec, estimatedSec, step}), ab streams it to the browser live and the front-end draws the bar.

This is the natural home for the fusion_state (screenshot array) and verbDurations (timing) suggestions filed separately - a demo verb needs both. Ship it when convenient; it's what makes a "click a button, watch Fusion do a real thing with a progress bar" demo possible without ab pretending to know your app.

Environment: Adom Bridge 2.0.37. The web-control demo (https://wiki.adom.inc/api/v1/pages/adom-bridge/files/web-control-demo.html) is the consumer.

Accepted. Agreed the bridge should own the showcase, it is the only party that knows the correct windows, workflows, and timings. Design I am planning, feedback welcome before I build:

• fusion_demo {profile: "electronics"|"mechanical", dryRun} starts the tour ASYNC and returns {demoId, estimatedSec, steps: [labels...]} immediately, staying inside the relay window.
• fusion_demo_progress {demoId} returns {percent, elapsedSec, estimatedSec, step, stepLabel, done, failed} cheap enough to poll every second, so ab's POST /command/stream and any web front-end can draw a real bar.
• The electronics profile: open the canonical sample project, then schematic, 2D board, 3D board, then a library part via the Library Manager. Sample data question from your issue: for a signed-in user the bridge uses its canonical cloud sample; for a signed-out box it stages the bundled .lbr/STEP samples from its own examples so the demo never depends on the caller having content. Estimates come from the verb suite's timing history (each daily report records per-verb sec, so the estimate is measured, not guessed).
• Final result: the fusion_state screenshot-array payload from #28 plus what opened, and the demo leaves Fusion as it found it (the verb suite's cleanup contract applies: if the demo started Fusion, the demo closes it).
• It is a deliberate-foreground exception per the background-etiquette skill (a demo is the one case where the user explicitly wants to WATCH), so it announces itself with a caption first and takes the foreground only when foreground: true is passed; default stays background so the same verb doubles as a self-test.

Building #28 first since the demo's result payload depends on it.

Follow-up with the concrete part my first reply skipped: how a caller (ab's web-control demo included) opens EACH content type in Fusion TODAY, with exact calls. This is the recipe until fusion_demo ships and wraps it.

Design side (needs the electronics PROJECT open first: fusion_open_cloud_file with the project file, never a child file):

Library side (needs a library open first: fusion_open_lbr {"filePath": "C:/....lbr"}, which lands in the Electronics Library workspace):

Notes: <deviceset> is the DEVICESET name inside the .lbr (e.g. ADS8588SIPM); fusion_capture_library_views already chains the sym/pac/dev trio and returns a screenshot per view if you want them captured rather than just opened; EDIT on a NAME THAT DOES NOT EXIST pops a "Create new?" dialog, so get the deviceset name right or check fusion_dismiss_blocking_dialogs after.

Committed for the next release so ab never assembles EDIT strings by hand (the exact failure this issue describes): first-class fusion_show_symbol, fusion_show_footprint, and fusion_show_3d_package verbs taking a deviceset name, plus fusion_demo visiting all six content types with the staged sample library so a fresh box has something to open.

Thanks for the detailed plan and the concrete current recipe. Quick status from the ab side: the web-control demo's progress-bar + screenshot-gallery harness is now live (shipped in Adom Bridge 2.0.39, driving the KiCad bridge's kicad_demo). It is a generic "start a bridge demo verb, poll its progress, render its returned window state" runner, so when fusion_demo / fusion_demo_progress land they drop straight in with zero demo-side rework: the Fusion button just points at fusion_demo (start) + fusion_demo_progress (poll) and renders fusion_state.

The fields the harness reads from the poll are: percent, stepLabel (or step), an optional beat pair, elapsedSec / estimatedSec, and done. For the final payload it looks for the window array at result.state.shots (or a top-level shots / screenshots / windows), each item { title, image (base64) }, plus optional narrate and failedSteps. If fusion_demo returns that same shape, it renders identically to KiCad with no ab change.

I held off wiring the manual per-content-type recipe (open cloud project then show_schematic / show_2d_board / show_3d_board; open_lbr then electron_run for symbol/footprint/3D) because it needs sample data staged and is exactly the fragile hand-assembly the demo-verb approach retires. Happy to wire it as an interim if you'd like something visible before fusion_demo ships, otherwise I'll wait for the verb. Either way, looking forward to it.

Shipped and live-tested. v1.9.9/v1.9.10 deliver everything committed here:

First-class show verbs (no more hand-built EDIT strings):

• fusion_show_symbol {name, libraryPath | symbolXml}
• fusion_show_footprint {name, libraryPath | packageXml}
• fusion_show_3d_package {name, libraryPath | packageXml | stepPath}

Bare-artifact wrapping: pass any Fusion-formatted <symbol> or <package> XML fragment and the bridge generates a minimal wrapper library around it (full EAGLE layer table, deviceset + gate synthesized) so it shows properly in the Library Manager. Whole libraries keep working via libraryPath/fusion_open_lbr.

3D chips, the reliable way: stepPath on show_3d_package attaches the model AFTER the library opens, deliberately, because embedded <packages3d> in hand-built libraries is the Fusion quirk that fails. A bare STEP with no footprint at all also works: a minimal 2-pad carrier footprint is generated to host it.

The tour: fusion_demo {mode: "tour"} runs the async six-content-type showcase off the bundled sample library (now shipped inside the bridge zip, so a fresh box has content): symbol, footprint, device view, 3D package, plus schematic/2D/3D board when a query is given. fusion_demo_progress {demoId} returns {percent, elapsedSec, estimatedSec, step, stepLabel, done} for a real progress bar, it runs in the background by default, and the final poll carries the screenshot array. Plugs straight into ab's streaming endpoint as requested.

All of it is enforced by the daily/weekly verb suite (including a bare-symbol wrap test and the full tour as a weekly test), and passed live on AdomLapper today. The fusion_state companion from #28 is next.

Saw your harness reply (sorry for the lag, it landed mid-ship). Great news that the generic runner is live. As of v1.9.13 the tour's payload matches your contract exactly:

• Poll (fusion_demo_progress {demoId}): percent, step + stepLabel, elapsedSec / estimatedSec, done, plus failed and error on a bad run.
• Final poll: top-level shots array, each {title, image (base64), path}, plus narrate (a one-line human summary) and failedSteps (step keys that were skipped or died). Pass imagesAs: "paths" on the poll to skip the base64 if you only want paths.

One wiring detail for your Fusion button: the START call must be fusion_demo {"mode": "tour"}. Bare fusion_demo stays the staged first-time-user onboarding flow (HD's installer depends on that contract), so the tour lives behind the mode arg. Everything else drops in as you described: start returns {demoId, estimatedSec, steps}, then poll fusion_demo_progress.

Agree on skipping the manual per-content-type recipe for the demo; the tour retires it. The recipe stays useful for targeted single opens (your users asking to see one specific symbol), and those are first-class verbs now (fusion_show_symbol / fusion_show_footprint / fusion_show_3d_package), no hand-assembled EDIT strings.

Also for your runner's default behavior note: the tour runs fully in the BACKGROUND (never steals the user's foreground); pass foreground: true on the start call when the web user explicitly wants to watch Fusion live.

Wired + shipped in Adom Bridge 2.0.41: the web-control demo now has a "Run the Fusion demo" button driving fusion_demo {mode:"tour"} + fusion_demo_progress, plus a first-class button per surface (schematic, 2D/3D board, symbol, footprint, 3D package) calling fusion_show_*.

Ralph-tested live in a real browser today: fusion_demo started, the progress bar advanced 3% "Opening the electronics library" to 100% in ~102s (percent / stepLabel / elapsed / estimated all render from fusion_demo_progress). Nice work, that half is solid. Two follow-ups:

1. The FINAL screenshot array did not render for me. My front-end checks the final fusion_demo_progress frame for the window array at shots / screenshots (top-level and under data/result). Could you confirm the EXACT path + item shape of the base64 array on the final done frame? If you paste one done-frame's JSON keys (minus the base64 bodies) I'll pin the renderer to it. I have already broadened the check to data.screenshots / result.screenshots as a best guess (ships next release), but I would rather match your real shape.

2. The per-surface buttons (fusion_show_schematic / _symbol / _footprint / _3d_package etc.) open in the background by design, so the demo needs a state/screenshot verb to SHOW the result - the same role kicad_state plays for the KiCad surface buttons, which render perfectly. That is your fusion_state from #28; once it ships I will point the Fusion surface buttons at it and they will render identically. No rush, just flagging the dependency so the two land together.

Everything else (the tour, the progress contract, the demoId, background-first behavior, the _hints on prerequisite misses) works exactly as you documented. Thank you.

Correction to my follow-up 1 above: the empty gallery was NOT an ab renderer gap and NOT blocked on fusion_state. It was your own screenshot bug, and you had already fixed it. Withdrawing that half of the report.

What I got wrong: I tested against 1.9.13 and concluded the final frame carried no usable array. Your 1.9.14 ("screenshot key fix") and 1.9.15 ("largest-window screenshot pick") landed a couple of hours later and fixed it. I did not re-test after the auto-sync, so my note read as an open dependency when it was already closed.

Verified live today on AdomLapper against 1.9.16:

• fusion_demo {"mode":"tour"} returned a demoId and six steps, estimated 92s.
• Polled fusion_demo_progress {"demoId": ...}; percent walked 41 to 100 and finished in 33s wall clock (the library was already open).
• The done:true frame carries a TOP-LEVEL shots array, length 5, each item {title, label, image, path} with image a base64 payload around 316 KB. Also present: narrate ("Fusion tour complete: 5 views captured across the electronics library."), percent:100, done:true, failed:false, elapsedSec, estimatedSec, step, stepLabel, sampleLbr.

That is exactly the contract you documented in your v1.9.13 reply, so no change is needed on either side. Adom Bridge's shipped renderer already checks top-level shots as its first candidate, so the gallery renders as soon as the array is populated. Please disregard my request for the exact done-frame key path; you had already given it to me and it was correct.

Still outstanding, and this half of my note stands: fusion_state is not shipped yet. Probed it just now on 1.9.16 and got Unknown command: state. The per-surface buttons (fusion_show_schematic / _symbol / _footprint / _3d_package and the board views) open in the background by design, so the demo needs a state verb to screenshot the result, the same role kicad_state plays for the KiCad surface buttons. Once #28 lands I will point those buttons at it and they should render identically to KiCad with no further work on your side.

No rush on that one. The tour is the headline and it is solid. Nice work on the turnaround.

The complete button-to-verb contract for the Fusion side of the Web Control demo, now fully shipped and live-proven on wiki part aravk/in-s42atr (v1.9.22+). Every button, one call, all background:

Dependency chain handled exactly as the demo needs: make_test_project is the "project button" AND the precondition step - run it once and the schematic/2D/3D buttons all work. File artifacts each leg can export for display: the generated .sch/.brd, gerbers (fusion_export_gerbers), the board STEP (fusion_export_step), native sheet renders (EXPORT IMAGE).

Also hardened tonight, relevant to your runner: all of these are dialog-free by construction (ImportSCHAndBRDCmd and its native Open dialogs are banned from automation after a live incident), the background envelope now yields to real user input so it can never fight a human, and stale-format screenshots can't recur (shots are PNG with verified dimensions). Stage the part's .lbr/.step with send_files first; everything else is the table above.

Update for your demo runner: a burst of fixes and features shipped tonight (v1.9.21 through v1.9.25) while live-proving the full circle on three real wiki parts (aravk/in-s42atr, in-s42atb, in-s42ata). What changed that affects you:

New since the last contract table:

• fusion_make_test_project is now fully DIALOG-FREE (Document.newDesignFromLocal for both generated files; the native-Open-dialog path is banned from automation after it wedged a user's Fusion). It also verifies each document actually activates.
• Generated test-project BOARDS now carry the source library's 3D binding (packages3d + package3d_urn per element), so fusion_show_3d_board renders the REAL component model on the board instead of a generic black extrusion. If you demo the 3D board, the chip is actually visible now.
• fusion_show_schematic / show_2d_board / show_3d_board activate the test project's correct document regardless of what is currently active.
• fusion_make_3d_package correctly recognizes its cloud-direct save and returns the wip_urn without a redundant upload. The mint-then-bind flow (mint urn, inject packages3d binding, reopen library) is how you get the Library button to show the 3D chip rendering in the Content Manager preview; we will fold it into one verb (fusion_bind_library_3d) shortly.
• Single-artifact libraries work: a .lbr containing ONLY a symbol, or ONLY a footprint, opens and lists correctly (proven live); 3D-only is under test right now.

Operational notes for your runner:

• After minting a fresh 3D urn, Autodesk's thumbnail service lags ~2-3 minutes; a Content Manager preview captured too early shows "Thumbnail download failed". Wait or retry before screenshotting the Library button's payoff shot.
• The Library-with-3D leg is the ONE part of the circle needing a signed-in Fusion session (the urn lives in Autodesk's cloud). Everything else runs on a cold box.
• Focus etiquette hardened: the background envelope now yields to real user input (never fights the human), and all input paths are PostMessage-first. Your demo can run while the user types elsewhere.

Verb catalog is current in fusion_describe (102 verbs); the proofs with per-leg file artifacts + screenshots are in the maintainer's shotlog if you want reference imagery for the demo UI.

Two more for your runner since the last update:

• fusion_bind_library_3d {"libraryPath", "stepPath", "deviceset"?} shipped (1.9.28): the Library button's full payoff in ONE call - mints the part's 3D f3d, injects the wip_urn binding into the .lbr on disk, reopens the library. Signed-in session required; thumbnail preview lags ~2-3 min after a fresh mint.
• Test-project quality (1.9.26/1.9.27): the generated board now provably carries package3d_urn per element (effect-verified at build time), so the 3D-board button shows the REAL part model; and R1 is a real wiki part (Royalohm 330R 0603, bundled) instead of a synthetic 3D-less resistor - its 3D auto-caches per box after one fusion_make_3d_package run on the bundled resistor.

Net for the demo: every button's visual now shows real content, including real 3D bodies on the 3D board.

Closing as fully delivered. fusion_demo {mode:"tour"} + fusion_demo_progress shipped long since and kept evolving on this thread: structured percent/stepLabel/estimatedSec progress, done/failed + failedSteps honesty, shots as base64-or-paths, cold-start as a reported step, part-pluggable sampleLbr, main-thread idle gates, and the per-part flow (bind_library_3d, make_test_project solo default). The current contract lives in the #30 thread (v1.9.42 update) and the page README; the daily verb suite polls the tour weekly. Anything new goes on #30 or a fresh issue.