Adom Bridge

Logged live 2026-06-27 while driving the Fusion bridge through a real PCB end to end. Three related asks. #1 and #2 are prototyped and proven live locally; #3 is the deploy bug that blocked them. Full write-ups are staged in the project repo (adom-desktop-fusion-open-hierarchy-feedback.md, adom-desktop-fusion-aps-feedback.md).

1. Open verbs must teach the electronics file hierarchy (+ reprimand)

A Fusion electronics design is a parent/child chain of separate files, each a distinct productType — not one file:

PROJECT        EcadDesignProductType   <- the ONLY file to open directly
  |- schematic   SchematicProductType
  |- board/.brd  BoardProductType
  |- 3D PCB      DesignProductType      (generated FROM the .brd - the LEAF)

Opening a schematic / .brd / 3D directly gives an isolated/empty view, and you cannot derive the board from the 3D (it's the leaf). Nothing in the skill or the verbs taught this, so the AI kept opening the wrong file and burned a lot of the user's time.

Ask: in handle_open_cloud_file + handle_open_by_urn (commands/cloud_documents.py), after the open read app.activeProduct.productType and return a reprimand in the response _hint when it is NOT EcadDesignProductType. Proven live:

Helper _ecad_open_reprimand(app) + a two-line injection at each success return; diff available on request. Also add the hierarchy section to the bridge SKILL.md (done locally).

2. (THE BLOCKER) Cache edits never reach the running add-in

The add-in source lives at ...\Adom Desktop\bridges-cache\fusion360\addin\AdomBridge\, but Fusion **loads** the add-in from %APPDATA%\Roaming\Autodesk\Autodesk Fusion 360\API\AddIns\AdomBridge\. fusion_close + fusion_start does NOT redeploy cache → AddIns, and the two copies had already diverged. Editing the documented source silently does nothing — I had to patch the Roaming copy directly to make the change live. An AI or bridge author editing the source has zero effect, with no warning.

Ask: redeploy cache → AddIns on bridge/Fusion start (with a version check), OR load the add-in directly from the cache, OR add a fusion_reload_addin verb so a code change can go live without a full Fusion restart.

3. APS / cloud search

• bare aps_status is a trap. It's a core-CLI handler (port 8910) that shadows the bridge's APS and always reports configured:false — yet its own catalog text says "call this FIRST to decide between aps_search and fusion_search_cloud_files." So it steers AIs to the slow fallback even when fusion_aps_status reports configured:true, signedIn:true. Make it reflect the real bridge config, or remove it.
• fusion_search_cloud_files / fusion_walk_cloud_tree HARD-CRASH Fusion. Not just slow — a recursive call forcibly closes the add-in (WinError 10054) and takes Fusion down; observed 3x in one session. Their hints should warn about the crash; better, steer to fusion_aps_search.
• fusion_open_cloud_file only matches at the project root (can't reach nested files), and APS search results don't round-trip a folder path, so there's no clean "open this APS hit" path (fusion_open_by_urn_note points at the real verb but the gap remains).

Please reply with which asks you'll take, target AD version, and whether the DesignProductType reprimand should be hard or softer (to avoid false positives on pure-mechanical 3D designs with no PCB).