Live obstacle-aware Fusion routing

The new fusion_plan_route verb calculates an explicit path between two named pads from a fresh snapshot of the active Fusion board. It runs bounded, orthogonal two-layer A* using the same conservative clearance model as fusion_route_net. It does not use Freerouting or another external router. Planning is read-only and returns the input revision plus plan.route and plan.items; commits still use the existing revision-guarded mutation verb.

Required inputs: expectDocument, boardId, expectedRevision, net, fromPad, toPad. Defaults: 0.25 mm trace, 0.6 mm via / 0.3 mm drill, 0.5 mm grid, vias allowed, via cost equivalent to 5 mm of trace, 25,000 expanded nodes and 3,000 ms time limit. Grid ranges from 0.1 to 5 mm; limits are capped at 100,000 nodes / 5,000 ms. allowVias:false finds a same-layer route. Returned paths are validated again with the shared geometric preflight.

The isolated test board has three SMD pad pairs and two existing copper barriers on different layers. No routing waypoints are supplied to the planner. The first pair demonstrates a same-layer detour; the second allows vias; the third has a clear direct route. Both original barriers must remain unchanged.

Native insertion regression

The first live take stopped at a read-back mismatch: inserting a nominal 0.6 mm via at x=21, y=20 beside a 1 mm top-layer barrier at x=22 caused Fusion to push the barrier. The failure was retained in take-01/; no mutation was replayed.

The corrected build sets CHANGE DRILL before VIA, instead of inserting a via using the previous drill setting and changing it afterward. It also uses a conservative via insertion radius of max(diameter/2, drill+0.3 mm) for the preflight and search. This reserves extra space for native insertion behavior. The regression test rejects the original tight insertion point. Exact copper read-back remains essential: nominal exported dimensions alone do not model every aspect of Fusion's native router or effective design-rule dimensions.

Autodesk documents the shared drill setting and design-rule-dependent via size. This source supports the drill-setting change; the observed shove and extra clearance regression come from the live test evidence.

Scope

This is a bounded two-pad path planner, not a full PCB autorouter. It does not rip up or shove existing copper, optimize routing order across all nets, route differential pairs, tune lengths, or model polygons and arbitrary stackups. It retains the rectangular, two-layer, straight-copper restrictions of the existing preflight. It may reject legal paths conservatively or exhaust its grid/node/time budget. Final acceptance always uses native Autodesk DRC.

The planner's grid search can find different paths at different resolutions; it does not guarantee the globally best manufacturable layout. A failed mutation can leave partial copper or a native shove, so inspect current state before deciding how to recover. Planning failures do not create copper.

Verified live result and videos

take-04/final.json records all three pad pairs connected, 10 total segments (8 added, 2 original barriers), 2 vias and native Autodesk DRC with zero errors, warnings and airwires. The calculated lengths were 54, 40 and 40 mm. take-03 also passed routing; its recorder failed because the Fusion window was minimized. The runner now checks window and capture dimensions before creating copper and finalizes both recordings in finally.

fusion-obstacle-live-3x.mp4 is the 19.93-second share cut; fusion-obstacle-live-1x.mp4 is the 49.83-second version for reading live results. Both are 1920×1080, 30 fps and fully decoded successfully. Both were delivered to C:/Users/john/Documents/Adom Routing Demos; the normal-speed file was opened and visually verified in Windows Media Player.

The existing AdomActivityPalette is reused, including its branding and close handler. Its shared _shell_html component has optional routing fields and an SSE feed. ../live_panel.py hosts that page and feed in the container; Windows Fusion reaches it at the verified http://localhost:8893/ endpoint. The native message API returned empty acknowledgments on this Fusion instance, so the demo uses SSE instead of repeated page reloads. Each displayed event acknowledges DOM application before the next copper edit. A missing acknowledgment stops the demo. This is presentation evidence, separate from native PCB validation.

AB records the Fusion editor and its owned palette as two native window captures, then the renderer aligns them using call-start timestamps. Initialization can introduce a fraction-of-a-second offset; the edit manifest records this limit. The live text is recorded video, not reconstructed captions. The short take keeps calculation/check displays, trims part of the completed-state tail and adds a five-second final hold. take-04/panel-events.jsonl is a polling record started during this take; future runs log every publish and acknowledgment.

To reproduce after preparing an isolated unrouted board and discovering HWNDs:

python3 demo/routing/live_panel.py
# In another terminal:
python3 demo/routing/prepare_live_panel.py --document YOUR_EXACT_BOARD
python3 demo/routing/obstacles/record_obstacles.py \
  --document YOUR_EXACT_BOARD --take YOUR_NEW_TAKE \
  --hwnd FUSION_HWND --palette-hwnd ADOM_PALETTE_HWND

Verify both windows visually and fit the palette beside the board before recording. prepare_live_panel.py changes the existing palette URL once and preserves its close behavior. Keep the container server alive while that display is in use. The optional component changes do not require replacing the loaded add-in or restarting Fusion. The installed native routing runtime remains 1.10.0-dev.routing.4, pinned for development.