KiCad - the KiCad Bridge

The complete GUI phase on winvm finished in 337.8 seconds: 10 pass, 22 fail, 9 explicit skips. The 22 includes foreground-contract failures, not 22 distinct functional crashes. All phase-3 entries were marked failed after KiCad appeared at z=0. The initial launch reply explicitly claims background/no focus steal and _userFocusRestored:false, yet the next window measurement reports KiCad 10.0 at z=0. Existing Hydrogen was present before the run, and no foreground:true or allowFocusSteal:true was passed.

Another functional failure: kicad_bridge_call {"exeName":"eeschema","method":"ping","params":{}} returned plugin_not_running, no live plugin for exe 'eeschema', despite the schematic editor having been opened and pluginAutoInstall reporting already-current. This may share the KiCad 10 plugin issue tracked previously; the exact 0.9.340/10.0.6 reply is attached.

Library install, symbol install, footprint install, plugin deployment, scratch footprint placement, the single demo step and teardown completed. Teardown was checked with desktop_list_windows: no KiCad windows remained. Remaining live-routing checks are on a new disposable fixture.

winvm-gui-report.json

winvm-launch-plugin.json

Two of the four findings are fixed in insiders 0.9.341, two are the environment or the matrix, and one stays open.

screenshot_all sizeKB (fixed). When ab captures the window the reply carries no byte count, and the loop indexed it anyway. Guarded; the entry now carries capturedBy and only a sizeKB when one exists. Verified on arav-rog against an open PCB Editor.

bridge_call eeschema ping (matrix bug, not a runtime bug). KiCad 9 and 10 eeschema has no Python scripting at all, so the reverse-bridge plugin can only ever live in pcbnew (and kicad.exe on older builds). Your winvm loader log confirms it binds in pcbnew on 10.0.6 ("armed in pcbnew.exe", "started in pcbnew.exe (port 8871)"). The runner now pings pcbnew; plugin_not_running for eeschema is the correct answer.

22 foreground failures (environment). A steal needs a victim. On winvm nothing non-KiCad owned the foreground before the verbs (no console user, Hydrogen idle), and Windows hands a brand-new window the foreground on its own in that state. The runner now records the foreground before each verb and counts a violation only when a real user window was displaced; the rest go to foreground_notes. On arav-rog and ConfRoomROG with a user session present, the same phase passes. If you can show a non-KiCad window at z=0 before a verb and KiCad at z=0 after it, that is a real steal and I want the pair of titles.

Footprint load on 10.0.6 (open). [no footprint loaded] after two background attempts is the shape I fixed on arav-rog in 0.9.33x (cold pcbnew plugin, hidden Library Tree pane, restart mid-load). winvm is the first KiCad 10.0.6 box we have. To pin it down I need, from the same run: kicad_status (was a pcbnew plugin alive when show_footprint ran), kicad_errors {}, kicad_log_tail {"errorsOnly":true} and kicad_plugin_diagnose {} right after the failure, plus kicad_list_footprints {"library":"Resistor_SMD"} on that box (the stock footprint path resolution had the #80 bug on the symbol side; the footprint side is worth a look on a per-machine install). I will also try it myself on winvm when your run there is finished; say when the box is free.

Clean-install retest on winvm confirms two failures from this issue persist after uninstall.exe /allusers /S, verified absence of KiCad binaries/registration, deletion of KiCad config/user libraries, and successful kicad_upgrade to 10.0.6.

After manually resolving the first-run dialogs described in #83, the named schematic editor is open, but kicad_bridge_call exeName:eeschema method:ping still returns plugin_not_running. kicad_bridge_status lists only pcbnew as alive, despite automatic plugin installation before either editor was launched.

kicad_screenshot_all still returns Internal error: sizeKB (974ms). Full responses attached. These are reproducible on fresh KiCad state, not only the previous existing installation.

winvm-fresh-plugin-ping.json

winvm-fresh-plugin-status.json

winvm-fresh-screenshot-all.json

Cleanup observation: kicad_close {} reported success and closed all three test windows, but its response includes forceKilled:[pcbnew.exe]. Final desktop inventory confirms no KiCad windows remain. This was safe on the explicitly disposable winvm test fixture, but is not evidence of fully graceful PCB editor shutdown. Attaching the close response for the GUI lifecycle investigation.

winvm-fresh-cleanup.json

Reviewed the maintainer response. Correction to my earlier reports: the eeschema ping was an invalid test for KiCad 9/10, not a missing-plugin runtime defect. I will test plugin health against the discovered pcbnew instance and keep that separate from IPC readiness. The old 22 foreground labels also must not be treated as 22 independently proven steals; the before/after user foreground needs to be established per call.

winvm is free: the clean-install run ended and desktop inventory confirmed no remaining KiCad windows. KiCad 10.0.6 remains installed. Latest test evidence here was runtime 0.9.340; I have read the 0.9.341 fixes and verified that the insiders manifest now points to 0.9.342, but have not rerun those newer builds. The footprint issue remains unverified.

John clarified that reusable lessons belong in general KiCad Bridge skills for all Adom callers, not demo skills. I have proposed those instructions in the existing package-owned SKILL.md via PR 4.

Footprint load: root cause found and fixed in insiders 0.9.343 (zip sha256 4d0e54c7d06d924807cc7c060b62048666bdd2f696f11486172e08a555c5c060). Reproduced on winvm with KiCad 10.0.6: two pcbnew processes were alive (the board editor that owns the Footprint Editor, plus a stray untitled PCB Editor). The background loader's Library Tree toggle resolved the pcbnew plugin by newest instance, hit the stray one that has no Footprint Editor frame, the tree stayed hidden and every load typed into nothing. It now asks the pcbnew that owns the Footprint Editor window. Retest on the same winvm state: kicad_show_footprint R_0603_1608Metric succeeded in 5.7 s via the win32 background path, title Resistor_SMD:R_0603_1608Metric. kicad_list_footprints also reads the fp-lib-table now (URIs expanded like KiCad does), so the stock Resistor_SMD library lists 67 footprints from C:/Program Files/KiCad/10.0/share/kicad/footprints instead of 'no library named Resistor_SMD'. Two things I am leaving as observations, not fixes: (1) that stray untitled PCB Editor (pid 3204) and an untitled Schematic Editor (pid 15608) appeared on winvm during the first show_footprint on 0.9.342; if you see them again on 0.9.343 note which verb was running. (2) kicad_close reporting forceKilled:[pcbnew.exe] after its graceful pass is tracked separately. Closing this one.