Handoff: M5 kein-WLAN-Zweig gegen echtes Gerät bestätigt

Testgerät hat keinen WLAN-Chip -- korrekt erkannt, Konfiguration lief
ohne WLAN-Befehle sauber durch. Der eigentliche SSID/Passwort-.set-Pfad
bleibt ungetestet, dafür fehlt ein Gerät mit echtem WLAN-Chip.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HReLXMbmPvtQ23p1iWiJNW

HANDOFF.md

@@ -1,10 +1,12 @@
 # RouterOS Assistant — Handoff
 
 Stand: nach M5 (WLAN-Schritt). M1–M4 gegen ein echtes physisches
-Mikrotik-Testgerät (RouterOS 7.24.2) verifiziert; M5 ist gebaut und
-getestet (Build + Unit-Tests grün), aber noch **nicht gegen echte
-WLAN-Hardware verifiziert** — unklar, ob das Testgerät überhaupt einen
-WLAN-Chip hat.
+Mikrotik-Testgerät (RouterOS 7.24.2) verifiziert. M5: der
+"kein-WLAN-erkannt"-Zweig ist gegen das echte Testgerät bestätigt (Gerät
+hat keinen WLAN-Chip, wurde korrekt erkannt, Konfiguration lief sauber
+durch ohne WLAN-Befehle). Der eigentliche SSID/Passwort-`.set`-Pfad
+(Sicherheitsprofil anlegen + Interface konfigurieren) ist **weiterhin
+ungetestet** — dafür fehlt ein Gerät mit echtem WLAN-Chip.
 
 ## Ziel
 
@@ -137,11 +139,12 @@ selbst separat als `@ObservedObject` halten.
   SSH. Der REST-`apply()`-Pfad (`POST`/`PATCH` mit JSON-Body,
   `findItemID` für `.set`) ist nur gegen Mocks getestet, nicht gegen ein
   echtes Gerät mit aktiver REST-API.
-- **WLAN-Schritt (M5) komplett ungetestet gegen echte Hardware** — nur
-  Build+Unit-Tests grün. Unklar ob das Testgerät WLAN hat. Vor Vertrauen
-  in diesen Schritt unbedingt gegen ein Gerät mit WLAN-Chip testen —
-  sowohl den Legacy-`/interface wireless`-Pfad als auch die Erkennung
-  von `wifi`-typisierten (neuerer Treiber, nicht unterstützt) Interfaces.
+- **WLAN-`.set`-Pfad (M5) ungetestet gegen echte Hardware** — der
+  "kein WLAN"-Zweig ist am echten Testgerät bestätigt (kein WLAN-Chip,
+  korrekt erkannt), aber Sicherheitsprofil-Anlage + SSID/Passwort-`.set`
+  auf einem echten `/interface wireless`-Interface noch nie gegen ein
+  Gerät mit WLAN-Chip gelaufen. Vor Vertrauen in diesen Pfad unbedingt
+  an einem Gerät mit Legacy-WLAN testen.
 - **Neuer RouterOS-WiFi-Treiber (`/interface wifi`, wifiwave2/802.11ax)
   nicht unterstützt** — wird erkannt und im UI erklärt, aber nicht
   konfiguriert. Eigener Umbau nötig (andere Menüstruktur), falls
@@ -155,7 +158,9 @@ selbst separat als `@ObservedObject` halten.
 - ✅ M4: VLAN-Schritt (separates virtuelles Netz, kein Port-Tagging)
 - ✅ M5: WLAN-Schritt (SSID/Passwort, echte `.set`-Operation im Befehlsmodell,
   nur bei erkanntem Legacy-Wireless; neuer WiFi-Treiber erkannt aber nicht
-  unterstützt) — **gebaut, aber noch nicht gegen echte WLAN-Hardware getestet**
+  unterstützt) — "kein WLAN"-Zweig gegen echtes Gerät bestätigt, der
+  eigentliche SSID/Passwort-`.set`-Pfad **weiterhin ungetestet** (kein
+  WLAN-Chip am Testgerät)
 - ⬜ M6: Firewall-Schritt (sicherer Standard: NAT/Masquerade, WAN→LAN blocken)
 - ⬜ M7: Härtung — SSH-Hostkey-TOFU, Fehlerzustände, Politur, ggf. REST-Schreibpfad
   gegen echtes Gerät mit aktivem `www-ssl` verifizieren