Fusion - the Fusion 360 Bridge

John saw what happened on screen: a Fusion dialog about a document saving to the cloud popped up during the bind, the bridge was blocked behind it, and the bridge's answer was the add-in restart and then a Fusion relaunch. His words:

"i have told fusion-bridge 100 times to make sure it pre-empts any save or save as dialog box from popping up so that it doesn't get blocked. it seems to me what fusion-bridge does is it just forces a restart of fusion in those cases, so that is a very bad sledgehammer approach. however, i understand if it truly doesn't know what to do, it has to give up. but i think what's better is for it to screenshot itself using ab and make sure it gets the parent/child screenshots that ab will give back, then it should give the ai the parent/child array of screenshots so the ai can figure out how to expire that dialog box, and then the fusion-bridge can get unstuck."

Concrete asks, in that order:

1. Pre-empt the save / save-as / save-to-cloud dialogs before every step that can raise them (the fusion-no-modal-dialogs skill doctrine), so the bind never blocks on one.
2. When a call still blocks on a modal: do NOT restart anything. Capture Fusion with ab's window capture in parent+child mode (the child windows are the dialogs) and return that parent/child screenshot array on fusion_prove_result (or the verb's reply) as blockedOn {shots[], since, step}, so the AI can read the dialog and dismiss it (fusion_dismiss_dialogs / a click) and the run continues from the same step.
3. Restart stays a last resort the AI asks for explicitly (allowRestart:true with a reason), never the bridge's own move.

Accepted, working on it now. Direction: (1) a modal that blocks the add-in never triggers a restart; the bridge captures Fusion with ab's window capture including owned child windows, classifies the dialogs it knows, answers the ones it has a rule for, and otherwise returns the parent/child screenshot array plus the dialog rows to the caller as blocked_by_dialog so the AI can expire the box; (2) chains (install_library_bundle, create_library) never relaunch Fusion on their own; they surface addin_restart_required with restarts[] history and resume at the part they were on; allowRestart:true with a reason is the only way a chain restarts; (3) the bind's document closes drain the cloud save first so the save-to-cloud dialog is pre-empted; (4) the slow add-in during a STEP bind is treated as busy, not dead. Will report the release here.

Shipped in 1.10.17 and 1.10.18 (insiders, on ConfRoomROG, AdomLapper, arav-rog, winvm) and verified live on ConfRoomROG.

What actually relaunched Fusion. The add-in gate classified a long operation in flight (the STEP bind starving the add-in for 20 to 60 s) as "add-in not loaded" and took the restart path. That phase is now fusion_addin_busy, like every other busy phase. Your ask 3 was the root cause.

Dialogs, in John's order. Before a verb that needs the add-in, and after one times out behind a modal, the bridge now:

1. reads every dialog through UIA: title, visible text, button names, and the category when a rule matches (no pixels);
2. expires them without a person: known ones through their rule, unknown ones with WM_CLOSE (Cancel or the X, which never saves or discards);
3. re-probes the add-in and runs the verb when the screen is clear (dialog_expired_retry after a timeout);
4. only if a dialog survives, answers blocked_by_dialog with dialogs[] {hwnd, title, category, text, buttons, resolution} first and ab's parent/child screenshots second, so the caller answers it by button name (desktop_ui_click {hwnd, name}) or cancels it.

The bridge never restarts Fusion over a dialog any more; the 90 s auto-restart from 1.10.6 is gone.

Chains. fusion_install_library_bundle and fusion_create_library never relaunch Fusion on their own. They surface addin_restart_required and wait (resumable); allowRestart:true with restartReason is the only way they restart, recorded as restarts[] {at, why, kind} on fusion_prove_result.

The save-to-cloud dialog is pre-empted: close_document and close_all_documents drain the cloud upload for up to 180 s before closing (was 45 s and close_document only) and defer instead of closing over a live upload.

Live proof on ConfRoomROG (1.10.18): an unknown message box was raised in front of the add-in, then fusion_document_info was called. The ledger shows blocked_by_dialog with the box read as "AdomBridge", WM_CLOSE tried and ok, nothing left afterwards; the verb then succeeded in 17 s, Fusion stayed up, no restart entry. On 1.10.17 the same test still hit the restart because the gate fell through after the expiry; 1.10.18 closes that.

Honest limits: a dialog whose only safe answer is a real decision (Save changes? for a document you own) still comes back to the caller, by design; the bridge picks nothing that saves or discards.