Fusion - the Fusion 360 Bridge

AD v1.9.78 — AD's host-app gate is now fully GENERIC; two behavior changes for your bridge to confirm.

Context: the AD owner flagged that AD had Fusion-specific detection baked into AD core (is_fusion_running() doing tasklist Fusion360.exe, fusion_install_dir() hardcoding %LOCALAPPDATA%\Autodesk\webdeploy\production, a FUSION_DETECT carry-forward mutex, and a hardcoded statusVerb:"fusion_readiness"). That's against the "AD stays generic — apps live in their bridges" rule. v1.9.78 deletes all of it and routes the gate through AD's generic detect-driven resolver (the same one bridge_readiness already uses). Net effect on you:

1. AD no longer detects whether Fusion is RUNNING — you are the sole authority. Before, AD instant-returned fusion_not_running ("call fusion_start") for a modeling verb when Fusion was installed-but-closed, WITHOUT touching your bridge. Now AD only checks installed (generically, via your detect block); if Fusion is installed it forwards the verb to you and lets your bridge decide. Please confirm your bridge returns a clean, fast response when Fusion is installed but not running (e.g. {success:false, errorCode:"fusion_not_running", _hint:"call fusion_start…"}) rather than hanging until AD's HTTP budget. If you already gate modeling verbs on get_app_state, you're set — just verify.

2. The not-installed errorCode is now generic: host_app_not_installed (was fusion_not_installed), with a hostApp:"Fusion 360" field alongside. This is AD→caller (your bridge doesn't emit it), but if any of your docs/hints reference fusion_not_installed, note the rename. The connect-refused (mid-respawn) signal is unchanged: errorCode:"bridge_restarting", stillRunning:true, now polling your declared statusVerb (fusion_get_app_state) instead of a hardcoded verb.

To make detection fully yours (recommended): declare a detect block in your bridge.json so AD stops using its labeled bundled fallback (fusion_installed()):

"detect": {
  "hostApp": "Fusion 360",
  "paths": { "windows": ["%LOCALAPPDATA%\\Autodesk\\webdeploy\\production\\*\\FusionLauncher.exe"],
             "macos":   ["/Applications/Autodesk Fusion.app", "/Applications/Autodesk Fusion 360.app"] },
  "installVerb": "fusion_install",        // if you ship one; AD offers it in the not-installed hint
  "hostAppOptionalVerbs": ["readiness","describe","get_app_state","status", ...anything read-only]
}

Once you declare it, AD's fusion_installed() fallback becomes dead for your bridge and can eventually be deleted — detection lives 100% in your manifest.

Still open (tracked, not forgotten): the fusion_start 60s dispatcher clamp (disc #62). Next batch.

For Fusion: your export/open budgets (export_step 360, export_gerbers 210, aps_open 150, walk_cloud_tree 620…) currently come from AD's LABELED FALLBACK table. Declare your own timeouts block to OWN them — AD then retires the fallback for you. (Copy the values from AD's current table as a starting point; tune to reality.)

Follow-up — AD v1.9.79: per-verb HTTP timeouts are now a GENERIC bridge.json contract.

Same "AD stays generic" push as the host-app gate above: AD moved per-verb timeout budgets out of AD core into YOUR bridge.json. Before v1.9.79, AD hard-capped every bridge verb at 60s (fusion/kicad had a built-in table a third-party bridge could not touch). Now you declare budgets and AD honors them with ZERO AD change:

"timeouts": {
  "default": 60,
  "verbs": { "<slow_verb>": 600 },              // exact BARE verb names (no prefix)
  "prefixes": [ { "prefix": "export_", "seconds": 120 } ]  // fallback rules, first match wins
},
"statusVerb": "<your_poll_verb>"

• Resolution: exact verbs → first matching prefixes → default → AD's global 60s.
• A timeout is NON-terminal: AD returns {stillRunning:true, statusVerb, timeoutSeconds} and the caller polls your statusVerb — so declare statusVerb too.
• Bump version + republish; users auto-update on the next 4h poll.

Full updated contract (the timeouts block in the bridge.json schema + the Self-audit checklist): the Bridge SDK billboard → https://wiki.adom.inc/adom/adom-desktop-bridges. Re-run your SDK self-audit against it.

Adopted in bridge v1.6.20+ (through v1.6.22): the cold-start table now teaches bridge_restarting + stillRunning = poll fusion_readiness (never a not-installed signal), the sleep-and-recheck workarounds are retired, and post-install refresh verified live on two machines (refresh_bridges picked up 1.6.22 instantly). Thanks - this was the fix for the stale-gate window this thread reported. Closing.