app

Adom Desktop - Fusion 360 Bridge

Public Made by Adom

by adom

Drive Autodesk Fusion 360 from the cloud via Adom Desktop: component libraries, IPC package generation, board layout, exports (STEP/Gerbers/BOM/CPL), fast APS cloud search, and parametric modeling.

fusion360autodeskcadpcbexportsapsmodeling
Overview Files Skills Discover Packages Releases Dependencies Issues4 Breadcrumbs Pull Requests Activity
adom-desktop-fusion-bridge / CHANGELOG_ARCHIVE.md
Download

Changelog archive (1.6.37 and earlier)

Older history for the Adom Desktop Fusion 360 bridge. Recent versions are in the main CHANGELOG.md. Newest-first.

1.6.37 - 2026-07-06

  • fusion_readiness no longer lies ready:true for a stuck/dead Fusion (John caught it). It only checked for the "Signing in" window when the add-in was silent - but a STALE add-in server from a just-killed instance keeps port 8774 answering, so addin_ok went True while the CURRENT Fusion sat stuck on "Signing in", and readiness reported ready. Now the Fusion-process window title is checked WHENEVER running (authoritative: "Signing in" == not ready), and ready additionally requires the add-in to actually RESPOND (a live main thread), not just the process to exist. Added a distinct "running but add-in not responding yet" hint so a half-launched Fusion is never mistaken for ready.
  • Proactive foreground-lock during launch = no more flicker. The reactive minimize-guard alone left a visible flash (window appears, then shrinks). Now the launch raises the Windows foreground-lock timeout so Fusion's splash/main/seat windows are DENIED a foreground grab outright (taskbar flash, not a real steal), restored to the user's original value when the launch window ends.

1.6.36 - 2026-07-06

  • Codified the background-launch rules in the fusion-bridge-dev skill (John's request): the ctypes handle-truncation gotcha (the silent killer behind 1.6.33/1.6.34), how to VERIFY the guard by objective GetWindowPlacement().showCmd == 2 state rather than by eye, and that the guard only fires on a FRESH launch (kill first for a clean background state). Verified live on the laptop: a clean fusion_start leaves Fusion360 showCmd=2 (minimized) - the window never sits in the foreground.

1.6.35 - 2026-07-06

  • Fixed the focus-guard doing NOTHING due to a ctypes handle-truncation bug (the real reason 1.6.33/1.6.34 still let windows steal focus, caught 2026-07-06). user32.GetForegroundWindow() was called with no restype, so ctypes defaulted the returned HWND to c_int and TRUNCATED it to 32 bits on 64-bit Windows - ShowWindowAsync then got a garbage handle and silently no-op'd, so the guard never actually minimized anything and the user had to alt-tab back themselves. Now the guard sets proper restype/argtypes (HWND/DWORD/BOOL) so handles survive, and polls at 0.1s. Family windows that steal focus are now genuinely minimized within ~100ms.

1.6.34 - 2026-07-06

  • Focus-guard now covers the whole Autodesk launch FAMILY (fix for the 1.6.33 guard, caught live). The guard only demoted Fusion360.exe windows, but the splash "Loading additional modules" (FusionLauncher.exe) and the "Signing in" / "Active Sessions Exceeded" dialogs (AdskIdentityManager.exe) slipped past and yanked the user's foreground. Now _fusion_family_pids() matches every family process image and the guard (150s) minimizes any of them that steals focus.
  • Seat conflict ("Active Sessions Exceeded") now AUTO-RECLAIMS the license instead of asking (John: "just grab the license back... no harm, the user can reclaim on the other machine"). The dialog is a CEF modal that ignores background SendInput, so the launch handler frees the seat at the SOURCE via _reclaim_seat_from_peers() (cross-AD fusion_stop to peer ADs), kills the local instance stuck on the dialog, and relaunches clean - no conflict dialog, no user prompt, fully background.

1.6.33 - 2026-07-06

  • Fusion now launches in the BACKGROUND - never steals the user's foreground (John's directive). The bridge runs on a machine the user is actively working on, and a bare Popen([launcher]) opened Fusion's splash + main window in the foreground, yanking focus off their work. Now ensure_fusion_ running() starts the launcher MINIMIZED + NOT ACTIVATED (STARTUPINFO SW_SHOWMINNOACTIVE) and fires a ~120s focus-guard daemon that minimizes (no-activate) only a Fusion window that is currently the foreground (focus-theft detected via GetForegroundWindow + PID match, so it never fights a user who deliberately opened Fusion). The add-in still loads fully while minimized. Foreground is now opt-in, only when a verb's job is to SHOW the user. Codified as a HARD invariant in the fusion-bridge-dev skill so every future window-opening path follows it.

1.6.32 - 2026-07-06

  • Fixed a false positive in 1.6.31's updating detection (caught immediately on a real laptop during a regression pass). Fusion NEVER prunes old webdeploy\production builds, so a normal machine accumulates many stale ones (the laptop had 5, dating back to April, Fusion not even running) - and the bare "2+ builds" heuristic fired permanently, falsely telling callers "Fusion is auto-updating, restarting every 30-60s" when Fusion was simply closed. fusion_update_in_progress() now requires ACTIVE streaming: 2+ launcher builds AND at least one build dir modified in the last ~20 min. Stale leftovers no longer trigger it; the genuine mid-update flap still does.

1.6.31 - 2026-07-05

  • fusion_readiness now reports a distinct updating:true status when Fusion is applying an auto-update. New fusion_update_in_progress() detects the tell-tale TWO+ webdeploy production builds coexisting; while that applies, Fusion crash-restarts itself every ~30-60s, so verbs intermittently saw a bare "not running" that read as a crash. Readiness now flags updating:true with a hint to poll/retry (it stabilizes once the update finishes) rather than treat the flap as fatal. Both hardening items came straight out of the fresh-VM battery.
  • Preference verbs (fusion_set_preference/fusion_get_preferences) retry once on a transient add-in connection error. The first call can hit the add-in mid doc-transition (e.g. right after opening a Library, when the pref script must create a Design) and come back "not running" though Fusion is up; a ~1.5s retry clears it (seen live on the battery - failed first call, passed on retry). A genuinely-down Fusion just costs one extra 1.5s attempt.

1.6.30 - 2026-07-05

  • fusion_install_fusion and fusion_start now live-detect too (completing the 1.6.29 fix). Both still trusted the stale bridge-start fusion_info.installed snapshot: on the fresh VM, fusion_install_fusion REFUSED with "already installed" though disk was NO_WEBDEPLOY, blocking the reinstall, and fusion_start would launch into the void. Both now call detect_fusion() for the on-disk truth; fusion_start also reassigns from it so a launch immediately after a fresh install uses a current exe_path. Found + fixed live during the fresh-VM battery.

1.6.29 - 2026-07-05

  • Fixed fusion_readiness trusting a stale install cache. It read the bridge-START fusion_info.installed snapshot and only re-detected when that was False - so after Fusion was UNINSTALLED (or a VM reset wiped it) while the bridge kept running, readiness still reported installed/running/ready:true on a machine with NO_WEBDEPLOY on disk (found live during a fresh-VM validation on ADOMBASELINE). It now ALWAYS live-detects via detect_fusion() (a fast filesystem scan), so readiness reflects reality whether Fusion was just installed OR just removed.

1.6.28 - 2026-07-05

  • New fusion_set_preference + fusion_get_preferences verbs - drive Fusion's appearance and navigation settings programmatically, applied LIVE (no restart). Server-only orchestrators (they compose an adsk preferences script and run it via the existing add-in run_modeling_script, so no add-in redeploy). Friendly keys: theme (light/darkblue/darkgray/classic/device/dark), invertScrollZoom (mouse scroll/zoom direction), orbitScheme (fusion360/alias/inventor/solidworks/tinkercad/powermill), modelingOrientation (yup/zup), gestureNav, cameraPivot, lengthUnit (mm/cm/m/in/ft, active design). Per-key outcome is reported in applied and the resulting state in current. Discovered via a live introspection of app.preferences.generalPreferences on ADOMBASELINE.
  • Note on theme availability: not every Fusion build ships every theme. On the current webdeploy only LightGray, DarkBlue, Device were available (Dark Gray theme not available / Classic theme not available raise on assignment), so the verb tries candidates and reports per-key failures; dark resolves to Dark Gray then falls back to Dark Blue. Dark mode was set live on the VM's Fusion this way (Dark Blue).

1.6.27 - 2026-07-05

  • Fixed a false-positive in 1.6.26's new needsSignin readiness detection (caught live before release to any consumer). 1.6.26 derived needsSignin from classify_launch_dialogs(), which enumerates ALL top-level windows and so matched a stray Edge browser tab titled "Sign in - Autodesk" - reporting needsSignin:true while Fusion was actually signed in and drivable. Now the detection is scoped to the Fusion-process window (get_fusion_window_info title/mainEnabled) and is only evaluated when the add-in isn't responding (a responding add-in = past sign-in = drivable), so a leftover browser tab can never trigger it. Verified on ADOMBASELINE: signed-in Fusion now reports ready:true.

1.6.26 - 2026-07-05

  • Adopted AD 1.9.84's direct API (disc #78): the bridge now calls notify_user ITSELF, cross-AD. New ad_client.py talks back to AD over $ADOM_DIRECT_API_URL/command with the X-Adom-Bridge-Token attribution header. It capability-probes GET /commands (not hardcoded) so it degrades gracefully on older AD, enumerates peer ADs via targets, and can route any verb to a peer with a cross-AD target. Dropped the old "AD can't notify" workaround (returning a notifyUser payload for the driving AI to relay). On a launch that surfaces a seat/licensing DECISION dialog (a true wall that can suspend/close Fusion on the user's OTHER machine), the bridge now fires notify_user directly with reach_user=True — fanning out to "all" peers when it may be running unattended on a VM, so the toast lands wherever the user is. Response carries notifyDelivered. Sign-in stays automate-first (NOT auto-notified).
  • Fixed fusion_readiness lying ready:true during sign-in. Fusion can be running yet blocked by the first-run Autodesk sign-in modal (main UI disabled, add-in can't serve). Readiness now detects the signin_required window via the launch classifier and returns ready:false + needsSignin:true instead of "READY - drive Fusion" (which sent verbs into a wall). Found live on ADOMBASELINE.
  • Baked the PROVEN sign-in sequence into the needsSignin hint + fusion-onboarding skill (validated live 2026-07-05): clear stale signin.autodesk.com tabs (expired codes = "Sign-in request expired") → "Retry browser sign-in" for one fresh request → click "Open Product" with desktop_click (SendInput=isTrusted), NOT desktop_ui_click (UIA doesn't fire the protocol) → tick "Always allow" + "Open" on the in-page "open Autodesk Identity Manager?" overlay (not an owned popup) → poll readiness. Documents the nbrowser/CDP headless variant and the isTrusted requirement.

1.6.25 - 2026-07-04

  • Sign-in is now AUTOMATED-FIRST, with the path baked into the verb's _hint + a notifyUser payload (John's directive). On needsSignin, fusion_start now tells the AI to: (1) check nbrowser_readiness and drive the Autodesk OAuth via the native-browser extension over CDP when it's on the same browser Fusion opened sign-in in (fast + headless - beats the ~2min request expiry that defeats background desktop_ui_click, the failure seen live on the VM drill); (2) else desktop_ui_click the Sign In / Open Product buttons FAST; (3) ONLY if both fail, relay the new structured notifyUser:{title,body,level} payload to notify_user. The goal is: automate everything, pull the user in (via a toast) only for a true wall - never auto-enter password/2FA.

1.6.24 - 2026-07-04

  • Two more launch dialogs are now classified IN CODE (caught live on the clean-VM drill): "Fusion is already open / Multiple instances are not supported" (category already_open - auto-dismissed via Cancel; a singleton is never double-launched) and the first-run Autodesk "Welcome to Fusion / Signing in" window (category signin_required - SURFACED, never auto-closed, with a _hint to notify + drive Sign In / Open Product without touching credentials). Added an explicit AUTO_DISMISS_CATEGORIES set so only benign acks get WM_CLOSE'd; decisions + sign-in are returned as needsUserDecision/needsSignin. Fixes a latent bug where sign-in would have been auto-closed.

1.6.23 - 2026-07-04

  • NEW fusion_install_fusion - install Fusion for the user with ZERO approval-gated shell. The clean-VM drill showed every shell_execute step (download/spawn/tasklist) hits AD's "approve 1 hr" gate; bridge verbs run as trusted installed code and don't. The verb downloads Autodesk's official Client Downloader inside the bridge (urllib), is ELEVATION-AWARE (--globalinstall when admin, PER-USER otherwise - a non-elevated globalinstall dies silently on UAC, learned live), spawns it detached, and returns promptly. fusion_readiness now live-redetects and reports installing:true while the streamer runs. Declared as detect.installVerb (AD >=1.9.79) + in hostAppOptionalVerbs so it forwards on a Fusion-less box - completing the contract slot left empty in 1.6.22.

1.6.22 - 2026-07-04

  • Adopted AD 1.9.79's two new GENERIC bridge contracts (previously Fusion-specific AD-core code): (1) detect gains hostAppOptionalVerbs (readiness/describe/get_app_state/status + the APS verbs - all answer without Fusion running; AD now detects only INSTALLED, this bridge owns RUNNING and fast-fails fusion_not_running pre-add-in, no hang); (2) NEW timeouts block - per-verb HTTP budgets are now bridge-owned (AD's fallbacks + tuned values: build_library_3d 1800s, capture_library_views 600s, make_3d_package 200s, run_modeling_script 180s, generate_package 120s; open* prefix 150s). Timeouts stay NON-terminal ({stillRunning, statusVerb}). Docs note AD's not-installed errorCode is now generic host_app_not_installed (+hostApp field).

1.6.21 - 2026-07-04

  • Docs/skills audit (all three tiers). USER skill: fusion_generate_package added to the core verbs table + a bridge_restarting cold-start row (AD >=1.9.77: poll fusion_readiness, never a not-installed signal; read-only verbs forward mid-respawn). DEV skill: deploy section rewritten for the FusionAddins reality (install to ALL dirs, never-ask-user-to-restart). README fully overhauled: 11 capability sections incl. EPG package generation + markings, the architecture SVG, and the parent/child dialog breakthrough.

1.6.20 - 2026-07-04

  • The 10% marking margin is now ENFORCED by measurement, not estimated. Fusion's text font runs wider than the 0.75h glyph estimate ('ADOM-A' rendered edge-to-edge - John caught it), so after placing the text the verb measures its REAL sketch bbox and shrink-to-fits if it busts the margin box (both axes; up to 2 passes). The manifest records textWidthMeasuredMm + fitIterations.

1.6.19 - 2026-07-04

  • Markings run along the LONGEST axis of the top face (auto-rotated 90 deg when the long axis is sketch-y) - maximum room for the text (John's rule). Multi-line markings work: newline-joined text (MPN + variant) with per-line auto-fit (h = min(boxH/(1.35lines), boxW/(0.75maxChars))).
  • Sidecar manifest for marking refreshes: with outputStep, <step>.manifest.json records every setting picked + WHY + the calculated bboxes (chip bbox, top-5% band, face extents, text box, height, rotation). To refresh a marking (e.g. add a variant on line 2), re-call the verb with the manifest's type + paramsCm (unitsCm:true) + the new etch text - deterministic generation reproduces placement exactly. Manifest also returned inline; _hint teaches the whole workflow.

1.6.18 - 2026-07-04

  • Chip markings are now READABLE: raised WHITE text by default (John's spec). Humans need contrast - a dark-on-dark emboss is invisible - so fusion_generate_package now marks chips with a thin POSITIVE extrude painted white (silkscreen-style, via EPG's own rgb-appearance utility; white survives into the colored STEP). etchStyle:"engraved" keeps the sunken laser cut.
  • Top-surface finding is now the bbox-band algorithm (in CODE, not just the skill): whole-chip bounding box -> only upward planar faces in the TOP 5% height band -> largest area wins -> text laid out with a 10% margin inside that face. The verb's _hint teaches all of this + per-family param names on every call; the fusion-build-parts-library skill gained a "creating chips" section.

1.6.16 - 2026-07-04

  • (1.6.17) Etch auto-fit measures the face in SKETCH space (model-bbox axes can be swapped vs the text's baseline axis) + a 0.75h glyph width - 'LM358' now fits fully on a SOIC-8 top.
  • fusion_generate_package etch auto-fit is now WIDTH-aware: text height is capped by box-width / char-count (a glyph is ~0.62h wide), so a 5-char MPN like 'LM358' fits instead of cropping (height-only fit rendered 'M35' on a SOIC-8 - caught on the live verify).

1.6.15 - 2026-07-03

  • NEW fusion_generate_package - parametric IPC packages from Fusion's BUILT-IN ElectronicsPackageGenerator, with laser-etched markings, in one headless call. Give it a type (~50 EPG families: chip/soic/qfn/qfp/bga/sot23/dfn/melf/ecap/crystal/headers/...) + params (mm, auto-converted to EPG's cm) and it drives EPG's generator modules directly (no GUI), optionally laser-etches a marking (etch:"103" / an MPN) into the body top as REAL cut geometry, and exports STEP (outputStep) - the etch survives into the STEP for KiCad. Proven live on a fresh VM: 0603 + '103' etch + valid 233KB STEP (121 faces) in ~2s. EPG is located dynamically across webdeploy hashes + install roots (never hardcoded); missing EPG returns errorCode:epg_not_found. Etch targets the LARGEST body's top face (terminals tie the molded body on max-Z - learned live). This is the royalty-free path to whole component libraries: our own generated output, not license-restricted vendor models.

1.6.14 - 2026-07-03

  • #63 ROOT-CAUSED + FIXED: Fusion MOVED its add-in directory; we now install to ALL of them. 2025+ Fusion scans %APPDATA%\Autodesk\FusionAddins\ and SILENTLY ignores the legacy Autodesk Fusion[ 360]\API\AddIns\ dirs (proven live on a fresh install: add-in in the legacy dir never loaded through a full launch; moved to FusionAddins it came up in 20s, runOnStartup honored, zero manual enabling). install_addin.py now installs/uninstalls to EVERY known location (TARGET_CANDIDATES, newest first), fusion_detect scans all of them, and the add-in-not-responding errors carry the FusionAddins explanation + a stable errorCode.
  • ⛔ NEVER ask the user to restart Fusion / enable the add-in - baked into code + skills. Every hint that said "restart Fusion 360" / "enable via UTILITIES > ADD-INS" now instructs the AI to DO IT ITSELF (fusion_stop + fusion_start); the USER skill (convention 6), fusion-onboarding, and CLAUDE.md all carry the rule. Doing the work for the user is the point of the bridge.

1.6.13 - 2026-07-03

  • bridge.json dependencies described honestly. Dropped fusion360: ">=2.0.0" - Fusion 360 is the HOST APP (already declared in the detect block, and it uses date/webdeploy versions, not a ">=2.0.0" semver), not a package dependency. Corrected the stale python: ">=3.11" to >=3.10 (the real floor - the code uses 3.10 X | None unions; AD provisions + pins Python 3.12.13). The user-facing wiki Dependencies tab stays empty, which is correct: this bridge has no external wiki-package deps (the add-in is bundled, the APS layer is in-repo).

1.6.12 - 2026-07-03

  • Launch now WATCHES for licensing/launch dialogs in CODE (not just a skill), found live on the ADOMBASELINE first-run test. _handle_launch enumerates ALL top-level windows the instant the Fusion process is up and classifies the dialogs that block a first launch but are owned by the Autodesk FAMILY (AdskIdentityManager / FusionLauncher), so the Fusion-scoped classifier misses them: "Active Sessions Exceeded" + "Suspend Remote Session" (seat conflict) and "Error Launching Streamed Application / missing or incomplete / re-install" (an incomplete webdeploy folder). Benign launch-error acks are auto-dismissed (WM_CLOSE, background). A seat-conflict is a DECISION dialog: the bridge returns needsUserDecision:true + setupDialogs[] + a _hint that says fire a notify_user and ASK the user which option to take (the options suspend/shut-down Fusion on their OTHER machine) - it NEVER auto-picks. New helpers in dialog_classify.py: classify_launch_dialogs, close_dialog_bg, DECISION_CATEGORIES.

1.6.11 - 2026-07-03

  • Detect a system-wide (--globalinstall) Fusion, not just per-user (fixes a broken onboarding loop, found on the ADOMBASELINE fresh-VM test). The fusion-onboarding skill installs Fusion with --globalinstall, which lands the launcher under %ProgramFiles%\Autodesk\webdeploy\production\, but detection (both fusion_detect.py and the bridge.json detect block) only checked %LOCALAPPDATA%. So an AI-installed Fusion was INVISIBLE - onboarding "succeeded" yet the bridge + AD bridge_readiness still reported no-app. Detection now scans %LOCALAPPDATA%, %ProgramFiles%, %ProgramFiles(x86)% (and %ProgramW6432%), preferring a complete install (has .ini) + newest.
  • Notify the user on EVERY active step. Per the "the AI does everything, but pull the user in when only they can act" rule: the USER skill's convention 4 and fusion-onboarding now mandate an AD notify_user toast the instant the user must do something (Autodesk sign-in, 2FA, a UAC/elevation prompt, license acceptance), and a progress toast for long installs - never silently wait on a screen they aren't watching.

1.6.10 - 2026-07-03

  • "Fusion not installed" hints now honor the SDK Tier-2 cardinal rule (found on a fresh-AD test). Testing a first-time run on a clean AD 1.9.74 VM (ADOMBASELINE, no Fusion) showed the bridge's not-installed hints said "Fusion cannot be installed programmatically... ask the user to install it from autodesk.com... then retry" - a breach of the rule that the AI must OFFER to install the host app itself and NEVER tell the user to do it manually. All 4 not-installed hints (+ the /status tooltip) now offer AI-driven install via the fusion-onboarding skill (silent-install + Autodesk sign-in). Note: the correct probe for a "what EDA tools are installed" sweep is AD's bridge_readiness (side-effect-free aggregate with edaToolsInstalled + per-bridge state:no-app); verified it reports Fusion cleanly on the fresh VM via this bridge's detect block.

1.6.9 - 2026-06-30

  • fusion_start no longer dead-ends on a slow first launch (fixes #63, Arav's blocker 1). A first launch (fresh install: component downloads/updates/cloud sync) can take 2-4 min, far past AD's ~60s relay request cap - so {"timeout":300} could never win and the call looked like a hard failure. Now the launch confirms the Fusion process, then waits for the add-in only within a budget that stays UNDER the relay cap; if the add-in isn't up yet it returns {success:true, stillLaunching:true, statusVerb:"fusion_readiness"} with a _hint to POLL fusion_readiness until ready:true (never re-call fusion_start). Fast/normal launches still return "launched successfully" as before. The USER-skill cold-start table gained a stillLaunching row.

1.6.8 - 2026-06-30

  • Stale add-in is no longer a SILENT failure (fixes #55, Drew's report). The add-in now REPORTS its version (AdomBridge.manifest → /health + /status), and the bridge compares it to the version it bundles. fusion_readiness and fusion_addin_status now return addinVersion / expectedAddinVersion / addinStale (+ a re-sync _hint), and any add-in command the running add-in is too old to know (e.g. open_by_urn, which silently broke fusion_aps_open for Drew) now comes back with errorCode:"addin_stale" and the exact fix (fusion_stop then fusion_start to re-sync from cache with Fusion closed). Add-in manifest bumped 1.0.2 → 1.0.3.
  • Bridge-SDK re-audit against the updated SDK. (1) bridge.json verbs[] re-synced to the authoritative fusion_describe catalog (was stale: 40 → 53 verbs; added the library/3D + board + app-state verbs; statusVerb fusion_get_app_state is now listed; dropped the dead fusion_apply_instapcb_rules). (2) The USER skill's cold-start section now encodes all 8 SDK conventions (was 5), led by an errorCode response→meaning→action table (incl. the new addin_stale row) and the reuse-don't-relaunch + surface-_hint-verbatim conventions.

1.6.7 - 2026-06-30

  • AD 1.9.63 alignment (discussion #57). (1) The bridge HTTP server now honors ADOM_BIND_HOST (os.environ.get("ADOM_BIND_HOST", "127.0.0.1")) instead of a hardcoded host, so it never binds a public interface and never trips the Windows Firewall "allow access?" prompt AD guarantees users won't see. (2) Docs/skills updated to the new runtime-provisioning reality: AD provisions Python itself (system if on PATH, else a portable no-UAC python-build-standalone copy pinned to 3.12.13, spawned by absolute path) - the bridge must never bootstrap/download its own Python; state is checkable via AD's new runtimes verb. No self-bootstrap code existed to remove; only the "auto-installs Python" wording in SKILL.md / fusion-onboarding / CLAUDE.md was corrected.

1.6.6 - 2026-06-30

  • Bridge-SDK self-audit pass. bridge.json: homepage now points to the wiki page (was github - a stale default); removed the redundant top-level healthEndpoint (it lives inside spawn); added spawn.persistent + an explicit prewarm: {assets: []} (Fusion is a detected HOST APP + AD auto-installs Python, so nothing to prewarm). discovery_triggers rewritten to 16 everyday user-task phrasings (dropped verb-name/internal jargon) + a discovery_pitch. The USER skill now opens with a cold-start "read before you panic" + fusion_readiness pointer. fusion-bridge-dev (a dev skill) is no longer shipped in the user skills pkg (source-only).

1.6.5 - 2026-06-30

  • Host-app DETECTION declared (AD >=1.9.47). bridge.json gains a detect block (hostApp: "Fusion 360", Windows %LOCALAPPDATA%\Autodesk\webdeploy\production\*\FusionLauncher.exe mirroring fusion_detect.py, macOS /Applications/Autodesk Fusion[ 360].app) so AD DETECTS Fusion (the user's host app) instead of trying to install it. The status path fast-fails cleanly when Fusion isn't running.
  • NEW fusion_readiness verb - a fast {installed, running, ready, hostApp, bridgeVersion} check that never launches Fusion; the fusion-onboarding skill now opens with it (and AD's bridge_readiness). CLAUDE.md notes AD now auto-installs Python in the background, so the deploy trap's spawn case is handled by AD.

1.6.4 - 2026-06-29

  • Folder hygiene, part 2: make_3d_package no longer saveAs-es to the project ROOT either. v1.6.3 fixed the upload target but the f3d saveAs still landed in the shared root - now it saves into Adom AI Workspace/<task> (found/created in the active project), so a build leaves ZERO loose files in root.
  • Dialogs are dismissed in the BACKGROUND now (no focus steal). New _dismiss_dialogs_bg uses close_window (WM_CLOSE via PostMessage = Cancel/No), NEVER send_key/Escape (which calls SetForegroundWindow and yanks Fusion to the foreground). fusion_capture_library_views now auto-dismisses the "Create new symbol/footprint ''?" prompt that pops when a DEVICESET name is passed to .sym/.pac in a shared-footprint library (the symbol/package is named by the combo, e.g. R-0603, not R-0603-10K) - and its _hint + the fusion-driving skill now teach the right names
    • the background-dismiss rule.

1.6.3 - 2026-06-29

  • Cloud folder hygiene - the bridge NEVER writes loose files to a project ROOT anymore. Root cause of a real incident: fusion_make_3d_package defaulted its upload to the shared Adom project ROOT, so a big build dumped 100+ loose f3d files into the team's root and colleagues complained. Now uploads default to an AI-owned Adom AI Workspace folder with a per-task subfolder (build_library_3d derives the task from the .lbr name), and fusion_aps_upload REFUSES a known root folderId (errorCode: refused_root_upload). New fusion-cloud-hygiene skill.
  • NEW fusion_cleanup_cloud_files - precisely delete a list of cloud files by lineage urn (not by name), so cleaning up AI clutter can't touch a teammate's file in a shared folder. The add-in delete gained a fileId/lineageUrn exact-match path.

1.6.2 - 2026-06-29

  • fusion_capture_library_views settle fix. It fired the screenshot ~0.4s after EDIT, before the editor actually switched - so a shot could capture the PREVIOUS part (a mislabeled view). Now it waits a tunable settle (default 1.5s) after each EDIT before framing + capturing, so the shot matches its label.
  • Skill: the SHARED-FOOTPRINT pattern for whole-catalog libraries. fusion-multipart-libraries now documents how a 138-part library is really 10 footprints + 138 devicesets: collapse the catalog to its unique (type, package) combos, fusion_build_library_3d the ~10 bases (10 uploads, not 138), then clone each base deviceset per value (sharing its symbol + package + 3D binding). Proven by building the entire Adom basic parts library (138 parts, all Mapped + rendering).

1.6.1 - 2026-06-29

  • NEW fusion_capture_library_views - the views EEs actually trust. Given a list of packages (and the .lbr open), it runs EDIT <deviceset>.sym/.pac/.dev + WINDOW FIT + a background screenshot and returns, per part: the SYMBOL (full pinout), the FOOTPRINT (pad array + Copper/Silkscreen/Mask layer stack), and the COMPONENT view (Content Manager: symbol + the package table with the footprint<->package Mapped ✓ + pin/pad counts). The 3D before/after shots never showed these.
  • _inject_package3d_bindings is now MERGE-AWARE + idempotent. It reads bindings already in the .lbr and accumulates the new ones (new wins), so re-running fusion_build_library_3d for just the parts that failed NO LONGER wipes the parts that already succeeded (the "a subset re-run dropped my earlier bindings" trap). fusion_build_library_3d now reads its own outLbrPath when re-run, each part self-retries once on a transient first-part failure, and its _hint documents the relay-timeout reality (a many-part run exceeds the ~60s relay request timeout but keeps running server-side - verify by the bound .lbr + the PNGs, then re-run any missing parts).

1.6.0 - 2026-06-29

  • NEW fusion_build_library_3d - build a whole RENDERING multi-part 3D library in ONE call. Give it the combined .lbr + a parts[] list ({package, lbrPath, modelPath}); for each part it makes the footprint+chip f3d package (no GUI dialogs), collects the wip_urn, then injects ALL bindings in one pass (_inject_package3d_bindings - the EAGLE <packages3d> + per-device <package3dinstances> surgery the AI used to hand-write) and opens the finished library once. Returns per-part urns + a screenshots[] of every before/after. Each part is independent, so a Fusion reset mid-run just means re-running the failed parts.
  • fusion_make_3d_package got two upgrades: (1) projectId/folderId are now optional - they default to the MAIN-project upload folder (_discover_upload_target), so the AI no longer has to fusion_aps_browse for them; (2) pass captureLabel to auto-capture a BEFORE (the footprint in the 3D viewer) and AFTER (the chip placed flat on its pads) hwnd-targeted background screenshot, returned as before/after. A viewport fit() frames each shot.
  • Both verbs added to fusion_describe (the Verbs tab) and gated as Fusion-required.

1.5.13 - 2026-06-29

  • Rich teaching hints on fusion_make_3d_package: its _hint now spells out NEXT step (the exact binding markup), what to EXPECT (check_dialogs==0, footprint+chip preview, pad alignment), the SPEEDUP (batch per part -> hand-merge all -> open once), and the PITFALLS (needs Fusion running; a raw STEP renders nothing; never FINISH the Package3D generator). Skill gained a matching "Speedups + what to expect" section.

1.5.12 - 2026-06-29

  • fusion_make_3d_package now produces a PROPER component package (footprint + chip). It opens the lbr and runs Electron.Create3DPackage to load the package's FOOTPRINT into the generator, imports the chip ONTO it, orients flat, and saveAs an f3d - so the 3D model contains the footprint (pads + courtyard) AND the chip, merged and aligned (the chip's pads land on the footprint pads in the 3D viewer, which is the whole point of that viewer). The 1.5.11 verb imported into an empty Design, giving a chip with NO footprint. New required arg: lbrPath. Proven on the full 10-part library (AdomBasicParts3D_v2).
  • fusion-multipart-libraries skill updated to the footprint-aware recipe.

1.5.11 - 2026-06-29

  • NEW fusion_make_3d_package verb - a RENDERING per-package 3D model with ZERO GUI dialogs. It imports a STEP into a throwaway Design, orients it flat, saves an .f3d, uploads it via APS, and returns a fs.file:vf wip_urn to hand-write into a library's <packages3d>. This is the dialog-free replacement for the Create3DPackage generator (whose FINISH is trapped behind two unbeatable "Fusion360" CEF modals). Proven on a full 10-part Adom basic-parts library (R/C/L/LED/nRF54L15) - every package renders its real chip, flat on its footprint.
  • fusion-multipart-libraries skill rewritten as SOLVED - the f3d recipe end to end + the key gotcha (a raw STEP upload binds but does NOT render: "Thumbnail download failed"; an f3d renders)
    • the GUI-generator dead end to avoid.
  • New skills fusion-driving (read the dialog/owned-popup array after every mutating op; never fullscreen-capture) and fusion-cloud-save (Hub-upload / saveAs discipline); fusion-libraries cross-linked to both.
  • README + SKILL now link the component-library docs (the skills + CREATING_BASIC_PARTS_LIBRARIES.md).

1.5.10 - 2026-06-29

  • Dialog-capture false-positive fix: a docked panel (Browser/Timeline) shares the "Fusion360" title but does NOT disable the main window, so a generic-titled candidate is now only surfaced when the main window is actually disabled (a real modal is up). Stops the auto dialog-capture crying wolf.

1.5.9 - 2026-06-28

  • Auto dialog-array capture after every mutating fusion_* verb: enumerates + screenshots any owned popup / modal by hwnd (background, never fullscreen) and returns it plus an "analyze this before proceeding" hint, so the AI cannot fly blind past a Save / "are you sure you want to close" / recovery dialog.
  • NEW fusion_check_dialogs verb - poll the current dialog/owned-popup array on demand.
  • Dialog classifier: new rules for the Hub upload-in-progress ("packages are being uploaded... lose these changes") and "save was cancelled / cannot be saved while packages are being uploaded" modals; the generic/unknown fallback no longer says "dismiss" (which could click Yes on a data-loss confirm).

1.5.8 - 2026-06-28

  • bridge.json: added updateManifestUrl (+ healthEndpoint) so Adom Desktop auto-update works (it was null, which broke auto-update - discussion #31).

1.5.7 and earlier

  • fusion_attach_3d_package (GUI Package3D generator flow - superseded for multi-part work by fusion_make_3d_package), APS fast cloud search, the Electronics workflow verbs, and exports. See the git history on the wiki page.