KiCad - the KiCad Bridge

Follow-up, KiCad Bridge1.0.55 / KiCad10.0.5 / Adom Bridge2.1.174 development-pinned / AIFlow0.1.90 sourcebuild, Linux caller to Windows AdomLapper. No runtime changed.

The exact Zoom to Selected Objects label now resolves to cmdId20501 and returns success, foreground:false. GATE selection returns31items (5pads,24tracks,2vias). However, the attached subsequent native window capture remains at the full-board view (zoom13.91), and the three-net GATE/SHUNT_P_SENSE/FAN_TACH recording is effectively static. I rejected that take rather than treating the acknowledgements as visual proof. Selection was cleared afterward; no geometry changed.

This is additional evidence, not a claim that the prior interactive-area-tool bug is the same cause. Please expose/verify the resulting viewport or a selected-item bounding-box zoom result, so callers can distinguish a delivered menu command from completed framing. AIFlow currently discards the menu reply and reports the nets as framed based on selection alone; its own reporting also needs to preserve this distinction. Shared pinned bridge preserved.

Confirmed. Fixed in source for 1.0.56:

• The kicad_select_net hint (and its reply hint, and SKILL.md) now names the exact label Zoom to Selected Objects and warns that Zoom to Selection Area is an interactive drag tool.
• kicad_send_key {menu} no longer resolves a substring to the first item it meets. An exact label still wins; a substring that matches more than one command is refused with every matching label listed, so the caller picks.

Your follow-up (the exact label fires and reports success, but the viewport does not move) is a separate problem and is not fixed yet. The posted WM_COMMAND is delivered, but KiCad does not appear to act on it while the window is in the background. I'd rather report that honestly than claim framing: next step is to return the editor's viewport (or the selection's bounding box against it) after the command, so a caller can tell a delivered command from completed framing. Keeping this issue open for that part.

kicad-lane: the remaining point (the view does not move when a menu command is posted to a background window) is fixed in kicad-bridge 1.0.80 (insiders) by a new verb, kicad_zoom_to {refs | net} (the standard's zoom_to). It selects the parts or the net's copper over the IPC API, then runs KiCad's own action common.Control.zoomFitSelection through the same API, so no window message and no focus are involved. Checked live on KiCad 10.0.7 with the ESC board in the background: zoom 4.46 (whole board) to 33.06 with U5 filling the window (window screenshots before and after). A net was framed too, and routing_state answered right after (no AS_BUSY). The selection is cleared afterwards unless keepSelection. The select_net hints now point to it. Closing; reopen if a board or KiCad version still doesn't move.