diff --git a/docs/research/vehicle-probe.md b/docs/research/vehicle-probe.md
index 96dbe62..ff135e6 100644
--- a/docs/research/vehicle-probe.md
+++ b/docs/research/vehicle-probe.md
@@ -63,3 +63,15 @@ Scanned: the 9 mods in `C:\Users\Public\mod.io\10640\mods\` (e.g. `devers_1`, `m
 - `api.engine.util.transport.calcPosition(edge.geometry, t)` gives a world position along an edge geometry.
 - `burntnuggie_line_priority_1` sets line **reservation** priority via `makeLineUpdateCmd`. That's path reservation for rail, not road traffic.
 - `makeVehicleSetLineCmd` to the vehicle's own line: the lanes planned ahead change, but the engine re-plans them on its own all the time (the leader's changed too, without a command). It doesn't force a lane change, and with `stopIndex=0` it re-targets the line's first stop.
+
+## Segment rebuild via `replaceSegment` (run 2026-10-05 ~20:55 UTC)
+
+- `api.engine.util.proposal.replaceSegment(seg)` plus `makeWorldBuildProposalCmd(p, nil, true, true)` from engine state **works**: segments 29702, 21304 and 29012 never appeared again after their rebuild (they got new ids).
+- **After all 3 rebuilds, the follower and leader ended up in different lanes** (`country_new_medium`, 2 lanes per direction). Each time the *leader* moved from lane 4 to lane 3, either right away or one segment later, and the follower stayed in lane 4.
+  - #1 (seg 29702): follower 29251 at 50.4 m behind leader 29852 at 76.7 m. Afterwards, on seg 29699, 29251 is at 29.1 m (lane 4) and 29852 at 20.2 m (lane 3). 29251 drives 18.6–19.6 m/s, above its earlier 16.67, and stays a segment ahead. **The follower got past.**
+  - #2 (seg 21304): 29851 (leader) moved to lane 3 on seg 27833. The lanes split, but the order was unchanged.
+  - #3 (seg 29012): 29251 (leader) moved to lane 3 on seg 29322.
+  - Without rebuilds, the same pair stayed together in lane 4 for 6 segments (first probe). The engine also switches lanes by itself at segment ends sometimes, so 3/3 is suggestive, not proof.
+  - Likely cause (human's hypothesis): the vehicles' `MovePath` refers to lanes of the removed segment, so the engine must re-attach them to the new segment and re-plan, and a vehicle can land in a different lane.
+- **Debug `MovePath` exchange is unusable from engine state**: `api.cmd.sendCommand(api.cmd.debug.makeComponentExchangeCmd(v, movePath))` fails with `Error decoding argument #3` even **without** a callback. So the earlier error wasn't caused by the callback. The only untried route is the GUI thread.
+- Not yet tested: a rebuild on a two-way (one lane per direction) road.
diff --git a/mod/_metadata/modinfo.json b/mod/_metadata/modinfo.json
index aaee126..a6a8661 100644
--- a/mod/_metadata/modinfo.json
+++ b/mod/_metadata/modinfo.json
@@ -9,7 +9,9 @@
     "summary": "Vehicle overtaking (WIP)",
     "name": "Overtake",
     "tags": [
-        "script"
+        "Script Mod",
+        "Car",
+        "Road"
     ],
-    "url": ""
+    "url": "https://git.arthurerlich.de/haylan/tpf3-overtake"
 }
diff --git a/mod/content/overtake_probe.script.tl b/mod/content/overtake_probe.script.tl
index 183769c..d103d60 100644
--- a/mod/content/overtake_probe.script.tl
+++ b/mod/content/overtake_probe.script.tl
@@ -10,7 +10,7 @@ local INTERVAL = 2.0
 local MAX_GAP = 40.0
 local MAX_REBUILDS = 3 -- hand-built proposals were silently rejected; now via api.engine.util.proposal.replaceSegment
 local MAX_SETLINES = 0 -- set-line disabled: lanes ahead get re-planned by the engine anyway, no forced lane change
-local MAX_JUMPS = 3 -- EXPERIMENT: debug component exchange of MovePath with pathPos moved past the leader
+local MAX_JUMPS = 0 -- dead: sendCommand(makeComponentExchangeCmd(...)) fails in engine state even without a callback
 local JUMP_AHEAD = 15.0
 local elapsed = 0.0
 local ticks = 0