EDA Bridge Standard: one way for an AI to drive every PCB tool

altium-lane: Altium answers thermal_vias and via_fence from the engine (altium-bridge source dd71650, unreleased 0.2.79; it ships in the next batch).

• The bridge passes {board: routing_state, rules: read_rules, args} to the engine, then places apply.args.vias as one undo step and answers applied / failed / revision. With dryRun it returns the plan unplaced.
• Its own copies are gone: features.rs keeps only board_features, which uses the engine's plan_stitching_with, corners, region_of and summary.
• Every check reply now reports the engine's own engine string; the hand-written version is removed.
• Tests: bridge 165 and engine 50 unit + 5 conformance pass, vendored at standard 0.7.0 / engine 0.4.0. Live on Altium Develop (DESKTOP-BAR6S0F), via_fence on the lane board plans through the engine, and thermal_vias refuses U1's SOIC with pad_has_no_net as before.

fusion-lane: fusion-bridge 1.13.3 (public) answers thermal_vias and via_fence from engine 0.4.0. Fusion's own planners are gone.

How:

• The engine plans.
• Fusion places the plan's apply.args.vias, reads every via back, and undoes them all on a mismatch.
• The reply is the engine's, plus applied, failed and revision.
• dryRun returns the plan with apply as fusion_place_vias, which now also takes size.
• The board's via rule goes to the engine as {kind: via, sizeMm, drillMm}, so planned.via.from is "the board's via rule".
• Replies carry the engine's own engine.

Compared with fusion-bridge 1.13.2's planners on fusion-lane's copy of BQ25792:

• thermal_vias L2 pad 2: identical, the same 4 points.
• Placed live: read back and seen in Fusion as a 2×2 grid in the pad. A second plan answers already_has_vias. I removed them again.
• via_fence on D_P/D_N (viaNet PGND): the same 2 vias, within 0.6 mm of mine. The engine has 108 candidates against my 214.
• via_fence {edge: true}: 18 vias against my 26, at the same 0.8 mm inset.
  • The engine steps at exactly the pitch from the corner inset; mine divided each edge evenly.
  • It also keeps 18 of 76 candidates against my 26 of 80, so it's stricter about what is clear. I've taken it as is.

The daily battery: 161 pass, and the only 5 failures are APS sign-in ones.

kicad-lane: done in kicad-bridge 1.0.72 (insiders): kicad_thermal_vias and kicad_via_fence are planned by the vendored engine (adom-eda-checks 0.4.0).

• The engine plans in the standard frame. The bridge turns the points into KiCad's frame and places them as before: live as one Undo step, or into the closed file, after KiCad's DRC shows no new error either way.
• The via is the project's Default net class, passed as {kind: "via", sizeMm, drillMm}, so planned.via.from reads "the board's via rule". The fence clearance defaults to the board's largest clearance rule.
• Replies carry the engine's engine field; the hand-written version is gone, and a test ties VENDOR.md to adom_eda_checks::VERSION.

On the ESC board (KiCad 10.0.7):

• thermal vias in Q1 placed 16 vias with no new DRC errors, and a second run placed none (16 existing);
• an edge fence on GND placed 118 vias with no new DRC errors.

Full battery 301/0/1. Reference: reference/kicad-1.0.72.json. Engine 0.4.1 (stacked) comes in the next batch.

All three bridges answer these from the engine now:

• Altium: 0.2.79 source (dd71650), ships in its next release.
• KiCad: 1.0.72 on insiders. placement_check is now exact.
• Fusion: 1.13.3, public.

Each reply carries the engine's own engine field. Fusion and Altium have taken 0.4.1 (stacked in placement_check); KiCad takes it in its next batch. Closing.