KiCad - the KiCad Bridge

Ask (from John)

Please build a Linux version of the KiCad Bridge and test it on both Linux boxes below. The aim: adom-aiflow can finish a board end to end on a Linux machine that runs KiCad itself, with no Windows desktop in the loop.

Why this is needed now

On 2026-10-14/15 a Grok Bot agent designed a 12 V to 5 V / 1 A TPS54202 buck on its own Linux computer: KiCad 10 and adom-aiflow installed there, schematic, layout, ERC/DRC clean, Adom Fields solved, reworked into an Adom molecule. Write-up and clips: https://wiki.adom.inc/adom/grok-bridge/files/first-ai-pcb/README.md

adom-aiflow stopped before its sign-off. Its live stages call kicad_* verbs through Adom Bridge, and every kicad-bridge release so far (through 1.0.152) is a Windows build only:

• land route, pour, land vias, land pours (native undo steps on the live board)
• tour nets, tour 3d (IPC selection, zoom, 3D viewer)
• models (kicad_model_check)
• finish (live board validates at 0 unconnected)

The Grok computer already joined the mesh with the Linux Adom Bridge (AppImage, ab 2.1.176). It has KiCad 10 as a flatpak (org.kicad.KiCad, run under dbus-run-session; kicad and kicad-cli wrappers in ~/.local/bin, X display :3), and adom-aiflow and adom-fields. So the only missing piece is the bridge.

What looks portable

Per kicad-bridge-contributing, rust/crates/kicad-core is platform-neutral (IPC in ipc.rs, board parsing, DRC, zones, DSN, libraries), kicad-platform/src/win/ is the Windows-only part (windows, focus, menus, UIA, capture), and cargo build on Linux already compiles the neutral crates plus stubs. Everything aiflow needs for landing, pours, gate and finish goes through the IPC API. The window/UIA verbs can answer not_supported_on_platform at first, as kicad_readiness.platform already allows.

Test boxes (please test on both)

1. The Grok computer: mesh target grok-bot-vm-155244935 (Linux, user box, 8 CPUs, no GPU, KiCad 10 flatpak). The test board is /workspace/grok-buck/kicad/grok-buck.kicad_pro (private copy on john/grok-buck). It is shared by every bot on that Grok account, so leave other /workspace folders alone.
2. John's gallia container (john-galliaapril), which already runs kicad-bridge. Test it through the mesh.

Done means

• bridge_install of a Linux build on both boxes. Then kicad_readiness reports ipcApi: true with KiCad 10 running (flatpak sandbox and API socket path included), and kicad_status sees the open board.
• adom-aiflow on the Grok computer runs land route, pour, land pours, tour nets and finish on grok-buck against that box's own KiCad, and finish passes, with no Windows desktop involved.
• Window verbs either work under X11/Xwayland or answer not_supported_on_platform with a hint (never a silent ok:true).

Gotchas seen on that box

• KiCad there is a flatpak. The IPC socket lives inside the sandbox, so the bridge has to find it (or KiCad needs --filesystem / socket overrides).
• The mesh sometimes answers target_not_found for grok-bot-vm-155244935 while targets lists it reachable:true (adom/adom-bridge#240). Retry before calling the box down.
• The box's backgrounded Grok Bot UI can freeze, but that doesn't affect the bridge.