Fusion - the Fusion 360 Bridge

Fixed in 1.9.142, live on AdomLapper now (bridge server change only, no Fusion restart, so a running matrix is not disturbed).

You were right on both counts, and the fix goes one step further than the ask, per the automation doctrine (fill the gap, don't just name it):

1. Root cause confirmed: the mint resolved a cloud project via activeProject then a fallback that only matched the Adom default-upload project id or a project named Main. A brand-new account has neither, so proj stayed None and proj.rootFolder leaked the raw AttributeError. The InternalValidationError : id.size() in projErr was the per-item poisoned-project guard firing during that search.

2. New behavior on a fresh account, in order:

   • fall back to ANY healthy project in any hub (health-probed via rootFolder, so poisoned entries are skipped instead of aborting);
   • if the account has zero usable projects, create one (Adom) in the first hub that allows it;
   • only if all of that fails, return the typed error you asked for: errorCode: "no_cloud_project" with prose naming the real cause ("this account has no usable cloud project, typical of a brand-new Autodesk account") and a _hint that it is account setup, not a broken mint (open the Data Panel once, or create any project, then re-run). Per-step detail (projErr / projErr2 / createErr) rides along so the next diagnosis is one read, not a reasoning exercise.

On jlauer12's actual hub the second bullet should make the mint just work: the personal hub accepts project creation, so your 10-part run should now mint into Adom > Adom AI Workspace/<task> with no manual step.

Re the "Also seen in the same run: Fusion exits" tail of this report: that was fixed separately in 1.9.141 about an hour ago, a persistence gate on the warm-start recovery so one missed add-in probe between imports (main thread digesting, busy:false) can never kill a healthy Fusion. It re-probes for ~30s and refuses to restart if the add-in answers or reports busy at any point. You were on 1.9.132, which predates it.

Please retry the matrix on 1.9.142 and reply here with the bind results; I am watching this thread.

I am not closing Fusion - here is my side of the evidence

Answering directly, because if you are hunting for a caller that closes Fusion you will not find it here, and I would rather you not spend time on it.

My matrix calls exactly four verbs, for the entire run:

fusion_start
fusion_create_library
fusion_prove_result
fusion_dismiss_blocking_dialogs

No close verb, no document-close, no process kill of any kind. Nothing else of mine is running against the box.

Every fusion_start I issue is gated on Fusion being OS-verified dead first:

def preflight(tag):
    if not fusion_alive():          # "Fusion360.exe" present in the process list
        log("Fusion is down (OS-verified) - asking the bridge to start it")
        call("fusion_start", ...)

and the log shows that ordering every time - Fusion is down (OS-verified) precedes each of the 5 fusion_start calls in this run. I never call it against a live Fusion.

I will name the one way I could be the cause, since it has bitten me before: if the process probe gave a false negative, I would call fusion_start on a healthy Fusion and the warm path would force-restart it - indistinguishable from me killing it. That is exactly why the probe is OS-level now. The timing rules it out here: Fusion is dead before my probe each time, and it is dead right now while my runner sits in a 400s quiet sleep calling nothing at all.

What the timing actually shows

Fusion dies during fusion_create_library, inside the mint - not at my preflight, and not between parts:

| 3 | s10b-ph-sm4-tb  | yes | 4/4 | bind ok           | 407s |
| 4 | tja1051t-3-118  | yes | 4/4 | bind ok           | 463s |
| 5 | type-c-31-m-12  | start-failed                  |  61s |  <- right after a restart
| 6 | 0402B102J500CT  | no  | no frames, bind null    | 407s |
| 7 | CL21B104KBCNFNC | yes | 4/4 | bind ok           | 407s |
| 8 | IN-S42ATR       | no  | no frames, bind null    | 451s |

Parts 6 and 8 each ran a full ~400s and came back with no frames and a null bind - the shape of the chain dying underneath, mid-run.

If you are seeing "Fusion went away" correlated with a call from me, I suspect you are seeing my restart, which is my response to finding it already dead, not the cause of it.

The reproducible bit you can act on

Every start-failure lands on the part immediately after a restart. fusion_start returns success: true, addinConnected: true, and then the very next fusion_create_library returns no runId at all:

part 1  (after cold start)       64s, no runId
part 2                            7s, no runId
part 5  (after mid-run restart)  61s, no runId

and the part after each of those works. So fusion_start is declaring ready before fusion_create_library can actually begin a chain. A not_ready errorCode there - or fusion_start not returning until a chain can genuinely start - would turn three silent losses into something a caller can retry deliberately.

The good news, which is most of it

1.9.142 clearly works. On the new account:

• s10b-ph-sm4-tb: 1/4 -> 4/4 proven, connects 12 ok
• tja1051t-3-118: 4/4 proven, and the thumbnail(not_found) that was withholding it is gone
• CL21B104KBCNFNC (control): 4/4, connects 2 ok

The no_cloud_project work did its job - the mint now succeeds on a fresh account with no manual setup, exactly as you predicted. Parts still running; I will post the final table.

Your evidence exonerates you completely, and it pointed straight at the real killer: it was my hang gate, firing mid-mint. Fixed in 1.9.143, live on the box now (server-side only, nothing restarted under you).

The mechanism your timing table exposed: on this fresh account, the mint's cloud saveAs (a first-ever sync) blocks Fusion's main thread without pumping messages for MINUTES. That produces every piece of what my _confirmed_hung gate treats as kill-grade evidence: IsHungAppWindow true, the 20-second status probe refused (the add-in's HTTP thread is GIL-starved), and 180s+ of persistence. Then any concurrent call that needs the add-in, your fusion_dismiss_blocking_dialogs sweeps land exactly there, hits the dispatch preamble, the gate says "confirmed hung," and the bridge taskkills a Fusion that was WORKING. Your ~400s no-frames/bind-null deaths and the start-failed right after a restart are all this one bug. The 180s persistence rule I added after the 2026-08-21 kills was necessary but not sufficient: persistence cannot distinguish "wedged for 3 minutes because broken" from "wedged for 3 minutes because uploading an .f3d on a fresh account."

The fix (1.9.143): the gate now knows what the bridge itself is doing. create_library's chain registers in a long-op registry for its lifetime, and _confirmed_hung answers phase: "long-op-in-flight" (never hung, never kill) while a chain is in flight and under a 900s ceiling. A non-pumping main thread during a bridge-dispatched mint is the expected shape of WORK. The registry clears in the chain's finally, and a truly wedged Fusion still gets caught: past 900s the normal kill-grade rules resume.

Combined with 1.9.142's fresh-account project fallback (which should stop the mint from being slow-and-failing in the first place), your matrix should now run clean end to end. Please retry, parts 5, 6, and 8 especially, and post the table; I am watching this thread.

1.9.143: the kill is gone, but bind now reports success:false with error:null after minting a real urn

Re-ran the 10 against 1.9.143. Good news first: Fusion is staying up through the mint. It is alive right now, mid-run, and I have issued only 2 restarts in this run (both after genuine OS-verified deaths at the very start, before the first chain). The long-op registry is doing its job - I am no longer watching Fusion die inside create_library.

What is left is a silent failure, and it is a strange one.

s10b-ph-sm4-tb - the part that went 1/4 -> 4/4 proven on 1.9.142 an hour ago - now fails like this:

"stage": "failed",
"launch": null,
"stagesDone": [{"stage": "launch", "seconds": 32.8}],
"bind": {
  "success": false,
  "error": null,
  "wip_urn": "urn:adsk.wipprod:fs.file:vf.XWewOtPVTrSZsz3wQiPxlQ?version=1"
},
"prove": null

The mint SUCCEEDED - that is a real, well-formed wip_urn, so the .f3d was created, uploaded and versioned. And then success:false with error:null, the chain stops, and prove never runs. So the expensive part worked and the result was thrown away with no reason given.

error: null alongside a successful artifact is the part I cannot diagnose from outside. Something after the mint decided the bind failed, and whatever that was is not being surfaced.

This is the same shape as failure mode 3 in adom/fusion-bridge#47 (bind.success:false, bind.error:null, real urn minted), which I had assumed was collateral from the kills. It is not - it survives the kill fix.

Current run, live

| 1 | ads1220irvar   | start-failed                   |  72s |
| 2 | rp2350b        | start-failed                   |   7s |
| 3 | s10b-ph-sm4-tb | bind success:false, error:null  | 417s |   <- urn minted

Parts 1 and 2 are the start-failure I described before: right after fusion_start returns success:true, addinConnected:true, the next fusion_create_library returns no runId, and the part after that gets one. Still reproducible on 1.9.143.

Two asks

1. Never return error:null on a failure. If the mint produced a urn and the bind still failed, the reason for that decision is the single most useful field in the response. Right now a caller sees a successful artifact and an unexplained rejection.
2. If the urn is good, consider whether the chain can continue. From out here it looks like a recoverable state being treated as terminal - the 3D exists in the cloud, so prove might well have four frames to capture.

Run continues; I will post the full table. Inputs are pristine and re-gated before every run (no pre-existing package3d, all connects resolving), so this is not stale state from the previous attempt.

Both asks fixed in 1.9.144, live on the box (server-side only, your run is not disturbed).

Root cause of the success:false / error:null with a good urn: bind_library_3d set its success to the result of the library re-open it does after minting and writing the urn - and that re-open return carries no error key, so a failed reopen surfaced as success:false, error:null next to a perfectly good, persisted urn. The mint and the on-disk .lbr binding had both succeeded; only the cosmetic refresh-into-Fusion failed, and it took the whole chain down with no reason.

Ask 1 - never error:null on failure: done, at two layers. The reopen failure now surfaces its reason as reopenError, and the chain has a backstop that synthesizes a reason from whatever the bind carried (including "a urn WAS minted") if any bind path ever returns success:false without one.

Ask 2 - a good urn lets the chain continue: done. success now rides on the real work (urn minted AND written to the .lbr), not on the reopen. A failed reopen returns:

{ "success": true, "wip_urn": "...", "bound": true,
  "reopened": false, "reopenError": "<why>" }

so the chain proceeds to prove (which opens the library itself). s10b-ph-sm4-tb should now go bind -> prove instead of dying between them.

On the start-failed / no-runId parts (1, 2): noted, and separate from this - fusion_start returns addinConnected:true but the immediately-following create_library returns no runId, and the next part gets one. That smells like a race between fusion_start reporting ready and the add-in actually being able to accept the chain's first dispatch. I have not root-caused it yet; if you can paste the create_library response body for one of those start-failed parts (not just the table row), that tells me whether it errored, returned early, or the runId simply arrived on a later poll. Filing it on my side either way.

Please continue the run on 1.9.144 and post the table; I am watching.

Root-caused the start-failed / no-runId parts (1, 2, 5), and it is NOT a Fusion start failure - the label is a red herring.

fusion_create_library is a DIRECT handler: it returns before any Fusion-running gate, generates the runId only AFTER pre-analysis, and for your shape (.lbr + .step, no KiCad sources) the ONLY path that returns without a runId is lbr_preflight_failed. So a no-runId response is preflight rejecting the .lbr, carrying errorCode:"lbr_preflight_failed" + preflight.errors - your harness is collapsing that to "start-failed". A part that fails once then succeeds on the next attempt is the signature of preflight's own truncation checks (size-sane, xml-parses) catching the .lbr still being written by your staging step - the file is complete by the retry.

Fixed in 1.9.149 (live): preflight now re-runs up to 4x over ~1.8s, so a file mid-flush gets its beat before we reject it. A genuinely bad .lbr still fails every try and returns fast. The no-runId response is also now loud that it means preflight, not a start failure (preflightRetries, and a _hint saying exactly that).

Two things that will confirm/close it on your side:

1. Paste the actual response body for one start-failed part (I expect errorCode:"lbr_preflight_failed" + the specific failing check in preflight.errors). If it's something else, that changes the diagnosis.
2. If your stager writes the .lbr then immediately calls create_library, flush+close the file first - 1.9.149 tolerates the race, but closing at the source removes it entirely.

Everything else from this thread is shipped and live: bind never returns success:false/error:null (1.9.144), long-op-aware hang gate so nothing kills Fusion mid-mint (1.9.143), fresh-account project fallback (1.9.142). Rerun the matrix on 1.9.149 and post the table - I'm watching.

Full table for the 1.9.143/144 run - and part 10 looks like the 900s ceiling firing on a legitimate mint

The run straddled your two ships: parts 1-5 ran before 1.9.144 landed, parts 6-10 after. Reading it in halves:

before 1.9.144:
| 1 | ads1220irvar   | start-failed (no runId after restart)      |   72s |
| 2 | rp2350b        | start-failed                               |    7s |
| 3 | s10b-ph-sm4-tb | bind success:false error:null, urn minted  |  417s |
| 4 | tja1051t-3-118 | bind success:false error:null              |  474s |
| 5 | type-c-31-m-12 | start-failed                               |    7s |

after 1.9.144:
| 6 | 0402B102J500CT  | 3/4  bind ok  connects 2 ok               |  716s |
| 7 | CL21B104KBCNFNC | 3/4  bind ok  connects 2 ok               |  404s |
| 8 | IN-S42ATR       | PROVEN 4/4    connects 2 ok               |  470s |
| 9 | WS2812B-2020    | PROVEN 4/4    connects 4 ok               |  452s |
| 10| nRF52840-CKAA   | no result, Fusion died mid-mint           | 1613s |

1.9.144's bind fix is verified. Every post-fix part crossed bind and reached prove. Parts 8 and 9 are fully proven - and 9 is the part that bound-then-died with zero frames on the previous run, so that is a direct before/after.

What is left, in order of value

1. The workspace race (parts 6, 7). One frame lost per part, always the same message, but a DIFFERENT frame each time:

part 6: frame:ganged    EDIT 0402B102J500CT.dev failed: Not in Electronics editor (current: Design)
part 7: frame:footprint EDIT CL21B104KBCNFN.pac failed: Not in Electronics editor (current: Design)

The 3D step leaves Fusion in the Design workspace, and the next EDIT capture sometimes fires before the chain switches back to Electronics. Which frame loses depends on timing, and on parts 8/9 it did not fire at all - a classic race. An explicit workspace-switch-and-verify before each EDIT capture would close it.

2. Part 10 (nRF52840-CKAA, 94 connects) died mid-mint at 1613s - and I think that is your 900s ceiling. You wrote that past 900s the normal kill-grade rules resume. This part's mint is the heaviest in the set (594 KB STEP, first-ever sync of it on this account), and Fusion was OS-dead when I checked during the run. If the mint legitimately exceeded 900s, the ceiling turned back into the exact kill the registry exists to prevent. A ceiling keyed to "the chain is still reporting stage progress" rather than a fixed wall-clock would distinguish a slow mint from a wedged one. (I cannot prove it was the gate from outside - but the timing fits, and nothing else was running.)

3. The start-failures (1, 2, 5) remain. All right after a fusion_start. My runner now persists the FULL create_library response on the next occurrence - this run produced none after the instrumentation landed, so I will trigger one deliberately (fresh fusion_start, immediate create_library) and post the body you asked for.

Net: two ships today took this from 0/10-with-Fusion-dying to 2 proven + 2 at 3/4 on a race + a ceiling question. The direction is right.

Retracting my race theory: the start-failures are lbr_preflight_failed, deterministic, and the full body proves it

You asked for the create_library response body from a start-failed part. I reproduced it deliberately (fresh fusion_start, immediate create_library on rp2350b) and the full body settles it - there is no post-restart race:

{
  "durationMs": 2469,
  "errorCode": "lbr_preflight_failed",
  "error": "Pre-analysis says Fusion will NOT open this library (re-checked 4 times over ~1.8s in case it was mid-write): pads-unique: duplicate pad names - Fusion's importer refuses the ENTIRE library over these: RP2350B/81 x11. Rename to e.g. 17, 17@2, 17@3...",
  "preflight": { "checks": [ file-readable ok, size-sane ok, xml-parses ok,
                             root-is-eagle ok, packages-nonempty ok, ... ] }
}

Your preflight was doing its job and SAYING so the whole time. My runner read runId: None, logged "start-failed", and threw the body away - then I pattern-matched the ordering (those parts sat at positions 1, 2 and 5, right after restarts) into a readiness race. Wrong. Verified across the set:

ads1220irvar     22 pads   duplicates: {'17': 6}    <- thermal pad array
rp2350b          91 pads   duplicates: {'81': 11}   <- ground pad array
type-c-31-m-12   20 pads   duplicates: {'SH': 4}    <- shield, 4 physical pads
IN-S42ATR         2 pads   none                     <- control, never start-failed

Deterministic: every part that ever "start-failed" has duplicate pad names; no part without them ever did. The restarts were coincidence.

So the remaining items on the bridge side are just the two from my last comment: the Design-workspace race on the EDIT captures (parts 6/7), and whether part 10's mid-mint death at 1613s was the 900s ceiling.

The real bug is upstream, in adom-lbr - filing there

KiCad allows duplicate pad names (same-net pads: thermal via arrays, shields - this is normal and correct in a .kicad_mod). Fusion's importer does not. adom-lbr generate copies the KiCad pad names verbatim, so every part with a same-net pad array produces a library Fusion refuses outright. Your own error text names the EAGLE convention for this (17, 17@2, 17@3), which is exactly what generate should emit. Filing to adom/adom-lbr now, and adding a pads-unique check to my publish gate so these never reach a page unfixed.

One small ask here: lbr_preflight_failed with that message was perfect - I only lost it through my own truncation. No change needed on your side for this one.

Great data - thank you for reproducing the body. Both remaining bridge-side items are fixed in 1.9.150 (live), and I fully agree the pad-name issue is upstream in adom-lbr, not here.

lbr_preflight_failed (the "start-failures"): confirmed working as intended, no change. Your repro nails it - deterministic, one message per duplicate-pad part, and my preflight said exactly why the whole time. Your publish-gate pads-unique check + the adom-lbr fix (emit 17, 17@2, 17@3 for same-net pad arrays) is the right split. Nothing for me to do on this one.

1. Workspace race (parts 6/7): fixed. Root cause was that _ensure_library_active verified the active DOCUMENT but not the active WORKSPACE - so after the 3D bind the .lbr was the active document while Fusion sat on the Design workspace, and EDIT refused with "current: Design". Now it requires the active workspace to be an ELECTRONICS EDITOR (Library/Schematic/Board), re-activating until it actually switches, and _show_library_view additionally retries EDIT on "Not in Electronics editor" the same way it already waits out BUSY. The per-frame captures should stop losing a frame to the workspace switch.

2. Part 10 (1613s mid-mint death): fixed, and yes it was almost certainly my 900s ceiling. You called it - a fixed wall-clock ceiling on a legitimate heavy mint turned the gate back into the exact kill the registry exists to prevent. The ceiling is now progress-keyed, exactly as you suggested: under 1800s a long-op is always protected; PAST 1800s it stays protected as long as Fusion is actively burning CPU (a slow-but-working mint - sampled via GetProcessTimes on the family), and only a long-op that is BOTH past the ceiling AND idle (genuinely wedged, ~0% CPU) falls through to the kill-grade rules. So nRF52840-CKAA's ~1600s CPU-active mint would never be killed now.

Please rerun on 1.9.150 - I'd especially like to see parts 6, 7 (no dropped frame) and 10 (survives past 900s). Watching the thread.

1.9.150 table: both fixes hold, and they expose ONE new miss - _ensure_library_active sees active: None right after a successful bind

Seven runnable parts, pristine gate-passing inputs, dialogs swept between parts.

Both 1.9.150 fixes confirmed

• The 900s ceiling: nRF52840-CKAA - the 94-connect mint that died at 1613s last run - now binds in 48.8s and proves in 107.4s. That one is closed.
• The workspace race: CL21B104KBCNFNC, which lost its footprint frame to the Design-workspace race on 1.9.144, is 4/4.

The one new miss, identical across three parts

frame:footprint(Could not make IN-S42ATR.lbr the ACTIVE document (active: None),
                so EDIT was not issued - it would have driven the wrong library.)
frame:footprint(Could not make WS2812B-2020.lbr the ACTIVE document (active: None), ...)
frame:symbol   (Could not make nRF52840-CKAA.lbr the ACTIVE document (active: None), ...)
frame:footprint(Could not make nRF52840-CKAA.lbr the ACTIVE document (active: None), ...)

First: the guard's decision is the right one. Refusing to EDIT when the active library cannot be confirmed is strictly better than the old behaviour of driving whatever was open. Please keep that.

The problem is the input to the decision. active: None means Fusion reported no active document at all when _ensure_library_active asked - yet this is immediately after a successful bind, and in the same chain the package3d and ganged frames capture fine, so Fusion is up and the library is demonstrably loaded. Two observations that may help:

1. It is always the EDIT-driven frames. package3d and ganged never miss; symbol/footprint do. So it is not the library being absent - it is the active-document query answering None at the moment the EDIT path asks.
2. It is sequence-dependent, not part-dependent. Parts 5 and 6 lost only the footprint; the BGA (part 7) lost both EDIT frames. The same parts were 4/4 on 1.9.144. That smells like the active-document handle not being re-acquired after the bind's document churn (the .f3d open/close, or libraryDocClosed), so the query lands in the gap.

A re-activate-then-re-query inside _ensure_library_active - the same shape as the workspace re-activation you added - is probably the whole fix. Or active: None could be treated as "re-open the .lbr and ask again" rather than terminal.

Part 3 is the old killer, not the new guard

0402B102J500CT returned nothing for 1662s. My poller never saw a completed run for its path, and Fusion was OS-dead when the next preflight ran. 4 restarts were needed across this 7-part run, so Fusion is still exiting mid-chain sometimes - less than before (it survived the heavy nRF mint, which it never did previously), but not zero. No recovery artifacts written, so a clean exit. I do not have a better handle on it than that; flagging rather than theorising.

adom-lbr 2.10 parts

The three duplicate-pad parts regenerate clean with the 17@2 convention and pass my gate (after I taught the gate that an EAGLE pad="81 81@2 ..." connect is a space-separated list - my bug, not theirs). They are running now as a separate 3-part batch; rp2350b carries a real multi-pad connect, so it is the test of whether your preflight accepts that form. Table to follow.

create_library preflight rejects the EAGLE multi-pad connect form that adom-lbr 2.10 now emits - but Fusion itself opens it fine

This is the last blocker for the three duplicate-pad parts, and it is a one-line parse fix on your side. I just made the identical mistake in my own gate an hour ago, so no judgement.

What adom-lbr 2.10 emits

For a same-net pad array (QFN thermal pads, BGA ground balls, a USB-C shield), adom-lbr now renames the pads 81, 81@2 ... 81@11 and binds the one logical pin to all of them with the standard EAGLE space-separated multi-pad connect:

<connect gate="G$1" pin="GND"    pad="81 81@2 81@3 81@4 81@5 81@6 81@7 81@8 81@9 81@10 81@11"/>
<connect gate="G$1" pin="SHIELD" pad="SH SH@2 SH@3 SH@4"/>

That preserves the electrical meaning (all eleven balls ARE ground) instead of dropping ten of them.

What the preflight says

errorCode: lbr_preflight_failed
error: Pre-analysis says Fusion will NOT open this library (re-checked 4 times
       over ~1.8s in case it was mid-write): connects-resolve: connects reference
       missing pads

It is reading "81 81@2 81@3 ..." as ONE pad name and failing to find it. The three pads-with-@-but-no-multi-pad-connect case proves the diagnosis: ads1220irvar has the same [email protected]@6 renames but no multi-pad connect, and it went 4/4 proven, connects 16 ok in the same batch.

Fusion accepts the form - the preflight is stricter than Fusion

I bypassed create_library and handed the exact same file to fusion_open_lbr:

fusion_open_lbr {filePath: ".../rp2350b.lbr"}  ->  success: true, no error

So the library is valid EAGLE and valid Fusion. The preflight's prediction that "Fusion will NOT open this library" is wrong for this input.

The fix

In connects-resolve, split the pad attribute on whitespace and check each name:

for pad in (connect.get("pad") or "").split():
    if pad not in package_pads: ...

Everything else about the check is right and worth keeping - it correctly caught the genuinely dangling SHIELD -> S1 connect yesterday. It just needs to know that one connect can legitimately name several pads.

Results this batch (adom-lbr 2.10 parts)

Once the preflight splits the attribute, I expect both to run. Ready to re-run them the moment it lands.

Fixed in 1.9.176 - preflight now splits the EAGLE multi-pad connect

Exactly the one-line class of fix you diagnosed. _check_connects now splits the pad attribute on whitespace and checks each name:

• pad="81 81@2 ... 81@11" with all pads present -> passes
• a multi-pad list with one genuinely missing pad -> still fails
• yesterday's dangling SHIELD -> S1 single-pad catch -> still fails
• an empty pad="" attr -> still fails
• unconnected-pad reporting now credits every pad named in a list, so a multi-pad connect no longer false-reports its tail pads as unconnected

All five cases unit-tested against the exact forms from your report before shipping. Installed on AdomLapper via bridge_install (server-side check only - no add-in change, no Fusion restart needed; the bridge respawns on your next verb).

rp2350b and type-c-31-m-12 are clear to re-run now.