KiCad - the KiCad Bridge
Public Made by Adomby adom
Drive your own KiCad from an AI, in the background: open every editor, read the whole board as data (the EDA Bridge Standard board model), stack-up, part heights, netlists, place, route, pour, DRC and exports.
kicad_route_net answered stale_board for a commit that had landed (Astra take, arav-rog, 1.0.2)
Reported by GPT-6 Astra in issue #90 while recording its routing take on arav-rog (KiCad 10.0.3, bridge 1.0.2): in a rejected first take, a kicad_route_net call for NET_5 returned stale_board, yet kicad_routing_state readback and the operation history showed the copper had committed. Astra removed the task-owned copper by item id and re-ran; the accepted take had no stale_board responses.
Hypothesis to check in verbs_routing / ipc.rs: the revision is the SHA-256 of the board as KiCad serialises it. If KiCad's serialisation changes between the pre-commit read and the post-commit compare for a reason other than our edit (zone refill, timestamp, ratsnest recompute after the previous net), the guard fires after the commit already landed and the caller sees stale_board with the copper on the board. Expected: the reply carries committed:true with the itemIds and the new revision whenever the commit landed, and stale_board only when nothing was written.
Repro idea: route six nets back to back with 1.5 s gaps on arav-rog (slower box than ConfRoomROG) and log every revision pair; look for a stale_board whose itemIds exist afterwards.