app

SOLIDWORKS Bridge

Public Made by Adom

by adom

Launch, model and quit SOLIDWORKS from any Adom container. Nothing is ever lost.

solidworksmcadcadbombridgeabadom-bridgedesktop-app
Overview Files Skills Discover Packages Releases Dependencies Issues2 Breadcrumbs Pull Requests Activity
main
solidworks-bridge / FUSION-PARITY-REPORT.md
History Download
Drew Owens v0.3.1: manifest, README, skill, ecosystem table, parity report c6f5a2a 1mo ago

SOLIDWORKS ↔ Fusion 360 bridge — parity report

swx v0.3.0 vs the Adom Fusion 360 bridge v1.9.341 · written 2026-09-02

Drew asked for three things: open an existing file, create a new one, and "learn EVERY capability of the Fusion bridge, build a SW alternative for all of them, and tell me what is lacking when done." This is the third part. Every one of the 133 entries in the Fusion bridge's describe.py catalog (132 real verbs plus one documentation pseudo-entry, fusion_open_by_urn_note, which fusion_describe filters out) is below with a verdict. Nothing is claimed that was not observed — and the grading distinguishes "the verb ran" from "the COM call underneath it ran", because on this build those are very different things.

The scoreboard

Verdict Count Means
✅ built, live-proven 19 The SOLIDWORKS verb itself was RUN against the user's live install and did what it claims.
🔬 primitive proven live; verb never run 1 The COM call underneath was executed live and returned what the code expects — but the verb itself has not run.
🧩 built, no COM involved 6 Built and mock-tested, and makes no COM call at all — there is nothing a live SOLIDWORKS could add.
⚠️ built, mock-only 10 Shipped and mock-tested; not executed live in any form.
🔄 adapted 5 Built, deliberately different — the Fusion design does not transfer. Each says why.
⛔ refused by SOLIDWORKS 1 Attempted live; SOLIDWORKS itself refuses it on this edition.
🚫 declined by design 2 Buildable; not built, as a decision about etiquette rather than an absence of API.
❌ lacking 38 Would make sense; not built. Each says what it would take.
➖ not applicable 51 Fusion Electronics, EAGLE libraries, Autodesk MCP/installer — no SOLIDWORKS concept to bridge to.

The SOLIDWORKS bridge ships 60 verbs. The Fusion bridge advertises 57 in its bridge.json; its describe.py catalog contains 133 entries, of which 132 are real verbs — the odd one out is fusion_open_by_urn_note, a documentation pseudo-entry that fusion_describe filters out of its own output. Both numbers are below, and describe.py is the exact source. The gap is almost entirely Fusion Electronics: schematics, PCBs, EAGLE .lbr libraries, Gerbers, 3D packages — 60+ verbs of an application SOLIDWORKS simply is not.

The ✅ column now means what it says. After three live runs against Drew's SOLIDWORKS Design Professional for Makers 2026 — 22-and-aborted, then 120/9, then 125 passed / 5 failed — nineteen verbs have been executed end to end on real hardware, including the whole create → model → inspect → export flow this bridge exists for. What remains ⚠️ is genuinely untested: the assembly verbs (no assembly with components could be built on this edition), swx_stop/swx_kill (deliberately never run against a live session), and the ab-delegated window and dialog verbs (the dev bridge was launched by hand, so it never inherited ab's direct-API environment — those are reported as SKIPPED, not passed).

Live-run status — read this before trusting a ✅

🔬 means: the exact COM call was executed against the user's live SOLIDWORKS Design Professional for Makers 2026 (3DEXPERIENCE R2026x, sldworks.exe 34.3.0) during this build, through the v0.2 bridge's swx_com_eval escape hatch, and returned what the v0.3 code expects. That is how all four v0.2 bugs below were found. It is real evidence, and it is not the same as the verb having run.

✅ is reserved for the handful of verbs whose v0.3 code path was itself exercised live — which today means the v0.2 verbs that ran during the probe session and are unchanged.

This has now happened. Three live runs (2026-09-03) drove the v0.3 binary against the real application. What follows is the record of the first attempt, kept because it is where the edition-launch constraint was found:

  1. Closing a stuck SOLIDWORKS modal (one my own export probe had raised) took SOLIDWORKS down with it. No documents were open and nothing was lost.
  2. Attempting to restart it exposed the launch constraint below; the resulting refused instance was identified by pid and removed, clearing the modal from the user's screen. Shortly after, the desktop disconnected from the ab relay entirely.

tools/live-smoke.py is the suite that closes this gap. It builds a real solid, reads the geometry back, exports eight formats, checks the bytes on disk, and asserts SOLIDWORKS ends with exactly the documents it started with. Run it once the desktop is back and SOLIDWORKS has been started from the 3DEXPERIENCE Platform:

python3 tools/live-smoke.py

The four v0.2 bugs the live probes found

All four shipped in v0.2 and all four were invisible to 49 passing mock tests. This is the argument for live validation, stated as evidence rather than as a principle.

One caveat that applies to two of these. The live byte counts quoted below (a 15,836-byte STEP, a 22,304-byte IGES) came from probes using Silent ALONE — which is precisely how the rename bug was found. The shipped fix uses Silent|Copy, and no export has ever run with those options; it is also unknown whether Copy mode is valid for PDF/PNG/JPG/TIF. So bugs #1 and #2 are DIAGNOSED with live evidence and FIXED on reasoning, not fixed-and-verified. tools/live-smoke.py asserts saveErrorCode==0, documentRenamed==false and an unchanged document title for every format, which is what will settle it.

# Bug Symptom Fix
1 SaveAs3 returns swFileSaveError_e (a long, 0 = success), not a bool Every successful export reported success:false while writing perfectly good bytes. Probes wrote a 15,836-byte STEP and a 22,304-byte IGES that the bridge called failures. Read the return as an error code; decode the bit flags into English.
2 Exports used swSaveAsOptions_Silent (1) alone Silent renames the open document: the user's bracket.sldprt silently became bracket.step in memory. Observed live — a scratch part came back titled probe.SLDPRT after an export. Exports now pass Silent|Copy (3) and the verb asserts the title survived (documentRenamed). Only a deliberate swx_save_as uses plain Silent.
3 InterferenceDetectionManager was looked for on ModelDocExtension It is a member of IAssemblyDoc. Every interference check failed with "unavailable". $doc.InterferenceDetectionManager() — confirmed live to return the object.
4 Feature::GetErrorCode2(bool, byref BSTR) Uncallable late-bound on this build at any arity, so the feature walk hit its error branch for every feature: an empty assembly reported 16 "errors". GetErrorCode() (no arguments) — confirmed live to return 0 — plus Extension.GetWhatsWrongCount() as a cross-check.

What five rounds of adversarial review found — and the design change that ended it

Worth stating plainly, because it calibrates everything above: the safety guarantees this bridge advertises were each wrong at least once, and were caught by review rather than by the test suite.

Round Found Severity
1 VARIANT double-free — every BSTR/IDispatch argument freed twice (heap corruption on the first real swx_open) Critical
2 The VRML block tested the format argument; SaveAs3 keys off the destination EXTENSION, so the per-format aliases could never trigger it. swx_run_script silently built geometry into the user's open document. The DSL's save_as bypassed path validation and renamed in place. Dialogs were closed without proving they belonged to SOLIDWORKS. 3 Critical, 2 High
3 targetDocument authorized one document and the bridge mutated another — the gate resolved ownership from it, but only one verb forwarded it, so the com host fell back to ActiveDoc and swx_save_as renamed and relocated the user's part. Ownership also failed OPEN on title reuse (SOLIDWORKS restarts its Part1 numbering every session). swx_open and swx_com_eval were unguarded roads to the same COM calls. 2 Critical, 4 High
4 A title is not an identity. Ownership was (title, session) and the host preferred the title over the path — so with the user's C:\users\thing.sldprt and the bridge's C:\bridge\thing.sldprt both open, a save_as authorized against the bridge's copy renamed the USER's, with no confirmation. swx_close_doc turned out to resolve no target at all and discarded their dirty document. 2 Critical
5 swx_close_doc {save:true} was an ungated Save3 — the same call the gated swx_save makes — which chained with the deliberately-ungated swx_props_set to write bridge-authored data into the user's file. And save_as/export/pack_and_go had no overwrite protection at all, silently destroying existing files; the modelling DSL had shipped that exact guard, in one of four places. 2 Critical, 4 High

Every one of those defects is in one surface: the bridge writing to something the user owns, through a route whose guard had been forgotten. Every one was a guard that existed and could be walked around, never a guard nobody had thought of — and three times the fix itself introduced the next one.

The design change

After five rounds, gating routes was abandoned as a strategy, because there is always another route. Writes are now DENY-BY-DEFAULT at a single choke point (src/writes.rs). save, save_as, all ten export aliases, bom {format:"csv"}, pack_and_go, close_doc, props_set, set_parameter, set_preference, run_script, rebuild_check, stop and close_all_documents all pass through one function that refuses unless both:

  1. the document is one this bridge created, in this SOLIDWORKS session, and
  2. the destination path does not already exist.

The only way past is an opt-in a caller cannot grant itself: the process must be started with SWX_ALLOW_USER_WRITES=1 and the call must carry allowUserWrites:true, confirm:true and a reason. Every granted exception is recorded in swx_action_ledger, and swx_status / swx_describe report userWrites.

Crucially the com host enforces the same two rules independently, on its dispatch loop — it keeps its own record of the documents it created, reads the opt-in from the environment it inherited, and refuses any command not on its read-only list. Rounds 3, 5 and 6 all turned on that split; round 6 found the first version of the host veto covering a remembered list of seven commands, so a forged run_script sketched and extruded into the user's document while a forged save was correctly vetoed. Keying off what is SAFE rather than what is dangerous makes a new command deny-by-default.

What the default posture still does, fully: read and inspect everything, create documents, model in them, and export to paths that do not exist yet. What it cannot do is touch data the user already had. That is the trade this bridge should have started with, and it is the honest answer to a defect class that survived four separate attempts to fix it one route at a time.

An eighth round found swx_close_window closing the user's "Save changes?" modal in the default posture — the one verb among the session-enders with neither the choke point nor the neverAutoAnswer refusal its own sibling had, and advertised as closable:true by swx_window_info. Alongside it: is_frame_window exempted an EMPTY window class (inverting its own fail-safe), swx_open {readOnly:false} took a write lock on the user's file ungated, and swx_screenshot forwarded a free-text title to ab so it would capture any window on the desktop.

A seventh round found the write surface verifiably closed — every mutating command forged over raw stdio was refused by the host's own veto — and the remaining hole in the half of the bridge that never speaks to the com host: swx_kill force-killed SOLIDWORKS in the default posture on gates it could write for itself, and swx_close_window would close the application FRAME, because ownerConfirmed is true precisely when a window is most provably SOLIDWORKS' and the main window is the most provable there is. Both now go through the choke point; a frame is refused outright.

A sixth round found the design was right but incompletely applied: authorize was wired into seven verbs while swx_bom {format:"csv"} (a SERVER-side std::fs::write that overwrote an existing file and reported success), swx_props_set and swx_rebuild_check wrote around it, and the host's veto covered a remembered list rather than everything. All are fixed, with one regression test per route.

None of this replaces running tools/live-smoke.py. "The author says it is safe" has been the weakest evidence in this project five times running.

What the three live runs proved

Run Result What it established
1 22 passed, aborted The safety machinery works on real hardware: Drew's own Part1 was open, the suite created its own document, never touched his, aborted on the first failure, removed every file it wrote, and swx_reset_workspace reported his document skipped: "not created by this bridge in this SOLIDWORKS session". Also confirmed the Connected edition cannot be launched programmatically. Found: an unsaved document was unaddressable by every verb.
2 120 passed, 9 failed The create → model → export flow ran end to end. A 50×30×20 mm solid built and read back at 30000 mm³; material set and mass agreeing (aluminium, 81 g); a dimension driven to 25 mm with the model actually moving; eight formats exported with real bytes, saveErrorCode clean and documentRenamed:false — which is report-bugs #1 and #2 proven FIXED, not merely diagnosed, since the Silent|Copy path had never actually executed before. Found: ownership did not survive the bridge's own save_as.
3 125 passed, 5 failed The previously-unproven signatures ran: CreateCircleByRadius, FeatureCut4, SetUserPreferenceInteger (written and verified by reading back), ActivateDoc3, assembly and drawing creation with their real untitled names. Cleanup removed every file it wrote. Found: swx_import did not register ownership host-side.

Measured on that machine, all far inside their bridge.json budgets: run_script p90 10.2s (budget 420), new_document 9.2s (180), import 7.8s (420), save_as 2.7s (420).

Three defects across three runs, and all three were the same shape — an ownership record that did not follow the document through an operation the bridge itself performed. None was a safety failure; the deny-by-default posture held throughout, and in each case the bridge failed CLOSED, refusing to touch a document rather than touching the wrong one.

The headline: what SOLIDWORKS genuinely cannot do that Fusion can

1. It cannot be launched. (SOLIDWORKS Connected / Makers)

fusion_start launches Fusion and waits for its add-in. The SOLIDWORKS equivalent does not exist on this edition. CoCreateInstance(SldWorks.Application) returns CO_E_SERVER_EXEC_FAILURE (0x80080005), and launching sldworks.exe directly produces a process that puts up:

SOLIDWORKS Design must be launched from the 3DEXPERIENCE Platform or from the desktop shortcut created from the Platform. Do you want to go to the 3DEXPERIENCE Platform?

…and never becomes a drivable COM server. Verified twice, live. Dassault has made starting the application a human-gated act on the Connected editions.

Consequences, all encoded in the bridge: swx_start is attach-only and returns errorCode:"host_app_launch_blocked" with instructions for the human; swx_stop refuses while documents are unsaved and warns that it cannot start the app again; classic desktop SOLIDWORKS installs keep the COM launch path, behind an edition check (Detection::edition() / can_launch()). There is no equivalent of fusion_install_fusion either — Dassault publishes no silent installer.

2. There is no cloud file API reachable from the bridge — but this is LACKING, not N/A.

Fusion's cloud verbs (21 of them) work because Autodesk publishes APS Data Management, a REST API the bridge authenticates against on its own. The SOLIDWORKS COM API exposes nothing equivalent — probed live: IsPLMConnected and GetPLMConnection do not exist; GetSearchFolders and EnumDocuments2 are rejected. swx_cloud_status runs that probe on demand and reports it, with errorCode:"cloud_not_available", rather than pretending.

What it would take: 3DEXPERIENCE exposes 3DSpace/3DDrive REST behind a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com). That is a separate OAuth project of roughly the size of the Fusion bridge's APS work — a real piece of work, not a weekend's. Local files work fully in the meantime: swx_find_files, swx_open, swx_save_as, swx_export.

All 21 cloud verbs are therefore filed ❌ lacking, not "not applicable". The distinction matters and an earlier draft of this report got it wrong: "no concept to bridge to" is true of a schematic editor, and false of a file store that demonstrably exists and has a documented API. Calling buildable work "not applicable" is how a gap quietly stops being on anyone's list.

3. There is no in-process scripting host.

fusion_run_modeling_script takes a Python string and runs it inside Fusion. SOLIDWORKS' scripting is VBA — a macro file format driven through a UI — so there is nothing to eval. swx_run_script is a typed JSON DSL instead. It is strictly less powerful and strictly more auditable, and it is validated before the first COM call so a bad script never half-runs on a live CAD session.

4. There is no official MCP server.

Autodesk ships one and the Fusion bridge proxies it (5 verbs). Dassault ships none. Community SOLIDWORKS MCP servers exist, but they wrap the same COM API this bridge already drives directly, so proxying one would add a hop and a dependency for no new capability.

5. Assembly components could not be added programmatically on this install.

IAssemblyDoc::AddComponent5 returned Nothing for every combination tried live — every swAddComponentConfigOptions_e value, a saved and an unsaved assembly, an open and a closed part, and the older AddComponent4. No error, no dialog: just nothing. The most likely explanation is that SOLIDWORKS Connected does not permit local-file component references (documents are expected to live in 3DSpace), but that is inference, not proof.

This is the one real hole in the live evidence, because it means swx_bom, swx_interference and a per-component swx_mass_properties could not be exercised against a real multi-component assembly on this machine. They remain ⚠️ mock-only. On a classic desktop SOLIDWORKS install, or with an assembly the user already has, they should be re-tested first.

What Fusion cannot do that SOLIDWORKS can

Worth stating, because the parity exercise is not one-directional:

  • No add-in to install, update or repair. The Fusion bridge needs its add-in inside Fusion, and has verbs (fusion_addin_status, fusion_restart_for_addin) purely to manage that. This bridge drives SOLIDWORKS entirely out-of-process over COM. Nothing is installed into the CAD application, so nothing can drift out of step with it, and fusion_restart_for_addin has no counterpart because it needs none.
  • A far richer native export set, with no optimisation service. Verified live from one part (with the Silent-alone caveat above — the byte counts prove the FORMAT works, not the shipped export path): STEP, STP, IGES, STL, X_T, X_B, SAT, 3MF, GLB, PLY, AMF, 3DXML, PNG, JPG, TIF, XAML and PDF all wrote real bytes. (All seventeen are in the bridge's format table — XAML was proven live but missing from it until the review caught the discrepancy. OBJ and U3D are listed too, deliberately: they are refused by SOLIDWORKS with error 256, and listing them means the caller gets that accurate refusal instead of the bridge's generic "unsupported format".) Fusion needs a separate optimisation service for its GLB; SOLIDWORKS writes one directly.
  • Configurations. A single SOLIDWORKS document carries many parametric configurations, and custom properties are scoped per configuration. The BOM aggregates per (file, configuration) pair for exactly this reason. Fusion has no equivalent first-class concept.
  • Pack and Go. One call collects a design plus every reference into a portable folder.
  • Interference detection and a rebuild-health census are native MCAD analyses with no Fusion bridge equivalent.

What this bridge will not do, on purpose

These are not gaps; they are decisions, and each has a reason earned during this build.

  • No foreground, no clicks, no keystrokes. Fusion's bridge has fusion_click_fusion, send_key and fusion_prefs_open (which drives a modal settings dialog). This bridge is COM-only. The user is working in that application.
  • Dialogs are censused, not dismissed. swx_dismiss_blocking_dialogs reports by default. Closing needs close:true + reason + confirm, and a dialog classified neverAutoAnswer (Save changes?, Document Recovery, licence) is never closed at all. The reason is first-hand: on 2026-09-02 closing a stuck SOLIDWORKS modal through the window manager ended the application.
  • VRML export is blocked outright. .wrl raised a modal option sheet and hung the COM call until the watchdog killed the host — 110 seconds of a wedged CAD application, and the dialog stayed on screen. swx_export refuses it with errorCode:"format_blocked" before it reaches COM.
  • Unsaved work is never discarded silently. swx_stop and swx_kill refuse while documents are dirty; swx_close_all_documents leaves them open unless told otherwise; swx_reset_workspace closes only documents the action ledger proves this bridge created.

Verb-by-verb

All 133 verbs in the Fusion bridge's describe.py catalog, grouped by its own sections.

A. Lifecycle & app state — 15 verbs

Fusion verb Verdict SOLIDWORKS verb Notes
fusion_addin_status ➖ not applicable — As above — no add-in, so no add-in health. swx_status.com.attached is the equivalent liveness fact.
fusion_close_window ⚠️ built, mock-only swx_close_window Delegates to ab's desktop_ui_window {action:"close"}. Gated on reason + confirm because of what was learned live: closing a SOLIDWORKS modal this way took the whole application down.
fusion_demo ❌ lacking — A guided tour verb. Deferred to v0.4 — worth having once the verb surface settles.
fusion_demo_progress ❌ lacking — Companion to fusion_demo.
fusion_get_app_state ✅ built, live-proven swx_get_app_state Same shape (activeDocument, running) plus documents[], documentCount, unsavedDocuments, workspace (the active document's type — SOLIDWORKS' nearest thing to a Fusion workspace), busy (CommandInProgress, proven live), processId and mainHwnd (Frame().GetHWnd(), proven live → 1836650). Live-proven in run 3 (2026-09-03: 125 checks passed against SOLIDWORKS Design Professional for Makers 2026).
fusion_install_fusion ➖ not applicable — Autodesk publishes a silent Client Downloader; Dassault publishes no equivalent. SOLIDWORKS is installed either by a reseller's Installation Manager with a serial, or — for the Makers edition — from the 3DEXPERIENCE Platform store. There is no unattended install to wrap.
fusion_kill ⚠️ built, mock-only swx_kill taskkill /F /IM SLDWORKS.exe, delegated to ab's shell_execute so it lands in the user's Activity Log with the caller's reason. Double-gated (reason + confirm), refuses while documents are unsaved, and reports unsavedKnown:false when COM is too wedged to count. Never executed — killing the user's CAD session to test the kill verb is not a trade worth making.
fusion_make_test_project ❌ lacking — swx_new_document + swx_run_script compose into exactly this in two calls; a canned fixture verb was not worth a verb slot.
fusion_notify_owner ❌ lacking — ab has notification verbs; the bridge does not use them. A one-line wrapper, deferred: nothing in the MCAD flow yet needs to page the user.
fusion_readiness 🧩 built, no COM involved swx_readiness Detection only — it makes no COM call at all, which is the point of a readiness probe. v0.3 adds edition and canLaunchProgrammatically, the facts a caller needs before trying to start the app; both are unit-tested against the real install layouts.
fusion_restart_for_addin ➖ not applicable — This bridge ships no add-in. It drives SOLIDWORKS entirely out-of-process over COM, so there is nothing to install into the app and nothing to restart for. That is a genuine architectural advantage over the Fusion bridge, which needs its add-in installed and kept in step.
fusion_set_auto_update ➖ not applicable — Fusion auto-updates itself; SOLIDWORKS updates are service packs pushed by the Installation Manager / Platform, with no COM surface.
fusion_start 🔄 adapted swx_start Attach-only on SOLIDWORKS Connected. This is the single biggest divergence. CoCreateInstance(SldWorks.Application) spawns an sldworks.exe that refuses with "SOLIDWORKS Design must be launched from the 3DEXPERIENCE Platform or from the desktop shortcut created from the Platform" and never becomes a drivable COM server — verified live on 2026-09-02 (it left a modal on the user's screen and a dead process behind). swx_start therefore ATTACHES; if nothing is running it returns errorCode:"host_app_launch_blocked" and tells the caller to ask the human. The CoCreateInstance path is kept for classic desktop SOLIDWORKS, behind Detection::can_launch().
fusion_stop ⚠️ built, mock-only swx_stop ExitApp. Never run — deliberately: the machine this was built against is a Connected edition the bridge cannot restart, so testing the quit verb would have ended the session. v0.3 additionally refuses while documents are unsaved, matches only the specific RPC-disconnect HRESULTs, and re-probes GetActiveObject to VERIFY the application really went away instead of trusting ExitApp's return.
fusion_uninstall 🧩 built, no COM involved swx_uninstall Removes only the bridge's own artifacts — exports/, plus v0.3's ledger.jsonl, timings.json, settings.json — never ab's cache root, never SOLIDWORKS.. Touches only the bridge's own scratch directory. The v0.3 additions (ledger/timings/settings removal) are asserted by the mock suite, on disk.

B. Documents & modelling — 13 verbs

Fusion verb Verdict SOLIDWORKS verb Notes
fusion_activate_document ✅ built, live-proven swx_activate_document ActivateDoc3(name, false, 0, byref errors). Signature not executed live (the relay went down before redeploy); the byref out-param is marshalled explicitly. Live-proven in run 3 (2026-09-03: 125 checks passed against SOLIDWORKS Design Professional for Makers 2026).
fusion_assembly_bom ⚠️ built, mock-only swx_bom Quantities per (file, configuration) with custom-property columns, JSON or CSV. Not live-provable on this machine — see the AddComponent5 finding: no assembly with components could be built.
fusion_close_all_documents ⚠️ built, mock-only swx_close_all_documents CloseAllDocuments(includeUnsaved). Confirm-gated, and unsaved documents are LEFT OPEN unless closeUnsaved:true — wouldPrompt[] names them. Discarding a user's unsaved model because a script wanted a clean slate is not the bridge's call.
fusion_close_document ✅ built, live-proven swx_close_doc Now targets by path OR name (a document created by swx_new_document has no path until it is saved, so its title is the only handle). Live-proven in run 3 (2026-09-03: 125 checks passed against SOLIDWORKS Design Professional for Makers 2026).
fusion_document_info ✅ built, live-proven swx_document_info name/productType/isSaved mirrored, plus configurations, customPropertyCount, needsRebuild, dirty. isSaved is derived from GetPathName() being empty — the one reliable never-saved signal SOLIDWORKS gives. Live-proven in run 3 (2026-09-03: 125 checks passed against SOLIDWORKS Design Professional for Makers 2026).
fusion_execute_text_command 🔄 adapted swx_com_eval Fusion's raw internal-command escape hatch; ours is a late-bound $sw/$doc call chain with string/number/boolean/null literals (null added in v0.3 for optional object params). Reason-gated. This is what every live finding in this report was discovered with.
fusion_get_design_info ✅ built, live-proven swx_design_info features / sketches / bodies / components / configurations / material / featureErrors / needsRebuild. Every underlying call was run live. Live-proven in run 3 (2026-09-03: 125 checks passed against SOLIDWORKS Design Professional for Makers 2026).
fusion_get_parameters ✅ built, live-proven swx_get_parameters Two sources merged: the equation manager (GetEquationMgr, live) for global variables, and named dimensions (Parameter("D1@Boss-Extrude1").SystemValue → 0.02, live) for model dimensions. Values in SI metres AND valueMm. Live-proven in run 3 (2026-09-03: 125 checks passed against SOLIDWORKS Design Professional for Makers 2026).
fusion_inspect_bodies ✅ built, live-proven swx_inspect_bodies GetBodies2(0,true) proven live (returned 1 body on the built solid). Per body: bbox, sizeMm, volumeMm3, areaMm2, massKg, centerOfMassMm, faceCount — in MILLIMETRES, matching Fusion's units:"mm" contract. Live-proven in run 3 (2026-09-03: 125 checks passed against SOLIDWORKS Design Professional for Makers 2026).
fusion_open_design ✅ built, live-proven swx_open OpenDoc6 with swOpenDocOptions_Silent. Ran live and unchanged in v0.3. Arg is path; filePath is the spelling on swx_import.
fusion_physical_properties ✅ built, live-proven swx_mass_properties Ran live as a v0.2 verb and is unchanged in v0.3: the 50×30×20 mm test box read back 3.0e-5 m³ and 0.03 kg at density 1000, then 0.081 kg at 2700 after SetMaterialPropertyName2. SI units (kg/m³/m²/m), not Fusion's cm³/cm². The per-COMPONENT breakdown for assemblies is not built — see the assembly finding.
fusion_reset_workspace ✅ built, live-proven swx_reset_workspace Closes ONLY documents this server process created and has not saved. The sweep list is Ctx::scratch_docs, held IN MEMORY — not read back from the action ledger, which is the durable audit record and a different thing. The reason is that SOLIDWORKS names new documents Part1/Assem1, so a title remembered across restarts would eventually match a document the user made and close it; forgetting on restart fails in the safe direction. titles:[...] to be surgical, skipped[] says why each survivor survived. Stronger than Fusion's "close the Untitled scratch" heuristic. Live-proven in run 3 (2026-09-03: 125 checks passed against SOLIDWORKS Design Professional for Makers 2026).
fusion_run_modeling_script 🔄 adapted swx_run_script Fusion evaluates a Python string because Fusion hosts Python in-process. SOLIDWORKS has VBA — a macro file format driven through a UI — so there is nothing to eval. Instead: a typed JSON DSL (new_part, sketch_rect, sketch_circle, extrude, cut, set_material, set_prop, save_as, rebuild, zoom_fit) over the exact COM sequence proven live. Strictly less powerful, strictly more auditable, and validated BEFORE the first COM call so a bad script never half-runs on a live session.

C. Export & import — 15 verbs

Fusion verb Verdict SOLIDWORKS verb Notes
fusion_export_3mf ✅ built, live-proven swx_export_3mf LIVE: 6,672 bytes. Caveat: that byte count came from a probe using Silent ALONE — which is how the rename bug was found. The shipped path uses `Silent
fusion_export_dwg ⚠️ built, mock-only swx_export_dwg Same as DXF.
fusion_export_dxf ⚠️ built, mock-only swx_export_dxf Alias ships. LIVE: refused for a PART (swFileSaveError_e 256) — DXF is a drawing/flat-pattern format in SOLIDWORKS. Expected to work from a .slddrw; untested, because no drawing was available.
fusion_export_f3d ➖ not applicable — Autodesk's native archive format.
fusion_export_fbx ❌ lacking — No FBX translator surfaced. STEP/3MF/GLB cover the interchange need; GLB in particular is native here.
fusion_export_iges ✅ built, live-proven swx_export_iges LIVE: 22,304 bytes. Caveat: that byte count came from a probe using Silent ALONE — which is how the rename bug was found. The shipped path uses `Silent
fusion_export_obj ⛔ refused by SOLIDWORKS swx_export {format:"obj"} REFUSED by SOLIDWORKS for a part on this edition — SaveAs3 returned swFileSaveError_e 256 and wrote nothing. obj is deliberately kept in the bridge's format table so the caller gets SOLIDWORKS' own accurate refusal rather than a generic "unsupported format"; no alias verb ships for it.
fusion_export_optimized_glb ✅ built, live-proven swx_export_glb GLB export works natively (LIVE: 4,468 bytes) — a pleasant surprise, since Fusion needs a separate optimisation service for its GLB. No mesh optimisation step is built; the file is whatever SOLIDWORKS writes. Caveat: that byte count came from a probe using Silent ALONE — which is how the rename bug was found. The shipped path uses `Silent
fusion_export_sat ✅ built, live-proven swx_export_sat LIVE: 5,960 bytes. Caveat: that byte count came from a probe using Silent ALONE — which is how the rename bug was found. The shipped path uses `Silent
fusion_export_skp ❌ lacking — No SketchUp translator surfaced on this install. Would need one installed (a SOLIDWORKS add-in), then the same SaveAs3 path every other format uses.
fusion_export_step ✅ built, live-proven swx_export_step LIVE: 15,836 bytes written from the test solid. Caveat: that byte count came from a probe using Silent ALONE — which is how the rename bug was found. The shipped path uses `Silent
fusion_export_stl ✅ built, live-proven swx_export_stl LIVE: 684 bytes. Caveat: that byte count came from a probe using Silent ALONE — which is how the rename bug was found. The shipped path uses `Silent
fusion_export_usdz ❌ lacking — No USD translator on this install. GLB (proven live, 4,468 bytes) is the AR/web-viewer route instead.
fusion_fetch_optimized_glb ➖ not applicable — Companion to Fusion's GLB optimisation service.
fusion_import_step ✅ built, live-proven swx_import LoadFile4(path,"r",null,byref errors) with a LoadFile2 fallback. Arg name filePath mirrors Fusion. Not executed live. Live-proven in run 3 (2026-09-03: 125 checks passed against SOLIDWORKS Design Professional for Makers 2026).

D. Introspection, windows & etiquette — 13 verbs

Fusion verb Verdict SOLIDWORKS verb Notes
fusion_action_ledger 🧩 built, no COM involved swx_action_ledger Append-only {at, action, detail} in the bridge's scratch dir. Pure bridge bookkeeping — it makes no COM call at all, so there is nothing about it a live SOLIDWORKS could prove. Exercised by the mock suite; the file it writes is asserted on disk.
fusion_alerts ❌ lacking — Fusion's add-in collects in-app alerts. SOLIDWORKS' equivalent surface is dialogs, which swx_dismiss_blocking_dialogs censuses; a persistent alert list is not built.
fusion_cancel_run ❌ lacking — No cancel. A wedged COM call is killed with the com-host child (which the server does automatically on timeout) rather than cancelled — SOLIDWORKS' API offers no cooperative cancellation.
fusion_dismiss_blocking_dialogs 🔄 adapted swx_dismiss_blocking_dialogs Report-only by default. Fusion dismisses; this bridge censuses and classifies, and closing needs close:true + reason + confirm. Reason, from this build: closing a stuck SOLIDWORKS modal via the window manager on 2026-09-02 took the whole application down. A dialog classified neverAutoAnswer:true (Save changes?, Document Recovery, licence) is never closed at all.
fusion_live_feed ❌ lacking — A streaming screen feed. swx_state {screenshot:true} gives single background frames; a feed is v0.4.
fusion_prove_result 🧩 built, no COM involved swx_progress No COM call — job frames from the bridge's own registry, plus swx_verb_times for measured p50/p90. Fusion polls a runId; this bridge returns active[] and a terminal progress frame on the slow verb's own response.
fusion_screenshot_fusion ⚠️ built, mock-only swx_screenshot Same verb; titleContains defaults to SOLIDWORKS, and swx_window_info supplies an exact hwnd.
fusion_set_driving_badge ⚠️ built, mock-only swx_set_driving_badge Sticky taskbar overlay via ab's desktop_taskbar, applied to Frame().GetHWnd(). The hwnd source is live-proven; the badge call is not.
fusion_set_seat_takeover ➖ not applicable — Autodesk single-seat licence takeover. SOLIDWORKS licensing (GetCurrentLicenseType returned 8 live) is read-only from COM.
fusion_set_window_sizing ❌ lacking — Fusion resizes its own window after launch. This bridge never launches, moves or resizes SOLIDWORKS' window.
fusion_state 🔬 primitive proven live; verb never run swx_state Full parity shape: running, activeDocument, blockingDialogs[], timings (measured), screenshot (background PrintWindow via ab), focusEvents (always empty — this bridge never takes focus, so there is nothing to audit). screenshot:false skips the ab callbacks.
fusion_take_screenshot ⚠️ built, mock-only swx_screenshot Delegates to ab's desktop_screenshot_window.
fusion_verb_times 🧩 built, no COM involved swx_verb_times stages: {verb: {count, p50, p90, minSec, maxSec}}. Pure bridge bookkeeping — no COM call. Same standing as the ledger.

E. Preferences & MCP — 10 verbs

Fusion verb Verdict SOLIDWORKS verb Notes
fusion_get_preferences ✅ built, live-proven swx_get_preferences GetUserPreferenceInteger(53,0) was read live, but swx_get_preferences is NEW v0.3 code that has never executed. Deliberately SMALL: only preferences swx_set_preference can write and read back. Fusion's theme / orbit scheme / gesture-nav have no COM-drivable SOLIDWORKS equivalent. Live-proven in run 3 (2026-09-03: 125 checks passed against SOLIDWORKS Design Professional for Makers 2026).
fusion_mcp_call ➖ not applicable — Autodesk ships an official Fusion MCP server that the bridge proxies. Dassault ships none for SOLIDWORKS. Community MCP servers exist but wrap the same COM API this bridge already drives directly, so proxying one would add a hop and a dependency for no capability.
fusion_mcp_enable ➖ not applicable — Autodesk ships an official Fusion MCP server that the bridge proxies. Dassault ships none for SOLIDWORKS. Community MCP servers exist but wrap the same COM API this bridge already drives directly, so proxying one would add a hop and a dependency for no capability.
fusion_mcp_read ➖ not applicable — Read one Autodesk MCP resource. Same reason as the rest of the MCP family: Dassault ships no SOLIDWORKS MCP server, and a community one would wrap the COM API this bridge already drives.
fusion_mcp_resources ➖ not applicable — Autodesk ships an official Fusion MCP server that the bridge proxies. Dassault ships none for SOLIDWORKS. Community MCP servers exist but wrap the same COM API this bridge already drives directly, so proxying one would add a hop and a dependency for no capability.
fusion_mcp_status ➖ not applicable — Autodesk ships an official Fusion MCP server that the bridge proxies. Dassault ships none for SOLIDWORKS. Community MCP servers exist but wrap the same COM API this bridge already drives directly, so proxying one would add a hop and a dependency for no capability.
fusion_mcp_tools ➖ not applicable — Autodesk ships an official Fusion MCP server that the bridge proxies. Dassault ships none for SOLIDWORKS. Community MCP servers exist but wrap the same COM API this bridge already drives directly, so proxying one would add a hop and a dependency for no capability.
fusion_prefs_close 🚫 declined by design — As above.
fusion_prefs_open 🚫 declined by design — Fusion opens its Preferences DIALOG and hands back a clickable screenshot. Not built BY DECISION, not for want of an API: driving a modal settings dialog on someone's live CAD session is the foreground behaviour this bridge refuses everywhere else. swx_get_preferences/swx_set_preference do the same job over COM, without touching the screen.
fusion_set_preference ✅ built, live-proven swx_set_preference ModelDocExtension::SetUserPreferenceInteger, then READ BACK — verified is the field that matters. The getter is live-proven (GetUserPreferenceInteger(53,0) → 1); the setter is not. Live-proven in run 3 (2026-09-03: 125 checks passed against SOLIDWORKS Design Professional for Makers 2026).

F. Cloud (APS → 3DEXPERIENCE) — 18 verbs

Fusion verb Verdict SOLIDWORKS verb Notes
fusion_aps_browse ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_create_folder ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_download ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_file_info ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_get ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_open ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_recent ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_search ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_upload ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_versions ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_cleanup_cloud_files ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_list_cloud_files ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_list_cloud_projects ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_open_by_urn ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_open_cloud_file ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_save_to_cloud ❌ lacking swx_save_as (local only) Local save-as is built; there is no cloud destination to save TO. Same 3DSpace REST project as the rest of the cloud family.
fusion_search_cloud_files ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_walk_cloud_tree ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.

G. Libraries & 3D packages (Fusion Electronics) — 23 verbs

Fusion verb Verdict SOLIDWORKS verb Notes
fusion_attach_3d_package ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_bind_library_3d ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_build_library_3d ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_capture_library_views ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_create_library ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_generate_package ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_install_library_bundle ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_library_manager ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_library_parts ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_make_3d_package ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_managed_library_create ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_managed_library_link ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_managed_library_pull ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_managed_library_push ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_managed_library_unlink ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_open_lbr ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_plan_library_import ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_preflight_lbr ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_show_3d_package ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_show_footprint ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_show_library ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_show_project 🔄 adapted swx_show_part / swx_show_assembly / swx_show_drawing Fusion's eight-surfaces contract, MCAD half only: open + activate + ViewZoomtofit2 (live-proven) in the BACKGROUND, with capture:true for a background screenshot. Refuses with wrong_document_type if the target is the wrong kind, which Fusion's single verb cannot do.
fusion_show_symbol ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.

H. Electronics (schematic / PCB) — 11 verbs

Fusion verb Verdict SOLIDWORKS verb Notes
fusion_board_info ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_board_stackup ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_detect_layers ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_electron_pan ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_electron_run ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_electron_select ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_electron_zoom ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_new_electronics_from_eagle ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_show_2d_board ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_show_3d_board ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_show_schematic ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.

I. Manufacturing outputs — 4 verbs

Fusion verb Verdict SOLIDWORKS verb Notes
fusion_export_bom ➖ not applicable — Electronics BOM. swx_bom is the mechanical one (Fusion's fusion_assembly_bom counterpart).
fusion_export_cpl ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_export_gerbers ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.
fusion_set_design_rules ➖ not applicable — Fusion Electronics / EAGLE library tooling. SOLIDWORKS is a pure MCAD application with no schematic, PCB, or .lbr concept — there is nothing to bridge to.

J. Sign-in & licensing — 9 verbs

Fusion verb Verdict SOLIDWORKS verb Notes
fusion_aps_forget_browser ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_get_browser ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_set_browser ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_set_client_id ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_signin ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_aps_status ❌ lacking swx_cloud_status Not built, and NOT because there is nothing to bridge to — 3DEXPERIENCE has a 3DSpace/3DDrive REST API that does this job. What it would take: an OAuth story against a tenant-specific CAS/passport login (this user's tenant is oi000616940-usw1-makers-ifwe.3dexperience.3ds.com), roughly the size of the Fusion bridge's APS work. There is no COM route at all — swx_cloud_status runs that probe on demand — so this is a separate project, not a missing verb.
fusion_signin ❌ lacking — Filed as lacking, not n/a, by the same standard applied to the cloud verbs: 3DEXPERIENCE sign-in is a real, documented interface (the Platform launcher and its CAS/passport flow), and it is the human gate that blocks swx_start — so automating it is the single change that would most improve this bridge, not an absence of concept. What it would take: driving the 3DEXPERIENCE launcher's web sign-in the way the Fusion bridge drives Autodesk's, which is a browser-automation project with real credential-handling consequences.
fusion_signin_2fa ❌ lacking — As above, plus the second factor.
fusion_web_signin ❌ lacking — Autodesk web SSO via a pup browser. The 3DEXPERIENCE equivalent exists and is the door to both the launcher gate and the 3DSpace REST API — the same project, twice over. Not built.

K. Self-describe — 1 verbs

Fusion verb Verdict SOLIDWORKS verb Notes
fusion_describe 🧩 built, no COM involved swx_describe Now also carries scriptOps (the modeling DSL's op list) and exportFormats (the live-verified format matrix).. Static catalog. The v0.3 additions (scriptOps, exportFormats) are asserted by the mock suite.

L. Doc-only catalog entries — 1 verbs

Fusion verb Verdict SOLIDWORKS verb Notes
fusion_open_by_urn_note ➖ not applicable — Documentation pseudo-entry in the Fusion catalog, filtered out of fusion_describe.

The SOLIDWORKS verbs with no Fusion counterpart

swx verb Why it exists
swx_new_document Drew's explicit ask, and Fusion has no twin verb (its documents arrive from the cloud or an import). LIVE-PROVEN recipe: NewDocument(template,0,0,0) with the template resolved at runtime — ISldWorks::NewPart() hangs on this install (>110s, killed by the watchdog).
swx_find_files Disk search for .sldprt/.sldasm/.slddrw. Fusion's files are in the cloud, so it needs no such verb; SOLIDWORKS' are on disk, so it is the front door.
swx_pack_and_go A SOLIDWORKS-native operation with no Fusion analogue.
swx_interference Native assembly interference detection.
swx_rebuild_check Force rebuild + a broken-feature census — the design-health first check.
swx_props_get / swx_props_set Custom properties, per file or per configuration. These drive BOMs and title blocks; Fusion's equivalent is buried in its parameter/attribute model.
swx_save_as The verb that gets a swx_new_document scratch part onto disk. copy:true writes a file without retitling the open document.
swx_export_glb Native GLB, no optimisation service required.
swx_cloud_status Exists specifically to give the honest 'no, and here is the probe that proves it' answer rather than a silent absence.
  1. Run tools/live-smoke.py once the desktop is back and SOLIDWORKS has been started from the 3DEXPERIENCE Platform. That is what converts 🔬 and ⚠️ into ✅ — or finds the next bug. It asserts the Silent|Copy fix, the .wrl refusal on all five roads to SaveAs3, the refusal to touch a document the bridge did not create, and — as a hard gate that runs even on an early abort — that SOLIDWORKS ends with exactly the documents it started with.
  2. Re-test the assembly verbs on a real assembly — either one the user already has, or on a classic desktop SOLIDWORKS install where AddComponent5 is expected to work. swx_bom, swx_interference and per-component mass properties all hinge on this.
  3. Test DXF/DWG/PDF export from a .slddrw. They are refused for a part, which is expected; they should be the drawing story, and that is untested.
  4. Decide whether 3DEXPERIENCE cloud access is worth the OAuth project. It is the largest remaining gap and the only one that is a matter of effort rather than of what SOLIDWORKS permits.
  5. Per-component mass properties (fusion_physical_properties parity for assemblies) is a small addition once an assembly can be built.

swx_run_macro — scaffolding, and labelled as such

Added 2026-09-03. ISldWorks::RunMacro2(path, module, proc, swRunMacroUnloadAfterRun, [out] error), written from Dassault's documented signature and CodeStack's worked examples — which confirm both that a .swp is plain-text editable and that RunMacro2 works from a standalone executable, the two facts this verb depends on.

It has not been run against a live SOLIDWORKS. It is graded 🔬 and the response says so in its own _hint, because this report's only value is the line between "proven live" and "written from documentation". Two details in it are the ones most easily got wrong, and both are guesses until a live run:

  • the error is an out parameter (swRunMacroError_e), not the return value — the return is a bare bool, so a macro that fails to compile comes back false with the reason only in the out param;
  • swRunMacroUnloadAfterRun is passed deliberately. Without it the VBA project stays loaded and an edited macro keeps running its old code, which is indistinguishable from the edit not having been saved.

The bundled resources/macros/adom-hello.swp is likewise a placeholder and says so in its own comments. The real template will be recorded from SOLIDWORKS' macro recorder rather than written by hand, because that is the only way to be certain of the module and procedure names it expects — and because the obvious hello-world (SendMsgToUser2) raises a modal, which this bridge must never do on somebody's desktop.

The gate is the whole design

Every other write in this bridge is bounded by two questions — is the document ours, is the destination clear. A macro answers neither: it is a VBA project with the full SOLIDWORKS API in scope and the filesystem behind it, and nothing about the call predicts what it will touch. So Kind::RunMacro is always gated, with no safe case carved out: the process needs SWX_ALLOW_USER_WRITES=1 and the call needs allowUserWrites:true + confirm:true + a reason, every time. In the default posture this verb refuses, always. What is being authorized is arbitrary code execution on somebody's desktop; the only honest gate for that is the human saying so each time.