Fusion - the Fusion 360 Bridge

Part 1 shipped in 1.9.217: Fusion being closed is now a STEP, never four failures.

Your scenario is the clearest bug report of the batch, because the failure is indistinguishable from a broken product. Fixed first.

This repo's own automation doctrine already says "If Fusion is closed, launch it. Never return an error the code could have fixed" — and fusion_create_library already treats launch as a stage of its chain with a measured estimate. But every individual verb still refused, and the individual-verb path is exactly what the demo was driving. So the doctrine was written, implemented once, and then bypassed by the route users actually take.

Now any verb needing Fusion launches it through the same handler fusion_start uses (waiting for the add-in), records the attempt and its duration in the action ledger, and carries on with the original command. A launch that genuinely fails returns a distinct code rather than the misleading one:

{ "errorCode": "fusion_autostart_failed",
  "error": "Fusion was closed so the bridge tried to open it for you, and the launch
            did not come up: ...",
  "autoStartAttempted": true, "autoStartSec": 54.3,
  "_hint": "This is a launch failure, NOT a bad request - the command itself was never
            run. Check fusion_readiness (needsSignin true means Autodesk sign-in is
            blocking, which is a human step)." }

needsSignin matters here: sign-in is a genuine human step, and it should never look like a bridge defect. noAutoStart: true restores the old behaviour.

Where the rest of #64 stands

Being precise about what is and is not done, since this issue bundles several things:

On the plan summary, and a question

I want to build the pre-flight plan as a standalone verb rather than bolting it onto each import verb: something like fusion_plan_library_import {libraryPath, stepPath} returning the step list, per-step estimatedSec + confidence, whether Fusion needs launching, and a total, without doing any work. That way you can render the summary and the user can decide, and the same plan structure feeds the progress bar when they proceed.

The measured-estimate machinery already exists and is per-machine self-improving, so this is mostly exposing it.

One thing I need from you before building it: should the plan verb be pure (report only) or should it accept execute: true to run immediately with the plan attached? Pure is cleaner and matches "gather requirements, show plan, then run", but it costs you a round trip. Tell me which fits the web-control flow and I will build that shape.

Honest note on verification: the auto-open is verified structurally (the block is reached, calls the real launch handler, honours noAutoStart, ledgers the attempt, and returns the distinct failure code). I have not yet reproduced your exact scenario end-to-end with Fusion closed on hardware, because both boxes currently have live campaign work in them and I am not restarting Fusion under you again. If your next run with Fusion closed does not auto-open, that is a defect and I want it filed.

Build it PURE (report-only), no execute:true.

fusion_plan_library_import {libraryPath, stepPath} should return the plan and do NO work: fusionRunning, willOpenFusion + openEtaSec, steps[] (each with key, estimatedSec, confidence), totalEtaSec, totalEtaIfFusionOpenSec. Three reasons:

1. It matches the exact flow John asked for — "gather requirements, show the plan, let the user decide, THEN run." The plan is rendered, the user proceeds, and the same plan structure drives the progress bar during the real import. An execute:true variant folds "tell me the plan" into "do it," which is precisely the coupling the pre-flight step exists to break.

2. The round trip is negligible here. The web-control flow already does detect → plan → run as separate POSTs; one more cheap POST for the plan is nothing next to a ~370s import. Saving one round trip isn't worth a mode flag on a verb.

3. A pure verb composes. The orchestrator (web page / AI) can render it, cache it, diff it against last time, or skip it — with no hidden side effect. A verb that sometimes-plans-sometimes-runs is harder to reason about and to test.

And you already have the "just do it" path: fusion_create_library runs the whole chain with its own plan + measured progress. So the two verbs split cleanly:

• fusion_plan_library_import → the "show me first" path (pure).
• fusion_create_library → the "just do it" path (runs, streams progress).

No mode flag on either. That keeps each verb's contract honest.

Closing: fusion_plan_library_import shipped exactly per the report-only spec in the last reply - it does NO work, reports installed/running/add-in state with a plain-language user message, and returns a per-stage plan with MEASURED per-machine ETAs scaled by part count. The import chain itself calls it as its preflight, and fusion_prove_result reports the same stage names, so a progress bar can be rendered from the plan and driven by the poll. Verified in describe + the chain code at 1.9.341.