`move_connected` leaves every wire behind and reports success

[komar3456]

move_connected leaves every wire behind and reports success

Version: Konnect v0.7.0 (konnect-pcm-v0.7.0-windows.zip, installed via PCM)
KiCad: 10.0.4 · OS: Windows 11 · Transport: stdio

move_connected is documented as "Move a symbol and stretch/shrink connected wire
stubs to preserve connections". In v0.7.0 it moves the symbol and leaves the wiring
exactly where it was, so every connection the symbol had is silently broken. The
call returns {"moved": ...} with no warning, and nothing in the response
distinguishes this from a successful drag.

Reproduction

Konnect tools only — the wiring is created by connect_to_net, so nothing here
depends on hand-placed coordinates.

create_schematic          { "path": "stub.kicad_sch" }
add_schematic_component   { "schematic": "stub.kicad_sch", "lib_id": "Device:R",
                            "reference": "R1", "x": 100.33, "y": 100.33 }
connect_to_net            { "schematic": "stub.kicad_sch", "reference": "R1",
                            "pin_number": "1", "net": "VBUS" }
move_connected            { "schematic": "stub.kicad_sch", "reference": "R1",
                            "x": 111.76, "y": 100.33 }

connect_to_net writes the stub at pin 1 exactly: wire (100.33, 96.52) → (100.33, 93.98)
with the VBUS label at the far end.

Observed

move_connected returns:

{"moved":"R1","x":111.76,"y":100.33}

In the file, the symbol moved and the stub did not:

(symbol (lib_id "Device:R") (at 111.76 100.33 0) ...   ← moved
(wire (pts (xy 100.33 96.52) (xy 100.33 93.98)))       ← unchanged
(label "VBUS" (at 100.33 93.98 0) ...)                 ← unchanged

Pin 1 is now at (111.76, 96.52); the stub still starts at (100.33, 96.52).

kicad-cli sch erc on the same file, before and after the move:

	Errors	Warnings	Messages
before move_connected	1	1	pin_not_connected (pin 2, expected — nothing attached), isolated_pin_label
after move_connected	3	1	pin_not_connected ×2, label_dangling, unconnected_wire_endpoint

So the move turned a connected pin into a disconnected one and orphaned the label.

Same result with a plain pin-to-pin wire

Not specific to stubs. Two resistors, one wire between R1.2 and R2.1 placed with
add_wire at the pin coordinates reported by get_schematic_pin_locations, then
move_connected on R1:

wire before: (100.33, 104.14) → (100.33, 116.84)
wire after:  (100.33, 104.14) → (100.33, 116.84)   ← unchanged, R1 is now at x=111.76

ERC after: 4 × pin_not_connected, 1 × unconnected_wire_endpoint.

Also: no-connect flags stay behind

In a third variant, a no-connect flag added at pin 2 with add_no_connect stayed at
its original coordinate after move_connected, producing no_connect_dangling plus
an unconnected pin at the symbol's new location — two ERC messages describing one
thing the user never did.

Expected

Either the documented behaviour — attached wire endpoints, labels and no-connect
flags follow the pins — or, failing that, an explicit refusal. The dangerous part is
not the missing feature but the successful-looking report: nothing in the response
says the schematic just lost its connections, and on a large sheet the damage is
invisible until ERC or the netlist is checked much later.

move_schematic_component documents that it does not adjust wires, which is fine and
unambiguous; this report is only about move_connected, whose contract is to
preserve the connections.

[mixelpixx]

Honesty fix on main (183b43a): move_connected now refuses with an error naming move_schematic_component as the working alternative, instead of silently delegating to the plain move and reporting connections preserved — which it had done since the first release. Its dead parameters are removed from the schema (documented in docs/API_MIGRATIONS.md); #285's new schema-parameter guard actually caught the stub advertising arguments nothing read, which is the system working. This issue stays open, relabeled as the feature it really is: a wire-carrying move needs the #120 connectivity model to know which wires to stretch and which junctions to create or prune. Anyone taking #120 should treat this as its acceptance test.

[neusse]

Linked to the coordinate and geometry correctness tracker in #575 under dependent geometry transforms.

This issue remains the focused implementation unit. Its completion evidence should verify the moved symbol, connected wire endpoints, necessary junction changes, and resulting connectivity—not only the requested symbol position. It may be implemented and merged independently; #575 supplies shared accounting rather than a monolithic prerequisite.