Reboot-Abnahme ap2: slaves-datapath und CAPWAP ueberstehen den Neustart

ap2 durchgestartet, nach 40 s wieder da. slaves-datapath=dp-caps-slaves
steht noch, der CAP findet crs326-core durch die gehaertete input-Kette
wieder (MNDP/CAPWAP korrekt offen — seit TP5 Etappe 4 nie getestet), die
sieben Slave-VAPs kommen als dynamische Bridge-Ports mit pvid 30/40/50/90
von selbst zurueck. Abnahme per frischer Lease: IOT 10.40.30.8 nach 30 s.

Nebenbefund: /system reboot ist ueber MikroMCP auf 7.24 nicht machbar
(Tool sendet unbekanntes delay, run_command per Deny-Policy gesperrt).

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

CLAUDE.md

@@ -50,7 +50,7 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`,
 
 ## Tooling
 - **MikroTik (core/branch/ap1/ap2):** MikroMCP-Server live → `mcp__mikromcp__*`-Tools (routerId `crs326-core`/`crs326-branch`/`ap1`/`ap2`).
-  Reads immer safe; Writes mit `dryRun:true` previewen, dann `apply_plan`. **Passwort setzen via `manage_user set-password`** (`/user set*` ist per Deny-Policy blockiert). `bridge/vlan/set` nur auf `[find … and !dynamic]`.
+  Reads immer safe; Writes mit `dryRun:true` previewen, dann `apply_plan`. **Passwort setzen via `manage_user set-password`** (`/user set*` ist per Deny-Policy blockiert). ⚠️ **Reboot geht auf ROS 7.24 gar nicht ueber MikroMCP:** das `reboot`-Tool sendet `delay`, die REST-API kennt den Parameter nicht (`unknown parameter delay`), und `run_command` ist fuer `/system reboot*` gesperrt — Weg ist `sshpass -p "$PW" ssh admin@<ip> "/system reboot"` (PW aus `~/.secrets`, im Output maskieren). `bridge/vlan/set` nur auf `[find … and !dynamic]`.
 - **~~ALLNET-Switch (sw1)~~:** ❌ **Gerät ausgebaut 2026-08-08** → der Telnet-Runner unter `switch/` ist **Archiv, nicht mehr ausführbar** (kein Endpunkt). Siehe `switch/README.md`. Nicht mehr als Werkzeug anbieten.
 - **~~Omada-Switch (sw2)~~:** ❌ abgebaut 2026-07-23 (TP15, durch `crs326-branch` ersetzt). Controller + omada-mcp komplett gelöscht — **Omada spielt keine Rolle mehr, nie wieder aufgreifen** (User-Entscheid 2026-07-22). Aufräum-Reste ✅ geprüft 2026-08-16 (s. Tabelle oben).
 - **Nautobot Golden Config (= der einzige legitime Config-Weg für Netzgeräte):** `nautobot/gc-configplan.py`

docs/teilprojekte.md

@@ -1384,6 +1384,16 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   - **`routeros/tp28-ap-wifi-reste-abraeumen.rsc` hat den Ausfall nicht ausgeloest, aber zementiert:**
     mit den geloeschten datapath-Objekten gab es lokal nichts mehr, worauf `slaves-datapath` haette
     zeigen koennen. Der Ein-Zeilen-Fix war damit weg. Nachtrag steht im Skript.
+  - ✅ **Reboot-Abnahme an ap2 (2026-08-18), drei Fragen auf einmal beantwortet:** `slaves-datapath`
+    ueberlebt den Neustart (statisches Objekt, steht im `/export`), der CAP **findet seinen Manager
+    durch die gehaertete input-Kette wieder** (`current-caps-man-identity=crs326-core` — MNDP/CAPWAP
+    sind also korrekt offen, das war seit TP5 Etappe 4 nie durchgespielt), und die sieben Slave-VAPs
+    kommen von selbst als dynamische Bridge-Ports mit pvid 30/40/50/90 zurueck. AP nach **40 s**
+    wieder erreichbar. Abnahme nach neuer Regel = **frische Lease**: IOT-Client `10.40.30.8`
+    `last-seen=30s`, MAIN-Client `10.40.10.180` `last-seen=1m54s`.
+  - ⚠️ **Reboot per MikroMCP geht auf 7.24 nicht:** das `reboot`-Tool sendet `delay`, die REST-API
+    antwortet `unknown parameter delay`; `run_command` ist fuer `/system reboot*` per Deny-Policy
+    gesperrt. Weg bis das gefixt ist: `sshpass` + `ssh admin@<ap> "/system reboot"`.
   - ✅ **Soll nachgezogen, Compliance wieder sauber: 92/92, 0 Drifts** (2026-08-18). Weg: Template in
     `nautobot/mikrotik_routeros.j2` → `routeros/push-gc-template.py` (Secret-Guard) → GitRepository-Sync
     → Backup/Intended/Compliance. Ohne den Push meldet der Refresh die zwei neuen Zeilen als `extra`