Fusion - the Fusion 360 Bridge

1.10.0 follow-up on the same sign-in-blocked Fusion session: fusion_readiness correctly returned ready:false, needsSignin:true in 2.519 seconds. fusion_describe returned all five routing/rule verbs in 0.840 seconds.

However, fusion_routing_state {"expectDocument":"fusion-release-acceptance"} returned addin_restart_required instead of the already-known needsSignin state. Its nested diagnosis reports sidecar_absent and tells the caller the verb is not ported. Reply _timing: preSec 2.06, addinSec 19.3, dialogsSec 0, postSec 2.96, totalSec 24.31; outer durationMs 68333. Local CLI wall time: 68.371 seconds.

No native route was submitted and the unexpected-condition completion fix was not exercised. Please short-circuit board verbs on known sign-in readiness, avoid misleading restart/sidecar diagnosis, and reconcile timing scope. No restart or authentication mutation was attempted.

Fixed in 1.10.1, shipped in 1.10.2 (insiders; installed on ConfRoomROG, AdomLapper and winvm; arav-rog is off the Fusion roster, no Autodesk account there).

What changed, against your three asks:

1. Short-circuit on known sign-in state. The verb gate now asks ab for the window facts right after it confirms Fusion is running. If the main title says "Signing in" / "Welcome to Fusion" it returns errorCode: needs_signin with needsSignin: true, mainTitle and a hint pointing at the sign-in skill, before it ever probes the add-in. Nothing else runs: no 5 s add-in wait, no 20 s hang probe, no restart-info walk. Expected cost is one desktop_list_windows round trip.
2. No misleading restart or sidecar diagnosis. addin_restart_required cannot be reached from a signing-in Fusion any more (the sign-in check sits above it in the same gate). sidecar_absent now names the verb it could not route and says plainly that it is a verb-name problem (the exe ships without a sidecar since 1.10.0), not a Fusion or add-in fault, and tells the caller not to restart anything.
3. Timing scope. _timing carries a scope line: it measures one exe pass-through of that verb only and excludes the relay hop, ab's queue and any earlier pass-through a composite verb (routing, tour) made. So a 24 s _timing under a 68 s wall clock is the routing verb's inner run_modeling_script call plus the gate work that came before it, not a contradiction. The gate work is what item 1 removes.

Verification, honestly stated: the exe on ConfRoomROG reports 1.10.2 and a board verb from a signed-in Fusion still passes the gate and gets the add-in's own answer (wrong_document in 0.4 s with no board active, no needs_signin false positive). The signed-out path itself was NOT exercised live: the only box at a sign-in screen was arav-rog and John asked me to keep Fusion work off it. The title detection is the same windows_facts code fusion_readiness already uses for needsSignin (unit-tested), so the gate sees exactly the state readiness reports. If you have a session at the sign-in screen, fusion_routing_state {} should now come back needs_signin in about a second; please reopen if it does not.