kicad-cli-remote: project footprint libraries (.pretty) and --schematic-parity never reach the desktop

John Lauer · ·closed by John Lauer

tools/kicad-cli-remote (installed as adom-aiflow-kicad-cli-remote, adom-aiflow 0.2.18) leaves out project footprint libraries, so native DRC and ERC report library findings that are not on the board.

What happens

  • pcb drc: send_board sends only <board>.kicad_pcb, .kicad_pro and .kicad_dru. With lib_footprint_issues enabled, every footprint from a project library reports The current configuration does not include the footprint library 'CapEncoder', because fp-lib-table and lib/CapEncoder.pretty/ never reach the desktop.
  • sch erc: send_schematic sends fp-lib-table, but follows only the sym-lib-table URIs, and only when they are files. A ${KIPRJMOD}/lib/X.pretty footprint library is a folder, so it is skipped. Every symbol whose footprint is in it gets footprint_link_issues.
  • pcb drc --schematic-parity is dropped (--*) shift), and the .kicad_sch is not sent. So the DRC JSON's schematic_parity: [] reads as a pass when parity was never checked.

Repro (KiCad 10.0.5 on a Windows desktop, 2026-10-25): a project with fp-lib-table -> ${KIPRJMOD}/lib/CapEncoder.pretty and sym-lib-table -> ${KIPRJMOD}/capencoder.kicad_sym.

  • Stock wrapper sch erc --severity-all: 6 x footprint_link_issues.
  • The same project, with both senders following fp-lib-table URIs and sending every file of a .pretty folder: ERC 0.
  • pcb drc --schematic-parity with the .kicad_sch sent: parity actually runs. A promoted-severity copy shows 4 footprint_filters_mismatch, which proves it ran, and the normal project is 0/0/0.

Fix tested locally (a patched copy, not pushed): in the send_schematic Python, loop over both sym-lib-table and fp-lib-table, and when a ${KIPRJMOD} URI is a directory, add its files. Have send_board reuse that grouping for the board's own lib tables, add kicad_sch to the sibling extensions, and pass --schematic-parity through. I can send it as a PR.

1 Reply

John Lauer ·

Fixed in adom-aiflow 0.2.19, all three. Your description held in the 0.2.18 source.

  • Schematic jobs (sch erc, sch export netlist): the board and schematic senders share one file-gathering step. It reads sym-lib-table and fp-lib-table, and a ${KIPRJMOD} entry that is a folder (a .pretty library) sends every file in it, keeping paths relative to the project.
  • Board jobs (pcb drc, gerbers, drill, pos): both library tables and the libraries they name now go too. With --schematic-parity, the schematic and its child sheets go as well: <board>.kicad_sch beside the board, or KICAD_REMOTE_SCHEMATIC, sent under the board's name because KiCad's parity check looks for that name.
  • Flags: --schematic-parity now reaches kicad-cli. --severity-exclusions, --exit-code-violations and --units pass through too.
  • aiflow's own DRC: gate, place check and adopt-board ask for parity when the run has a recorded schematic that kicad-cli can reach. Boards with no schematic run as before.
  • Checked on a real desktop (KiCad 10.0.5): parity really ran (69 findings on the buck, which are real differences such as VIN vs /VIN), and ERC gave 0. The offline test checks every file reaches the job folder on Windows and Linux.
  • Open question: parity findings are reported but don't block the gate yet. Whether they should is a separate decision.

Upgrade: adom-wiki pkg install adom/adom-aiflow, then adom-aiflow --version says 0.2.19.

John Lauer closed this ·
Colby Knox mentioned this in pull request #97 ·

Log in to reply.