HANDOFF.md: .id-Positions-Überlagerung live nachgeprüft (Bug 15)

Live-Vergleich :put [Pfad find] vs. print terse bei /ip address,
/ip route, /ip dhcp-server lease — Reihenfolge stimmte in allen drei
Fällen überein, kein erneuter Fehlgriff reproduzierbar. Entkräftet
Bug 15 nicht (RouterOS dokumentiert die Stabilität nirgends);
Timing-Race bei dynamischen Menüs (Lease-Tabelle) als Arbeitshypothese
festgehalten, echte Behebung bleibt offen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

HANDOFF.md

@@ -644,6 +644,24 @@ wiederholen.
   Menü — ob und wo das dort ebenfalls falsch zuordnen kann, ist nicht
   untersucht. Sollte bei unerklärlichem Verhalten dort (falsches Item
   geändert/gelöscht) als erste Verdachtsquelle geprüft werden.
+  **Nachtrag 2026-09-16:** live an `/ip address` (3 Einträge), `/ip route`
+  (4 Einträge) und erneut `/ip dhcp-server lease` (2 Einträge) geprüft
+  (`:put [<Pfad> find]` gegen einzeln per Filter ermittelte echte `.id`s
+  je Zeile verglichen) — in allen drei Fällen stimmte die Positions-
+  Reihenfolge diesmal exakt. Kein erneuter Fehlgriff reproduzierbar,
+  **aber das entkräftet Bug 15 nicht**: RouterOS dokumentiert nirgends,
+  dass die Reihenfolge von `:put [<Pfad> find]` und `print terse` stabil
+  identisch ist, und beide werden als zwei getrennte SSH-Befehle
+  nacheinander abgesetzt. Arbeitshypothese, unbestätigt: bei `/ip
+  dhcp-server lease` handelt es sich um eine reine Timing-Race — die
+  Lease-Tabelle ändert sich laufend durch verbindende/trennende Geräte,
+  eine Umsortierung zwischen den beiden Befehlen (statt einer grundsätzlich
+  falschen Zuordnung) würde erklären, warum Bug 15 dort auftrat, bei den
+  heute getesteten, weitgehend statischen Menüs (Adressen, Routen) aber
+  nicht. Für statische Menüs also vermutlich unkritisch, für Menüs mit
+  häufig wechselnden dynamischen Einträgen (DHCP-Leases, Verbindungs-
+  Tracking-Tabellen, falls je generisch angebunden) weiterhin als riskant
+  einstufen.
 - **WLAN-`.set`-Pfad (M5) weiterhin ungetestet gegen echte Hardware** —
   nur der "kein WLAN"-Zweig ist bestätigt (zwei Testgeräte, beide ohne
   WLAN-Chip). Sicherheitsprofil-Anlage + SSID/Passwort-`.set` auf einem
@@ -1319,12 +1337,15 @@ Claude-Memory `future-language-support.md` für Details.
    beobachtet, Apply lief trotzdem durch), aber auf Dauer Regel-Bloat —
    bei Gelegenheit auf "vorhandene identische Regel überspringen"
    umstellen.
-7. **`.id`-Positions-Überlagerung (`fetchMenuItems`) auf weitere Menüs
-   prüfen** — live als falsch bestätigt für `/ip dhcp-server lease`
-   (Bug 15). Betrifft potenziell jedes `.set`/`.remove` im Experte-Tab.
-   Am ehesten zu prüfen: bei einem Menü mit mehreren gleichzeitig
-   vorhandenen Einträgen `:put [<Pfad> find]` und `<Pfad> print terse`
-   unabhängig ausführen und die Reihenfolgen von Hand vergleichen.
+7. ~~`.id`-Positions-Überlagerung (`fetchMenuItems`) auf weitere Menüs
+   prüfen~~ — am 2026-09-16 live an `/ip address`/`/ip route`/erneut
+   `/ip dhcp-server lease` geprüft, keine erneute Fehlzuordnung
+   reproduzierbar (siehe "Bekannte Einschränkungen" oben für Details +
+   Timing-Race-Hypothese für dynamische Menüs). Damit fürs Erste
+   ausreichend untersucht — echte Behebung (z.B. `fetchMenuItems` auf
+   Einzel-Lookup statt Bulk-`find`+Positions-Zip umstellen) bleibt
+   offen, aber ohne aktuell reproduzierbaren Schadensfall nicht
+   dringend.
 8. **Router wurde zwischen M12 und M13 vom Nutzer komplett auf
    Werkseinstellungen zurückgesetzt** ("damit wir sauber weitermachen
    können"), im Zuge des ersten M13-Testlaufs (Bug 18, Login-Sperre)