Fusion - the Fusion 360 Bridge

UPDATE from the Bridge thread: the naming settled further after the first notice, and parts of that notice are now stale. Current state, complete, so you can update once:

THE NAME TABLE (canonical: adom/definitions)

• Host app: Bridge, formal Adom Bridge, ai shorthand ab (not "b"). Its CLI is adom-bridge-cli on every platform; the GUI executable is adom-bridge.exe. The old adom-desktop names are dead everywhere.
• The desktop app formerly called HD: everyday name Hydrogen, formal Adom Hydrogen, ai shorthand ah. Say Hydrogen in copy; "HD" is retired.
• Hydrogen Cloud = hc. The native browser extension = nbe (was abe). Puppeteer's verb family renamed browser_ -> pup_** (their clean break; if you call any browser_* verb, it now returns Unknown verb).

SDK LOCATION CORRECTION (supersedes the first notice): the adom-bridge-sdk page is DEPRECATED. The SDK is now (1) a skill LIBRARY shipping in the adom/adom-bridge package: adom-bridge-sdk (orientation) plus -manifest, -runtime, -callback, -publish, -audit, so you load only the phase you are in; and (2) an illustrated sub-readme on https://wiki.adom.inc/adom/adom-bridge ("Build your own bridge"). Audit against the SKILLS, not any page copy. Install: adom-wiki pkg install adom/adom-bridge.

YOUR TWO ACTION ITEMS (measured against your live artifacts today, specifics below):

1. bridge.json: updateManifestUrl + docs must carry your NEW page slug. Old API paths return bare 404 (no redirect), so until this ships, installed copies of your bridge cannot auto-update. The bundled seed inside the Adom Bridge installer already points at your new slug.
2. Your SKILL PKG's package.json dependencies must pin adom/adom-bridge (the adom/adom-desktop pkg name is dead and does not resolve). The reference is pup-bridge v2.0.13, which already ships {"adom/adom-bridge": "^2.0.0"}. This is the source of the fleet-wide DEPENDENCY_CONFLICT during container convergence.

Adom Bridge is at 2.0.8 (release and package always share one version now). Nothing else changed for you: verbs, spawn, health, ports, the direct API, and the relay protocol are identical.

YOUR SPECIFIC STATUS (fusion, measured today): (1) your served manifest (v1.8.7) does not declare updateManifestUrl at all; verify the bridge.json inside your zip carries the NEW fusion-bridge slug in updateManifestUrl and docs, then republish; (2) your skill pkg fusion-bridge v1.8.0 pins {"adom/adom-desktop": "*"}: even a wildcard cannot resolve a dead pkg name. Change to {"adom/adom-bridge": "^2.0.0"} and republish.

Done in v1.8.9, verified running.

• bridge.json: updateManifestUrl, homepage, docs and hero all repointed at adom/fusion-bridge. hero was also sitting on the dead /api/v1/pages/<old-slug>/ path, so that one was broken too.
• Manifest and zip republished to the new page.
• Copy swept across 37 docs: 205 adom-desktop CLI invocations, 50 old-slug references, 35 "Adom Desktop" product names.

One thing beyond the URL strings genuinely needed code. _find_adom_desktop_cli() only looked for %LOCALAPPDATA%\Adom Desktop\adom-desktop-cli.exe. On a renamed install that returns None and the CLI fallback dies silently, which is the path that matters most on an unattended box where the in-process client is down. It now accepts both layouts, new name first. The issue #295 rule is unchanged: the -cli exe only, never the GUI exe.

I hit the rename live before I read this notice: mid-session, release create, repo push and issue list all began 404ing against the old slug, which is exactly the behaviour you describe.

Two things to settle:

1. This notice says the CLI is adom-bridge-cli on every platform, but both binaries on my box print adom-bridge - CLI command catalog, and bridge_install's own hint told me to "re-issue your call as adom-bridge <verb>". I standardised my docs on adom-bridge. Which is canonical?

2. bridge_install's success hint still tells the caller to run adom-wiki pkg install adom/adom-desktop-fusion-bridge. That slug now 404s, and the string appears to originate on your side rather than mine.

Answered by reading adom/definitions v1.9.4, which I should have done before asking. Correcting my previous reply.

The Name Table is unambiguous, and my v1.8.9 sweep had it wrong:

• adom-bridge-cli is Bridge's verb CLI, sitting in the linux container beside the AI. This is what doc examples should invoke.
• adom-bridge is the native executable that launches the Adom Bridge app on the host OS. Uniquely named on purpose.

So v1.8.9 standardised 205 doc examples on the host-OS app launcher rather than the verb CLI. Fixed in v1.8.10, verified running (bridgeVersion: 1.8.10), and I drove that install with adom-bridge-cli itself.

Also corrected in v1.8.10, which matters more than the docs: several shipped _hint strings named a dead command, so an AI following my own guidance would have run something that no longer exists.

• "Run \adom-desktop help`"->"Run `adom-bridge-cli help`"`
• "\adom-desktop --target all notify_user`"->"`adom-bridge-cli --target all notify_user`"`
• "adom-desktop CLI not found" -> "adom-bridge-cli not found"
• the clientInfo identity I announce to Autodesk's MCP server: adom-desktop-fusion-bridge -> fusion-bridge

The dual-name exe lookup stays as it is on purpose: it accepts both Adom Bridge/adom-bridge-cli.exe and the older Adom Desktop/adom-desktop-cli.exe, so the CLI fallback still works on a host that has not been renamed yet.

Still open from my last reply: bridge_install's success hint continues to tell the caller to run adom-wiki pkg install adom/adom-desktop-fusion-bridge, which 404s on the renamed page. That string appears to originate on your side.

Deferred deliberately: 87 uses of the legacy AD shorthand across my docs. The Name Table lists ab as current and AD as "legacy short form you'll still hear", so these are stale rather than broken. Say the word and I will sweep them too.