kicad-cli-remote is Windows-only (cmd, %TEMP%, backslashes): gate fails on a Linux desktop now that kicad-bridge runs there

Overview Files Skills Discover Packages Releases Dependencies Issues10 Breadcrumbs Pull Requests Activity

Closed feature request

John Lauer · 1mo ago ·closed by John Lauer

Ask: let adom-aiflow-kicad-cli-remote run on a Linux desktop. kicad-bridge now has a Linux build (adom/kicad-bridge#127, #128), tested on the Grok computer (grok-bot-vm-155244935, Debian 13, KiCad 10.0.7 Flatpak). With it, the live stages work from a container with --target grok-bot-vm-155244935. Measured today on a copy of grok-buck:

Worked through the bridge: start --target --remote-board, route (empty plan, board already routed), land route, pour, land vias, land pours (reached the live preflight, which refused zones_intersect against the existing GND pour, correctly), measure (KiCad's fills, read live), tour nets (/GND 33 items and /VIN 21 selected and framed, screenshots saved) and verify-pours.
Blocked: gate (and every offline kicad-cli step). tools/kicad-cli-remote is Windows-only. It asks shell_execute for echo %TEMP%, builds cmd command lines (mkdir ... 2>nul &, rmdir /s /q, dir /b) and replaces every / with \. On Linux the DRC call becomes sh: 1: \home\box\.local\share\adom-kicad-bridge\bin\kicad-cli: not found and the gate reports "no report came back".

What a Linux path needs (I used a 40-line shim to prove it, and the gate then passed on the box's KiCad: 0 new errors, 0 unconnected):

Detect the target OS (adom-bridge targets gives os; or kicad_status.platform.os from kicad-bridge 1.0.56+).
Linux: send the board with its .kicad_dru and .kicad_pro to a folder under the user's home with send_files (not /tmp: a Flatpak KiCad has its own /tmp; kicad-bridge's launchers share the host's /tmp, but home is safe either way), run kicad_status.install.kicadCli with the same arguments through run_script {"interpreter":"bash"} with forward slashes, and pull_file the report.
Pass probe calls (pcb drc --help, version) through the same way, since the gate checks for --refill-zones.

Smaller, same run: the board's nets are hierarchical (/GND, /VIN), and the spec Grok wrote names them GND, VIN, so pour refused "the board has no pads on that net". netlist check already treats /VIN and VIN as equal; the spec's pours, nets and hot.tabNet could do the same, or the refusal could say that the board has /GND.

1 Reply

John Lauer · 27d ago

Fixed in adom-aiflow 0.2.3. adom-aiflow-kicad-cli-remote now detects the desktop's OS (KICAD_REMOTE_OS, then kicad_status, then adom-bridge targets). On Linux it sends the job to a folder under the user's home (not /tmp, for Flatpak), runs the bridge-reported kicad-cli through run_script with bash and forward slashes, pulls the outputs back and cleans up. Windows behaves as before. It also supports version, sch erc and pcb export step now. Tested on grok-bot-vm (KiCad 10.0.7 Flatpak): gate 0 new errors and 0 unconnected, export (2/2 copper, 34 drill hits, 31 CPL, 16 BOM), netlist check 38=38, schematic check with ERC 0 errors. The same set passes on Windows (KiCad 10.0.5). The smaller ask is in too: spec pours, nets and hot.tabNet naming GND match a board /GND when that is unambiguous, and the pour refusal names the nearby board net. Upgrade: adom-wiki pkg install adom/adom-aiflow, then adom-aiflow --version says 0.2.3.

John Lauer closed this · 27d ago