docs 🧭 Governance „Config nur via Nautobot" + TP19.1-Stand (ap1-DNS ✅, ap2 vertagt), sw2-IP-Korrektur .41.181, VLAN99-Cutover-Guides sw1/sw2, TP15-Lieferung 17.07., TP20 an Komodo gebunden

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 09:58:09 +02:00
parent c25f7ea512
commit 9611d47ef3
5 changed files with 192 additions and 10 deletions
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -28,7 +28,7 @@ GW je VLAN = `.1` · APs: ap1=`.1`, ap2=`.2` · Switches: ALLNET=`.11`, Omada=`.
 | Gerät | IP | Zugang |
 |---|---|---|
 | ALLNET Core-Switch (sw1) | 10.40.41.11 (interim, VLAN1) | `telnet 10.40.41.11` · User: `claudecode` · PW: `switch/.secrets` |
-| Omada Access-Switch (sw2) | 10.40.41.12 (zuletzt bekannt, nicht neu verifiziert) | Web-UI HTTPS, **standalone ohne Controller** (TP2.1 ✅ 2026-07-16, User hat Recovery nach Werks-Reset komplett selbst gemacht) · Creds `omada/.secrets` (ggf. neu nach Reset, ungeprüft) |
+| Omada Access-Switch (sw2) | **10.40.41.181** (post-TP2.1-Reset, VLAN1 — Korrektur 2026-07-16, alte `.12` war stale) | Web-UI HTTPS, **standalone ohne Controller** (TP2.1 ✅ 2026-07-16, User hat Recovery nach Werks-Reset komplett selbst gemacht) · Creds `sw2/.secrets` (löst `omada/.secrets` ab, dort als obsolet markiert) |
 | hAP ax² #1 (ap1) | 10.40.41.1 (bridge/VLAN1 Mgmt) | MikroMCP (live) · **TP4 ✅: L3-Router, GW je VLAN = .1** |
 | hAP ax² #2 (ap2) | 10.40.41.2 | MikroMCP (live) · **Port 2 am Omada-Switch** |
 | NAS (nas-bf, DS923) | 10.40.41.10 | SSH · Docker (Portainer endpointId=14) |
--- a/docs/ip-plan.md
+++ b/docs/ip-plan.md
@@ -21,7 +21,7 @@
 | ap1 (Router/hAP) | 10.40.41.1 | Router/GW | alle (.1) + Mgmt | bleibt `.1` je VLAN; Mgmt `10.40.99.1` | ⬜ | ist GW, kein „Umzug" |
 | ap2 (hAP) | 10.40.41.2 | AP | 99 MGMT | `10.40.99.2` | ⬜ | |
 | sw1 ALLNET (Core) | 10.40.41.11 | Switch-Mgmt | 99 MGMT | `10.40.99.11` | ⬜ | Mgmt-VLAN-Wechsel = Lockout-Risiko, sorgsam |
-| sw2 Omada (ES208G) | 10.40.41.12 | Switch-Mgmt | 99 MGMT | `10.40.99.12` | ⬜ | |
+| sw2 Omada (ES208G) | **10.40.41.181** (post-TP2.1-Reset, Korrektur 2026-07-16 — alte `.12` war stale) | Switch-Mgmt | 99 MGMT | `10.40.99.12` | ⬜ | |
 | NAS nas-bf (DS923) | ~~10.40.41.10~~ | INFRA | 20 INFRA | `10.40.20.10` | ✅ **live** | TP14.1 2026-07-10; DNS `nas.bf.lan` nachgezogen 2026-07-16 |
 | ~~Omada-Controller~~ | — | Service (macvlan/DS923) | — | — | ❌ **entfernt** | User hat den Container 2026-07-16 gelöscht (overkill für 1 Switch auf der Abschussliste, s. TP2.1/TP15). DNS-Eintrag `omada.bf.lan` entfernt |
 | ~~omada-mcp~~ | — | Service (pve-LXC) | — | — | ❌ **entfernt** | mit dem Controller zusammen gelöscht 2026-07-16 (MCP-Server verwaist, in Claude-Settings noch registriert — Aufräumen offen). DNS-Eintrag `omada-mcp.bf.lan` entfernt |
--- a/docs/teilprojekte.md
+++ b/docs/teilprojekte.md
@@ -27,6 +27,7 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
 > 🎯 **Ziel: sauberes System „from scratch", keine Leichen/Altlasten.** Migrations-Session-Endstand = **VLAN1 + altes cudy-WLAN komplett weg** (VLAN1 nur noch Mgmt, `defconf`-Client-DHCP zurückgezogen, cudy-Uplinks aufs Ziel-Client-VLAN getaggt oder cudy abgebaut). **Unterpunkte/Aufräum-Liste bei Migration:** (a) die Interim-Härtung ap2 `wifi1/wifi2 frame-types=admit-only-vlan-tagged` (TP3.1, 2026-07-06) bleibt gültig — verschwindet automatisch mit VLAN1; (b) `st-main rrm/wnm` = reines Roaming-Provisorium, prüfen ob nach Migration noch nötig; (c) **cudy1 = verbleibender aktiver VLAN1-Leak** (Dual-DHCP-Race, Doku Memory `project_vlan1_dhcp_incident`). Bis dahin sind diese Griffe Krücken, kein Zielzustand.
 > ⚠️ **HW-Constraint hAP ax²:** 1 GB RAM, aber nur **128 MB Flash + KEIN USB** → **Container auf dem Router NICHT praktikabel**.
 > Folge: **native RouterOS-Features bevorzugen** (z.B. Built-in-mDNS statt Container); Container (mDNS-Reflector, BIND9-DNS, Omada-Controller) laufen auf **NAS/pve**, nicht am hAP.
 > 🔒 **Governance-Entscheid (User, 2026-07-16, ausgeweitet 2026-07-16): Config ausschließlich über Nautobot — keine Direkt-Changes mehr an einzelnen im Netz verstreuten Geräten.** Ursprünglich als ap1/ap2-Config-Freeze bis TP21 formuliert, noch am selben Tag verallgemeinert: **jede** Netz-Gerätekonfiguration (Router, APs, künftig auch die CRS326-Switches) läuft ab jetzt exklusiv über Nautobot Golden Config (TP21), sobald das steht — keine ad-hoc MikroMCP-Writes/UI-Klicks mehr an Einzelgeräten. **TP19.1 war die letzte Ausnahme** (ap1-DNS-Fix + ap2/sw1/sw2-Mgmt-VLAN-Umzug, s.u.) — davon ist nur der risikolose ap1-Teil noch direkt gemacht worden, ap2 wurde bewusst auf „nach Nautobot" vertagt. **Macht Nautobot + alle Prerequisites (TP18→TP20→TP20.1→TP21, jetzt auch Komodo) zum aktuell kritischen Pfad**, vor TP5/TP6. Betrifft nicht Software-Migrationen auf NAS/pve (anderes Substrat) und die Frage, ob sw1/sw2 vor der CRS326-Ablösung noch angefasst werden (offen, s. TP15/TP19.1).
 ---
@@ -336,7 +337,8 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 ### TP14.5 — Session E: Freigabe-Gate → TP5-Firewall ▸ 🔜 (ZULETZT)
 - Erst wenn TP14.1–14.3 durch (alle Origins/Connectoren in VLAN20) → dann TP5 (Deny-by-default) starten. Reines Reihenfolge-Gate, kein eigener Change.
-### TP15 — HW-Refresh: Switching + Router + DC-USV ▸ 🟡 ENTSCHIEDEN, Beschaffung läuft (2026-07-14, WLAN-Punkt korrigiert 2026-07-15) — `docs/hw-refresh-requirements.md`, Memory `project_mikrotik_commit_nautobot_gc`
+### TP15 — HW-Refresh: Switching + Router + DC-USV ▸ 🟡 Beschaffung läuft, **Lieferung 2026-07-17 (morgen)** — `docs/hw-refresh-requirements.md`, Memory `project_mikrotik_commit_nautobot_gc`
 - 📦 **2× CRS326-24G-2S+RM werden morgen (2026-07-17) geliefert.** Sequenzierung ggü. Nautobot (TP21, noch Wochen entfernt: TP18→TP20→TP20.1→TP21 + jetzt Komodo-Abh.) **noch zu klären** — Governance-Regel „Config exklusiv über Nautobot" (s. oben) steht in Spannung zu „Config vorab machen" (User-Wunsch 2026-07-16): offen ist, ob (a) nur Config-as-Code/Intended-Config **vorbereitet** wird (Hardware bleibt bis Nautobot steht ungenutzt/eingelagert), oder (b) die Switches zeitnah klassisch von Hand eingebaut werden (verstößt gegen die frische Regel, Nautobot importiert später den Ist-Stand), oder (c) alles wartet bis Nautobot steht. Ebenfalls offen: lohnt sich der TP19.1-sw1/sw2-VLAN99-Umzug noch, wenn die CRS326-Ablösung so nah ist?
 - **🧭 Grundsatzentscheid (2026-07-14, korrigiert 2026-07-15): reines MikroTik-Ecosystem — Routing + Switching + WLAN.** **Omada bekommt KEINE Rolle** (weder Switching noch WLAN — der ursprüngliche „Omada=WLAN"-Satz war ein Fehlschluss beim Dokumentieren, User-Korrektur 2026-07-15: „WLAN war NIE von Omada die Rede"). Begründung Switching: Projektziel #1 **CAKE** nur RouterOS/OpenWrt/OPNsense (Omada-Gateway kann kein CAKE) → Switching = MikroTik CRS. WLAN bleibt auf hAP ax²/CAPsMAN (kein EAP-Kauf), Coverage-Fix bleibt Platzierungsfrage (TP3.3). Verworfene Vollvarianten (Omada-only, MikroTik-only) samt Begründung + Ansible/Nautobot-Recherche → Memory. **Anlass der Korrektur:** Omada-Controller↔sw2-Link beim VLAN20-Umzug (TP14.1) zerbrochen, versehentlicher Werks-Reset bei Rettungsversuch, fehlerhafter Wiederherstellungsversuch → sw2 wird standalone neu eingerichtet, s. **TP2.1**.
 - **🛒 Switches: 2× CRS326-24G-2S+RM bestellt (2026-07-14 — CSS326-Fehlbestellung storniert → CRS).** 24×1G + 2×SFP+, lüfterlos, DC-input (USV-tauglich). Lösen ALLNET-Core (sw1) + Omada-ES208G (sw2, s. TP2.1 — Solo/Interim bis CRS-Tausch) + Cudy ab.
  - ✅ **CRS = RouterOS-fähig → in-model:** MikroMCP-Write + Nautobot Golden Config (TP21) managen auch die **Switches**, nicht nur den Router → config-as-code deckt den **ganzen Kabel-Fabric**. (SwOS-Boot bliebe als Fallback möglich, aber nicht genutzt.)
@@ -384,7 +386,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - ✅ **Recon durch (`mcp/shelly/discover.py`, read-only /shelly-Sweep):** 16 live, **alle Gen3/Gen4** (uniforme RPC-API `WiFi.SetConfig`, auth=off — kein Gen1-Sonderfall). 10 „offline" = **weihnachten_\*** (s1/s2/s3, saisonal ausgesteckt Juli) + s12/s14/s16/s18/s22/s23 (aus/DHCP-drift). ⚠️ **Inventar-Fix:** s6 (kueche_kuehlschrank, `.213`) MAC falsch erfasst (`0c:72:74:36:90:9e`) → real **`d0:cf:13:d8:18:fc`**. s24 hat gar keine MAC.
 - **Mechanismus je Gerät:** Gen2+ RPC `WiFi.SetConfig {sta:{ssid,pass,enable}}` → Reboot → landet `.30.x`. ⚠️ **Risiken:** falsches PSK → AP-Mode (physischer Reset); Gerät kurz offline; HA/ioBroker-Refs brechen bis re-pointed; WPA3-mixed ggf. zickig auf alter FW; ap1 2,4-GHz-Master `wifi2` `running:false` → Coverage v.a. via ap2 prüfen.
 - ✅ **Live-Abgleich 2026-07-11 (go-ready):** (a) `shelly-mcp` (`server.py`) fertig — discover/get/set_sta/verify/reservation_plan, PSK in `.env` gesetzt (noch nicht als MCP registriert, optional). (b) **Alle VLAN30-DHCP-Reservierungen liegen** (`.30.2xx`, Oktett erhalten, außerhalb Pool `.100–.200`); **s6-Reservierung `.30.213` MAC gefixt** (falsch `0C:72…9E` → real `D0:CF:13:D8:18:FC`). (c) **IOT-SSID live verifiziert:** ap1 `w2-iot` `running:true`, 8 Clients −26…−68 dBm (ap1-`wifi2`-„running:false" ist kosmetisch). (d) **Migration bereits ~5/26 durch:** s14/16/18/22/23 seit ~2,5 d stabil auf reservierten `.30.221/.223/.225/.202/.203` (+ `.30.204` unbekannt, evtl. s24) → **Pilot faktisch bestanden**.
- ✅ **HA-Cross-Check 2026-07-11 (alle IPv4-Geräte in HA):** Shellys deckungsgleich; **`.30.204` = Shelly „Bad/Spiegelschrank" (Plus RGBW PM, `14:33:5c:d8:2d:7c`) = vmtl. s24** → 6 statt 5 schon migriert. **Netzweite Aufstellung + VLAN1-Leerstand-Analyse** im Runbook: nach TP17 + pve-Host→VLAN20 + Christophs Endgeräte→VLAN10 ist VLAN1 **endgeräte-frei**; es bleiben nur Switch-/AP-Mgmt (sw1/sw2/ap2 → VLAN99-Cutover, eigener Schritt) + **1 unidentifiziertes Gerät `.41.246`** (morgen klären). **Nicht-Shelly-VLAN30-Mover (User-bestätigt):** SwitchBot floor-lamp `.41.184` (Res. `.30.227` steht) + Twinkly-Girlande (`.30.228`, saisonal) + Creality Ender (fehlt noch, off). **Withings schon übersiedelt; Tasmota existiert nicht mehr** (kein aktives Gerät → stale HA-Eintrag). EOS-Smartwatches/eBook-Reader später + von Christoph selbst (eBook eher VLAN50).
+- ✅ **HA-Cross-Check 2026-07-11 (alle IPv4-Geräte in HA):** Shellys deckungsgleich; **`.30.204` = Shelly „Bad/Spiegelschrank" (Plus RGBW PM, `14:33:5c:d8:2d:7c`) = vmtl. s24** → 6 statt 5 schon migriert. **Netzweite Aufstellung + VLAN1-Leerstand-Analyse** im Runbook: nach TP17 + pve-Host→VLAN20 + Christophs Endgeräte→VLAN10 ist VLAN1 **endgeräte-frei**; es bleiben nur Switch-/AP-Mgmt (sw1/sw2/ap2 → VLAN99-Cutover, eigener Schritt) + **1 unidentifiziertes Gerät `.41.246`** (morgen klären). **Nicht-Shelly-VLAN30-Mover (User-bestätigt):** ✅ SwitchBot floor-lamp `.41.184` + ✅ Twinkly-Girlande `.30.228` (beide 2026-07-16 übersiedelt, s. TP19) + Creality Ender (fehlt noch, off). **Withings schon übersiedelt; Tasmota existiert nicht mehr** (kein aktives Gerät → stale HA-Eintrag). EOS-Smartwatches/eBook-Reader später + von Christoph selbst (eBook eher VLAN50).
 - **Scope-Erweiterung (User 2026-07-11):** je Gerät **3 Änderungen** — WLAN→`dirtyvader-iot` + IP (`.41.2xx`→`.30.2xx`) **+ einheitliches Geräte-Passwort** (`Shelly.SetAuth`, User `admin`, realm-individueller ha1 → Tool `set_auth` in `server.py` nachrüsten). **PW entschieden: eigenes Shelly-Admin-PW** (getrennt vom WLAN-PSK) → `SHELLY_DEVICE_PW` in `.env` (Christoph liefert Wert). **HA-Entities unverändert** (keyt per MAC). **HA-Entities bleiben unverändert** (HA keyt per MAC). **Projektion TP17.1 (experimentell, nachrangig):** Gen4 (~11 St.) auf **Thread/Matter** flashen (Firmware-Verfügbarkeit + Thread-Border-Router offen) — Konflikt mit „Entities unverändert" (Matter = neue Entities) → erst WiFi-Migration stabilisieren.
 - ✅ **Reservierungs-/Pool-Konvention (User 2026-07-11):** alle Shellys bekommen **statische IP** (`10.40.30.<octet>`, gw/dns `.30.1`) **+ in-pool DHCP-Reservierung** als Backup. `pool-v30` auf `.100-.250` erweitert (Reservierungen jetzt in-pool); `set_sta` auf `static=true` umgestellt; s24-Inventar + `.30.204`-Reservierung angelegt. **Vollständiger HA-MAC-Scan:** 2 verpasste Media-Geräte **Apple TV 4K + Philips TV** (aus, → VLAN40) — **vor cudy-Abschuss** VLAN verifizieren; **Apple TV = vmtl. Thread-Border-Router** (TP17.1). **`.41.246/.247 = cudy1/cudy2`** (Teardown-Ziele). Tasmota bestätigt tot.
 - **Offene Schritte (morgen, „nur noch go", Runbook `docs/tp17-shelly-go-runbook.md`):** die **16 verbliebenen VLAN1-Shellys** (s4–s11, s13, s15, s17, s19–s21, s25, s26 auf `10.40.41.2xx`) per `WiFi.SetConfig`→`dirtyvader-iot` umklemmen (Batch, je Gerät `.30.x` verifizieren) → Geräte-PW setzen → HA/ioBroker-Re-Point → SwitchBot/Tasmota/3. Nicht-Shelly → saisonale s1/s2/s3/s12 beim nächsten Einstecken → cudy-Alt-WLAN abbauen → DNS/Inventar/`ip-plan` nachziehen.
@@ -422,20 +424,24 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
  - **Verlorene Shelly — IDENTIFIZIERT via HA 2026-07-13** (User-Hinweis „du siehst ihn im HA"): HA-Device `shellyplugsg3-e4b063e41ab8`, **Modell = Shelly Plug S Gen3**, **MAC `e4:b0:63:e4:1a:b8`**, HA-device_id `7a21e8f3349e6660f8b35974fc989a7b`. **NICHT im 26er-Inventar** (Spare/Küchen-Steckdose, die Christoph beim Einrichten verbockt hat; er nannte sie „küche s20", aber s20=`98:a3:16:7c:5f:ec` läuft sauber auf `.30.206` — Verwechslung). **KEIN AP-Mode, nicht tot:** assoziiert am **Altnetz `elektrosmog.c`** (cudy → untagged VLAN1-L2), aber mit **bogus-IP `10.95.10.206`** (Fremd-Subnetz, User-Fehler) → unrouting-bar, daher weder in VLAN1/30-Sweep noch normal per IP erreichbar, aber **per MAC in HA/WiFi-Table sichtbar**. Der `.219/s12`-Verdacht war Sackgasse (s12 nur saisonal aus).
  - **Update 2026-07-14: Shelly wieder da** (User-Meldung) — Live-Status (noch bogus-IP `10.95.10.206` oder inzwischen normal erreichbar?) **zu Sessionbeginn per HA/ARP verifizieren**; Recovery-Plan unten ggf. obsolet, falls sich das Gerät selbst erholt hat.
  - **Recovery-Plan (falls beim Verify noch nötig):** ap1 bekommt **temporäre Zweit-IP `10.95.10.1/24` auf der Bridge** → `10.95.10.206` per L2 erreichbar → **ein** `WiFi.SetConfig {sta: ssid=dirtyvader-iot, pass=IOT-PSK, static, ip=10.40.30.<frei>}` + `Shelly.Reboot` → Gerät kommt auf VLAN30 hoch → temp-IP entfernen. Danach `.30.x`-Reservierung + Inventar (MAC `e4:b0:63:e4:1a:b8`) + eco-Policy. Umgeht die „blutige Nase" (IP am Gerät ändern während man drauf hängt = Verbindungsverlust) — vom Router aus in einem Rutsch. Christophs manueller Direkt-Versuch (AP-IP auf 10.40.30 „verdrehen") war genau deshalb gescheitert.
-  - **SwitchBot floor-lamp** `.41.184` (`b8:f8:62:09:f2:04`, live auf VLAN1/cudy) → **VLAN30 via SwitchBot-App** (kein Local-WiFi-API, nur App/BLE-Provisioning), Res. `.30.227` liegt. = Christoph-App-Task. ⚠️ **Update 2026-07-14: KEIN Prereq mehr — funktioniert laut User erst NACH VLAN1-Retirement** → verschoben in die Teardown-Nachlese (s.u.), blockiert den cudy-Abschuss nicht mehr.
+  - ✅ **SwitchBot floor-lamp** `.41.184` (`b8:f8:62:09:f2:04`) → **erfolgreich auf VLAN30 übersiedelt (2026-07-16, Christoph via App/BLE)**, Res. `.30.227`.
 - **Prereqs-Status (live nachgezogen 2026-07-16, s. Live-Sweep oben):**
  1. ✅ **Christophs Endgeräte → VLAN10/20 erledigt:** MacBook-Air (`c0:c7:db:de:71:be`, Claude-Sandbox-Client) hat aktive Leases nur noch auf `dhcp-v10`/`dhcp-v20`, keine `defconf`-Lease mehr. iPhone `.41.186` nicht im aktuellen Sweep erneut geprüft (zuletzt off/asleep) — kurz vor Cutover gegenchecken.
  2. ✅ **2 unidentifizierte VLAN1-Geräte (`.41.133`/`.41.198`) aus dem ARP verschwunden** — kein aktueller Eintrag mehr, gelten als nicht mehr blockierend (entweder migriert oder abgeklungen).
  3. ⏳ **Media → VLAN40 weiterhin offen:** Apple TV 4K + Philips TV nicht in diesem Sweep verifiziert.
  4. ⏳ **Saisonale Shellys s1/s2/s3/s12 weiterhin offen** — nicht blockierend, kann übersprungen werden (Re-Onboarding-Aufwand akzeptiert).
  5. ⏳ **pve-Interim-IP `.41.100` weiterhin aktiv/reachable** — Host-seitiger Cleanup auf pve selbst noch offen (nicht Router-Config).
- **Teardown-Sequenz (angepasst an den Live-Stand):** VLAN1-Client-Sweep ist **schon fast leer** (nur sw1-Mgmt + pve-Interim reachable) → `defconf`/pool-v1 ist **bereits disabled** → cudy-Abbau **entfällt** (cudy1 umgenutzt statt abgebaut, cudy2 tot) → **verbleibt:** SwitchBot floor-lamp via App/BLE auf VLAN30 (Res. `.30.227`), Media-Check (B1.3), pve-`.41.100` abräumen (B1.5), Interim-Krücken bewerten (ap2 `frame-types=admit-only-vlan-tagged`, `st-main rrm/wnm`), Inventar/`ip-plan`/DNS `.41→Ziel` final.
+- **Teardown-Sequenz (angepasst an den Live-Stand):** VLAN1-Client-Sweep ist **schon fast leer** (nur sw1-Mgmt + pve-Interim reachable) → `defconf`/pool-v1 ist **bereits disabled** → cudy-Abbau **entfällt** (cudy1 umgenutzt statt abgebaut, cudy2 tot) → ✅ **SwitchBot + Twinkly erledigt (2026-07-16)** → **verbleibt:** Media-Check (B1.3), pve-`.41.100` abräumen (B1.5), Interim-Krücken bewerten (ap2 `frame-types=admit-only-vlan-tagged`, `st-main rrm/wnm`), Inventar/`ip-plan`/DNS `.41→Ziel` final.
 - Abh.: **TP14 ✅** (Hosts raus aus VLAN1), **TP17 ✅** (Shellys raus). Verwandt: `project_vlan1_dhcp_incident` (cudy-Dual-DHCP-Leak), TP5 (Deny-by-default danach sauberer). SSoT hier + `docs/tp19-vlan1-cudy-teardown-runbook.md`. Folge: **TP19.1**.
-#### TP19.1 — VLAN99-MGMT-Cutover (sw1/sw2/ap2-Mgmt VLAN1 → VLAN99) ▸ 🔜 TODO (angelegt 2026-07-16, Unterpunkt von TP19)
+#### TP19.1 — VLAN99-MGMT-Cutover (sw1/sw2/ap2-Mgmt VLAN1 → VLAN99) ▸ ⏳ ap1-Teil ✅, ap2 auf Nautobot vertagt, sw1/sw2 offen (Stand 2026-07-16)
- **Scope:** die einzigen Dinge, die TP19s Hauptteil bewusst in VLAN1 belässt — sw1 (`.41.11`), sw2 (`.41.12`), ap2-Mgmt (`.41.2`) — auf VLAN 99 (MGMT, `10.40.99.0/24`) umziehen. Erst danach ist VLAN1 wirklich **komplett** weg, nicht nur als Client-Netz.
+- **Scope:** die einzigen Dinge, die TP19s Hauptteil bewusst in VLAN1 belässt — sw1 (`.41.11`), sw2 (`.41.181`), ap2-Mgmt (`.41.2`) — auf VLAN 99 (MGMT, `10.40.99.0/24`) umziehen. Erst danach ist VLAN1 wirklich **komplett** weg, nicht nur als Client-Netz.
 - **User-Entscheid (2026-07-16):** kein eigenständiges TP-Nummer — bewusst als **Unterpunkt von TP19** geführt („VLAN1 killen"), nicht als TP22 o.ä.
- **Bereits vorbereitet:** `docs/ip-plan.md` Phase 2 hat schon einen Entwurf (ap2→`10.40.99.2`, sw2→`10.40.99.12`, sw1→`10.40.99.11`, „Lockout-Risiko, sorgsam", sw1 zuletzt). ap1s DNS-Statics (`ap1.bf.lan`/`ap2.bf.lan`) tragen schon den Kommentar „update to `.99.x` after MGMT migration" (seit TP4).
+- ✅ **ap1-Teil erledigt (2026-07-16):** ap1 brauchte keinen funktionalen Umzug (vlan99-Interface/GW `.99.1` läuft schon seit TP4) — nur der kosmetische DNS-Static-Nachtrag `ap1.bf.lan` `10.40.41.1`→`10.40.99.1` war offen, per MikroMCP erledigt (dry-run→apply, `manage_dns_entry`).
 - 🔜 **ap2-Teil bewusst vertagt (User-Entscheid 2026-07-16): erst NACH Nautobot (TP21).** Nautobot übernimmt dann in einem Rutsch ap1 + ap2 + die neuen CRS326-Switches (TP15) als config-as-code-Fleet — der ap2-Mgmt-VLAN-Umzug wird also nicht mehr isoliert von Hand gemacht, sondern Teil der Nautobot-Erstadoption. `ap2.bf.lan`-DNS-Static bleibt bewusst auf `10.40.41.2` bis dahin.
 - 🔒 **TP19.1 war die letzte Ausnahme vom ap1/ap2-Config-Freeze — der jetzt (2026-07-16) zur generellen Regel ausgeweitet wurde** (s. Governance-Entscheid oben): **jede** Gerätekonfiguration künftig ausschließlich über Nautobot, keine direkten Änderungen mehr an einzelnen im Netz verstreuten Geräten. Der ap1-DNS-Fix oben war die letzte direkte MikroMCP-Write-Aktion unter der alten (engeren) Regel.
 - ⏳ **sw1/sw2-Teil: Status offen, hängt an der CRS326-Sequenzierung.** Klickanleitungen liegen fertig vor (`switch/ui-guides/02-vlan99-mgmt-cutover.md`, `sw2/ui-guides/01-vlan99-mgmt-cutover.md`), aber ob sie noch ausgeführt werden oder obsolet sind, hängt davon ab, wie TP15 (CRS326-Lieferung 2026-07-17) gehandhabt wird — s. TP15.
 - **Bereits vorbereitet:** `docs/ip-plan.md` Phase 2 hat schon einen Entwurf (ap2→`10.40.99.2`, sw2→`10.40.99.12`, sw1→`10.40.99.11`, „Lockout-Risiko, sorgsam", sw1 zuletzt).
 - **Abh.:** TP19-Hauptteil (VLAN1-Client-Retirement) — logisch danach, da VLAN99 als eigenes Mgmt-Netz erst dann wirklich nötig wird, wenn VLAN1 sonst leer ist. sw1-Teil braucht sw1-Telnet-Zugriff (User macht sw1-Changes direkt, s. Feedback-Memory) — Lockout-Risiko am größten bei sw1 (einziger Netzpfad zu sw2 hängt am Uplink).
 ### TP20 — Platform-Datenbank (Postgres Precious-Tier + MariaDB Tier-2) ▸ 🔜 KONZEPT (2026-07-14) — Memory `project_mikrotik_commit_nautobot_gc`
@@ -447,7 +453,8 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - **Substrat:** Postgres in **LXC auf pve** (DB-Klasse, nicht Docker).
 - **Scope TP20 = Plattform:** Cluster hoch, Tiering, Backup/PITR, **Nautobot-DB** anlegen. **vw-Migration + Cross-Site-HA = TP20.1** (ausgelagert).
 - **Offene Sub-Steps:** pgBackRest-Bucket in Garage (Abh. TP18-Startpfad ①); PG-Version final (16 vs 17); Rollen/DB-Anlage Nautobot.
- Abh.: **TP18** (Garage-S3 für Backups — mind. BF-Node ①). **Blockt TP21 + TP20.1.**
+- ⚠️ **Neue Abh. (User 2026-07-16): TP20 (Postgres-LXC) + weitere neue Softwarepakete sollen über Komodo deployt werden, nicht mehr direkt/Portainer.** Komodo hat aber aktuell **keine eigene TP-Nummer** — bislang nur als „Eigener Task" unter TP2 (Portainer-Ablösung, Zeile 72) und in CLAUDE.md-Tooling erwähnt. Noch zu klären: eigenes TP (z.B. TP22) heraustrennen, oder unter TP11 (Monitoring & Mgmt-Control-Plane) hängen? Bis geklärt: TP20 gilt als **an Komodo-Rollout gebunden**, nicht mehr eigenständig startbar.
 - Abh.: **TP18** (Garage-S3 für Backups — mind. BF-Node ①), **Komodo-Rollout** (s.o., TP-Nummer offen). **Blockt TP21 + TP20.1.**
 #### TP20.1 — Vaultwarden → Platform-Postgres + Cross-Site-HA ▸ 🔜 KONZEPT (2026-07-14, ausgelagert aus TP20)
 - **Ziel:** `vw` (`.20.127`, heute MariaDB) auf den Precious-Tier holen **und** das eigentliche User-Ziel erfüllen: **DB-Replikation über 2 Sites** (Standort-Verlust überlebbar).
@@ -475,6 +482,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 ---
 ## Reihenfolge / Abhängigkeiten
 > 🎯 **AKTUELLER KRITISCHER PFAD (Stand 2026-07-16, überschreibt die Reihenfolge unten):** TP18 (Garage-S3, mind. BF-Node ①) → TP20 (Platform-Postgres, jetzt zusätzlich an Komodo-Rollout gebunden, TP-Nummer offen) → TP20.1 (Vaultwarden) ∥ TP21 (Nautobot Golden Config) → danach erst TP19.1-Rest (ap2/sw1/sw2) + TP5/TP6. Grund: Governance-Entscheid „Config exklusiv über Nautobot" (s. oben) macht Nautobot zur Voraussetzung für praktisch jede weitere Router-/Switch-Änderung. Die Punkte 3-4 unten (Omada-PVID-Fix etc.) sind **historisch/überholt** (Omada spielt seit TP15-Korrektur keine Rolle mehr) — ganze Liste braucht mal eine Aufräum-Session, hier nur der aktuelle Fokus vorangestellt.
 > ✅ **TP16 (CF-Tunnel Round-Robin/macvlan-Host-Isolation → reziprokes 3-Tunnel-HA)** KERN UMGESETZT 2026-07-10 (#1033 strukturell weg). Offen nur Access-Strang (WARP/`vw`) = user-gated. As-Built `docs/cf-tunnel-mapping.md §10`.
 1. ~~**TP1 (GE8) → TP2 (Omada Controller).**~~ ✅ erledigt 2026-06-15.
 2. ~~**TP4 (Router-Cutover L3-Infra + WAN-Edge).**~~ ✅ erledigt 2026-06-15 (L3) + 2026-07-01 (Edge-Cutover, FB physisch weg).
--- a/sw2/ui-guides/01-vlan99-mgmt-cutover.md
+++ b/sw2/ui-guides/01-vlan99-mgmt-cutover.md
@@ -0,0 +1,80 @@
 # Omada ES208G (sw2, Standalone) — Web-UI-Guide: Management-VLAN 1 → 99 (TP19.1)
 > ⚠️ **Labels in diesem Dokument sind NICHT verifiziert.** Anders als beim ALLNET-Guide
 > (`switch/ui-guides/02-vlan99-mgmt-cutover.md`, dort echte Scrape derselben Firmware) habe ich
 > **keinen CLI/API-Zugriff auf sw2** und keine aktuelle Live-Ansicht seines Standalone-Web-UIs seit
 > dem TP2.1-Reset. Was unten steht, ist die **typische** Menüstruktur von TP-Link-Easy-Smart/
 > Easy-Managed-Switches (System/Switching/VLAN/Monitoring/Maintenance) — Absicht + Zielwerte stimmen,
 > **die genauen Seiten-/Feldnamen können abweichen**. Bitte nach jedem Klick kurz gegenprüfen, ob die
 > Seite tut, was der Schritt beabsichtigt — nicht blind Feld für Feld folgen. Bei Unklarheit lieber
 > stoppen und mir beschreiben/screenshotten, was tatsächlich da ist, statt zu raten. (Hintergrund: die
 > vorige sw2-Session hat genau an einer zu selbstsicheren Config-Rekonstruktion gehangen — s. Memory
 > `feedback_hw_config_trust_after_incident`. Diesmal lieber zu vorsichtig als zu forsch.)
 ## Was wir wollen (Absicht in einem Satz)
 sw2s eigene Management-Adresse von `10.40.41.181` (VLAN1, aktueller Live-Stand seit dem TP2.1-Reset,
 s. `sw2/.secrets`) auf **`10.40.99.12/24`, GW `10.40.99.1`, Management-VLAN 99** umstellen.
 ## ⚠️ Bevor du klickst
 - **Reihenfolge (`docs/ip-plan.md` Phase 2): ap2 zuerst, DANN sw2, dann sw1 zuletzt.** Wenn ap2 noch
  nicht auf VLAN99 ist, lieber damit anfangen — sw2 hängt zwar nicht direkt an ap2s Erreichbarkeit,
  aber die Reihenfolge minimiert, wie viele Dinge gleichzeitig "in Bewegung" sind.
 - **Kein Controller mehr im Spiel** (TP2.1) → **kein Adopt/Re-Adopt-Rollback-Pfad**, falls etwas
  schiefgeht. Der einzige Fallback ist lokal am Gerät.
 - **Vor-Check zuerst, nicht überspringen:** existiert VLAN 99 überhaupt schon in sw2s VLAN-DB (nach dem
  Werks-Reset + Solo-Recovery)? Und trägt **Port 1** (Uplink → ALLNET sw1 GE8) sowie **Port 2** (→ ap2)
  VLAN 99 **tagged**? Beide sind laut CLAUDE.md als "Trunk-ALL" konfiguriert, sollten es also haben —
  aber das war TP2.1s Solo-Recovery, hier nicht ungeprüft von TP1/TP2 übernehmen. Wenn eins von beiden
  fehlt: **hier abbrechen**, erst die VLAN-Membership nachziehen (analog `docs/tp2.1-omada-switch-
  standalone-runbook.md` Schritt 2-3), dann erst die Mgmt-Adresse anfassen.
 - **Prüfen, ob dieses Gerät ein "Save"/"Apply"-Konzept mit getrenntem Persistenz-Schritt hat** (viele
  Easy-Smart-Switches wenden Änderungen sofort UND dauerhaft an, ohne Zwischenschritt — anders als beim
  ALLNET-Switch gibt es hier möglicherweise **kein** "ändern-aber-nicht-speichern"-Sicherheitsnetz).
  Falls du im Menü einen expliziten "Save Config"/"Apply"-Schritt siehst: wie beim ALLNET-Guide **nicht
  sofort speichern**, erst auf der neuen IP verifizieren. Falls alles sofort permanent wird: dann ist die
  neue IP sofort scharf — sei entsprechend vorsichtig beim Eintippen der Werte.
 ## Klickpfad (Struktur typisch für Easy-Smart/Easy-Managed-UI — bitte gegenprüfen)
 ### 0) Login & Vorprüfung
 1. Browser → **https://10.40.41.181** (oder `http://`, falls https nicht angeboten wird) → Login
   `admin` (PW in `sw2/.secrets`, dort noch von dir einzutragen falls leer).
 2. Menü **VLAN** (evtl. Unterpunkt "802.1Q VLAN") → prüfen: VLAN 99 vorhanden? Falls eigene Namen
   vergeben wurden (MAIN/INFRA/…/MGMT analog ALLNET) sollte 99 = "MGMT" heißen.
 3. Dort (oder unter einem "Port"/"Membership"-Unterpunkt) prüfen: Port 1 + Port 2 = Tagged Member von
   VLAN 99.
 4. Falls beides passt → weiter zu Schritt 1. Falls nicht → hier abbrechen (s.o.).
 ### 1) IP-Adresse + Management-VLAN — vermutlich unter `System → IP Setting` oder `System → Network`
 1. Menü **System** suchen, darin nach IP-bezogenen Einträgen.
 2. Felder (Namen können abweichen, Absicht zählt):
   - **IP-Adresse** = `10.40.99.12`
   - **Subnetzmaske** = `255.255.255.0`
   - **Gateway** = `10.40.99.1`
   - Modus: **Static** (nicht DHCP)
   - Falls ein separates Feld **"Management VLAN"** oder **"VLAN ID"** existiert: `99` eintragen.
   - **Falls es KEIN separates Management-VLAN-Feld gibt:** dann bestimmt bei diesem Gerät vermutlich
     die **PVID des Ports, über den du gerade zugreifst** (oder eine switch-globale VLAN-Zuordnung),
     welches VLAN die Mgmt-IP bedient — in dem Fall bitte **stoppen und mir Bescheid geben**, bevor du
     weitermachst. Das ist ein Gerätekonzept, das ich vorher nicht zuverlässig kenne, und falsch geraten
     hier ist genau das Muster vom letzten Incident.
 3. Übernehmen/Apply.
 4. **Ab hier ist deine aktuelle Session zur `.41.181`-Adresse vermutlich tot** (erwartet, kein Fehler).
 ### 2) Reconnect & Verifikation
 1. Neuer Tab → **https://10.40.99.12**.
 2. Erreichbar + Login geht? → weiter (ggf. Save, falls es diesen Schritt gibt, s.o.).
 3. **Nicht erreichbar?** Kein Save-Schritt bekannt heißt: Änderung ist wahrscheinlich schon dauerhaft
   → **Power-Cycle bringt hier vermutlich KEIN automatisches Rollback** (anders als beim ALLNET-Switch).
   Fallback dann: physischer Zugriff, Reset-Taste (**Werksreset, komplette Config weg** — TP2.1 müsste
   nochmal gemacht werden). Bevor du das auslöst: kurz Ping/ARP von einem VLAN10/20-Host aus probieren
   (`10.40.99.12`, `10.40.41.181`) — vielleicht ist nur der Browser-Cache/DNS das Problem, nicht der Switch.
 ## Verifikation (nach erfolgreichem Wechsel)
 - `https://10.40.99.12` erreichbar, ap2-Mgmt weiterhin erreichbar (falls schon auf VLAN99).
 - `sw2/.secrets` `SW2_HOST` auf `10.40.99.12` aktualisieren.
 - `docs/ip-plan.md` Zeile sw2 bestätigen, `CLAUDE.md`-Hardwaretabelle nachziehen.
 ## Nachziehen (nach erfolgreichem Cutover, alle drei TP19.1-Kandidaten durch)
 - `docs/teilprojekte.md` TP19.1 auf ✅ setzen.
 - Governance-Hinweis: TP19.1 ist die letzte Ausnahme vom ap1/ap2-Config-Freeze bis TP21 (Nautobot) steht.
--- a/switch/ui-guides/02-vlan99-mgmt-cutover.md
+++ b/switch/ui-guides/02-vlan99-mgmt-cutover.md
@@ -0,0 +1,94 @@
 # ALLNET ALL-SG8316M (sw1) — Web-UI-Guide: Management-VLAN 1 → 99 (TP19.1)
 > **Methode:** Claude erklärt Absicht + Klickpfad, **du klickst**. UI = Realtek-OEM (Backbone-SPA),
 > FW 2.2.1.2956, erreichbar unter **https://10.40.41.11** (Login `claudecode`, PW in `switch/.secrets`).
 > Die VLAN-Menü-Labels unten (`VLAN → Port Setting`, `VLAN → Membership`) sind aus einer echten Scrape
 > auf **genau dieser Firmware** (`switch/ui-guides/01-trunk-ap-ports.md`, 2026-06-09) — sollten exakt passen.
 > Die **System/IP/Management-VLAN-Labels sind NICHT live gescraped** (nur aus der alten FW1.0-CGI-Map
 > abgeleitet, `switch/sg8316m-cgi-map.md`) — Seitentitel können abweichen, die **Absicht** steht bei
 > jedem Schritt dabei, danach suchen.
 ## Was wir wollen (Absicht in einem Satz)
 sw1s eigene Management-Adresse von `10.40.41.11` (VLAN1, interim) auf **`10.40.99.11/24`, GW `10.40.99.1`,
 Management-VLAN `99`** umstellen — der letzte von drei TP19.1-Kandidaten (nach ap2, vor... eigentlich
 **zuletzt**, s. Reihenfolge unten). VLAN 99 (MGMT) existiert bereits in der VLAN-DB (Name "MGMT" gesetzt),
 und alle Trunk-Ports (GE1/GE2/GE8 + der ap1-Uplink) tragen VLAN 99 bereits **tagged** (TP1 ✅) — es muss
 **keine VLAN- oder Port-Config** geändert werden, nur die switch-eigene Mgmt-Bindung.
 ## ⚠️ Bevor du klickst
 - **Reihenfolge (aus `docs/ip-plan.md` Phase 2): ap2 zuerst, dann sw2, dann sw1 zuletzt** — sw1 ist das
  risikoreichste Gerät (einziger Netzpfad zu sw2 hängt am sw1-Uplink; wird sw1 unerreichbar, ist auch
  sw2 nicht mehr über den Uplink diagnostizierbar). Wenn ap2/sw2 noch nicht durch sind: die hier lieber
  nicht vorziehen.
 - **Telnet-CLI ist aktuell kaputt** (`claudecode`-Login wird deterministisch abgelehnt, s. Memory
  `project_tp19_vlan1_status_20260716`) — d.h. **kein CLI-Fallback**, falls die Web-UI nach dem Schritt
  hängt. Das Web-UI-Login selbst ist unabhängig davon (anderer Login-Pfad) — trotzdem als Schritt 0 zuerst
  verifizieren, nicht blind loslegen.
 - **Die eingebaute Sicherheitsnetz-Mechanik dieses Geräts: Änderungen wirken erst nach explizitem `save`
  in Flash.** Solange du **nicht speicherst**, überlebt die Änderung keinen Reboot/Stromausfall — das ist
  hier bewusst der Rollback-Pfad (s. unten). **Also: NICHT sofort speichern, erst verifizieren.**
 - Kein bekannter Seriell-/Konsolen-Zugang an diesem Gerät. Physische Reset-Taste = **Werksreset** (komplette
  Config weg, alle VLANs/Trunks/Namen neu von den `.cli`-Skripten aufbauen) — nur allerletzter Ausweg.
 ## CLI-Äquivalent (nur zum Gegenchecken/für später, falls Telnet wieder geht)
 ```
 configure
 ip address 10.40.99.11 mask 255.255.255.0
 ip default-gateway 10.40.99.1
 management-vlan vlan 99
 end
 # NICHT sofort:
 save
 ```
 (Quelle: `switch/cli/CLI-REFERENCE.md`.)
 ## Klickpfad
 ### 0) Login & Vorprüfung
 1. Browser → **https://10.40.41.11** → Login `claudecode` (PW `switch/.secrets`).
 2. **VLAN → Membership**: prüfen, dass **VLAN 99** existiert und auf dem Port, der zu ap1 führt
   (laut `routeros/wan-cutover-runbook.md` = **gi15**; falls die UI andere Portnummern zeigt, den Port
   nehmen, der die meisten VLANs tagged trägt — das ist der AP-Uplink), als **Tagged (T)** gelistet ist.
   Falls nicht: **hier abbrechen**, nicht weitermachen (Physical-Path fehlt sonst).
 ### 1) IP-Adresse setzen — vermutlich `System → IP Setting` (Label ungescraped, s.o.)
 1. Menü mit "IP"/"Network"/"System" suchen (nicht "VLAN").
 2. Felder:
   - **IP-Adresse** = `10.40.99.11`
   - **Subnetzmaske** = `255.255.255.0`
   - **Default Gateway** = `10.40.99.1`
   - Modus: **Static** (nicht DHCP)
 3. **Noch NICHT Apply/Save drücken, wenn die Seite auch das Management-VLAN-Feld enthält** — erst
   Schritt 2 mit auf derselben Seite ausfüllen (viele Realtek-OEM-UIs haben IP + Mgmt-VLAN auf einer
   gemeinsamen Seite). Falls getrennte Seiten: Apply hier ist ok, weiter zu Schritt 2.
 ### 2) Management-VLAN setzen — vermutlich gleiche Seite oder `System → Management VLAN`
 1. Feld **Management VLAN / VLAN ID** = `99`.
 2. **Jetzt Apply/Submit.**
 3. **Ab hier ist deine aktuelle Browser-Session zur alten `.41.11`-Adresse tot** — das ist erwartet,
   keine Störung. Der Switch beantwortet ab jetzt nur noch auf `10.40.99.11`.
 ### 3) Reconnect & Verifikation (BEVOR gespeichert wird!)
 1. Neuer Tab → **https://10.40.99.11** aufrufen.
 2. Erreichbar + Login geht? → weiter zu Schritt 4 (Save).
 3. **Nicht erreichbar nach ~1 Minute?** → **nicht weiter versuchen, nicht neu konfigurieren** — stattdessen
   Switch stromlos machen und neu starten (Power-Cycle). Da **nicht gespeichert wurde**, bootet er mit der
   alten Config (`10.40.41.11`, VLAN1) wieder hoch → zurück auf Los, ohne Schaden. Danach mir Bescheid
   geben, bevor der nächste Versuch gestartet wird (ggf. stimmt eine Portzuordnung nicht).
 ### 4) Speichern (erst wenn Schritt 3 erfolgreich war!)
 - **System → Save Config** (oder Disketten-Symbol) → "Save to Flash". Ab jetzt übersteht die neue
  Mgmt-Adresse einen Reboot.
 ## Verifikation (nach Save)
 - `https://10.40.99.11` weiterhin erreichbar.
 - `switch/.secrets` `SW_HOST` auf `10.40.99.11` aktualisieren (für zukünftige Telnet-Versuche, falls
  der Login-Blocker sich klärt).
 - ap2 (sofern schon auf VLAN99 umgezogen) und sw2 weiterhin über VLAN99 erreichbar — kein Kollateralschaden
  am gemeinsamen MGMT-Segment.
 - `docs/ip-plan.md` Zeile sw1: `bestätigt` = ✅ setzen. `CLAUDE.md`-Hardwaretabelle nachziehen.
 ## Nachziehen (nach erfolgreichem Cutover, alle drei TP19.1-Kandidaten durch)
 - `docs/teilprojekte.md` TP19.1 auf ✅ setzen.
 - Governance-Hinweis beachten: TP19.1 ist die **letzte Ausnahme** vom ap1/ap2-Config-Freeze bis TP21
  (Nautobot) steht — danach keine weiteren ad-hoc-Router-Changes mehr ohne Rücksprache.