Initial import from bf-network-r6.opencode — opencode migration

docs/tp15-core-swap-session-handover.md

@@ -0,0 +1,70 @@
+# TP15 Core-Swap — Session-Handover (Prep → Cutover)
+
+> **Von:** Prep-Session 2026-07-23 (kein Netz-Eingriff). **An:** die Cutover-Session (eigenes Wartungsfenster).
+> **Erster Prompt der neuen Session:** „Lies `docs/tp15-core-swap-session-handover.md` und führe den Core-Swap
+> im Wartungsfenster durch." Der ausführliche Auftrag/Runbook liegt zusätzlich in
+> `docs/tp15-core-swap-session-handoff-prompt.md`; dieses Doc ist der aktuellere Einstieg.
+
+---
+
+## Was ist passiert (Prep-Session)
+ap1s komplette Live-L3-Config wurde gelesen und **fertig als staged Config materialisiert**:
+`routeros/tp15-core-l3-staged.rsc` — alles Betriebsumlenkende `disabled=yes`, im Cutover in EINEM Rutsch `enable`.
+Runbook/Rollback/Verifikation stehen im Plan; die drei Fenster-Entscheide sind gefällt. **Kein Gerät angefasst.**
+
+## Locked decisions (gelten, nicht neu diskutieren)
+1. **WG-Hub (TP10 FM/DW-VPN) migriert MIT** in dasselbe Fenster. (Hing im Handoff-Prompt nicht drin — er sitzt auf
+   ap1s Public-Edge und kann dort nicht bleiben.)
+2. **Governance = frische Direkt-Ausnahme #3** (REST/MikroMCP), danach Ist-Stand als *intended* → Nautobot.
+   ⚠️ **User muss die Ausnahme #3 zu Fensterbeginn formal erteilen.**
+3. **Rettungspfad = iPhone-Hotspot** am Notebook (nicht über sw1/ap1).
+
+## Endpoint-Frage (war der letzte offene Rechercheposten) — ✅ GEKLÄRT
+- Spokes adressieren den Hub über **`bf4.emsenhuber.net:51821`** = **Cloudflare-A-Record** (proxied=false, TTL 120,
+  aktuell `90.146.35.38` = ap1s Public-IP). **Kein DDNS-Updater auf ap1** (nur WANTEST/mac-clone-Scripts) → nichts
+  zu migrieren. `/ip/cloud` = MikroTik-DDNS `update-interval=none`, irrelevant (andere Domain).
+- **Cutover-Konsequenz:** Liwests Lease ist sticky → core zieht am WAN sehr wahrscheinlich **dieselbe** IP → `bf4`
+  passt weiter → FM/DW kommen von selbst hoch. **Falls doch neue IP:** per `CF_API_TOKEN` nachziehen —
+  (a) `bf4`-A-Record **und** (b) CF-Access-Policy `bf4-home-ip` (`90.146.35.38/32`). (CF-MCP ist read-only!)
+- **Chance:** core ist **nicht** `device-mode=home` → **scheduler+fetch gehen** → den `bf4`-DDNS-Auto-Updater bauen,
+  den ap1 nie konnte → schließt den offenen TP10-Follow-up (`docs/teilprojekte.md:289`).
+
+## Bekannte Prep-Gotchas (im Fenster einplanen)
+- **MikroMCP kann core noch NICHT schreiben:** `ROUTER_CRS326_CORE_USER/PASS` sind im MCP-Prozess nicht geladen
+  → **vor dem Fenster MikroMCP neu starten** (ENV `CRS326_CORE_*` aus `~/.secrets/credentials.env`) **oder**
+  REST-curl gegen `http://10.40.41.211/rest` (wie beim Bring-up).
+- **core-Mgmt `.99.11` ist tot** (sw1 #12 trägt kein 99T) — erreichbar nur VLAN1-Temp **`10.40.41.211`**.
+- **WG-Privkey:** ap1s `wg-hub`-Private-Key im Fenster von ap1 holen und auf core setzen (Platzhalter im `.rsc`),
+  damit core denselben Public Key hält → FM/DW brauchen keine Reconfig. **Secret → nicht committen.**
+- **vlan99:** core-GW wird `.1`; Bring-up-`.11` dadurch redundant → im Fenster reconcilen (Secondary behalten oder droppen).
+- **VLAN1 raus:** Hybrid-VLAN1-Drops sw1 GE3/GE7/GE10 (+ GE1) beim Umstecken echtem VLAN zuordnen oder stilllegen.
+
+## Pre-Window-Checkliste (was Christoph parat haben muss)
+- [ ] Wartungsfenster gewählt (Vollausfall Haus), iPhone-Hotspot am Notebook aktiv.
+- [ ] Governance-Ausnahme #3 formal erteilt.
+- [ ] MikroMCP neu gestartet (core schreibbar) **oder** REST-curl bereit.
+- [ ] Port-Umzugsplan sw1→core final (Anker: **#4=ap1, #8=branch, #16=WAN**; Rest gegen Verkabelung prüfen).
+- [ ] ap1-Voll-Backup (`/export`, `create_backup`) frisch gezogen.
+
+## Cutover-Schritte (Kurzform — Detail im Plan/Handoff-Prompt)
+1. Staged core-Config bauen (`.rsc`, alles disabled) + Reservierungen maschinell von ap1 heben
+   (`/ip/dhcp-server/lease/export`, nur `dynamic=no`) + WG-Privkey einsetzen.
+2. ap1 als Router stilllegen (DHCP/DNS/NAT/GW-IPs/WAN-DHCP-Client/`wg-hub` down; Config bleibt restorbar).
+3. Kabel sw1→core umstecken (ap1 `ether2`→`ether1`/PoE, `poe-out=off`), sw1 stromlos.
+4. core-L3 in einem Rutsch `enable` (GW-IPs, DHCP-Server, WAN-DHCP-Client, WG, DNS/NAT/Firewall).
+5. **Abnahme:** je VLAN Lease/GW-Ping/Internet · DNS `*.bf.lan` · branch über core #8 · **WG fm+dw Handshake <2m** +
+   Ping in `10.101.0.0/24`/`10.95.10.0/24` · CF/WARP · Public-IP==bf4 (sonst CF nachziehen) · VLAN1 endgeräte-frei.
+6. **Rollback jederzeit:** Kabel zurück auf sw1 + ap1 wieder `enable` → Netz wie zuvor.
+
+## Nach erfolgreichem Cutover
+- Mgmt-Renumber (branch `.99.13`→`.99.12`, core `.99.11`-Reconcile), VLAN1-Temp-IPs (`.41.211`/`.41.213`) entfernen.
+- Ist-Stand als *intended* → **Nautobot** (core `Planned`→`Active`, finale Ports, GraphQL-verifiziert).
+- Doku: `teilprojekte.md` TP15/TP4, `CLAUDE.md`, `docs/ip-plan.md` (core produktiv, ap1 = AP). Commit + Push.
+- **Danach TP3** — WLAN-Neuprovisionierung ohne CAPsMAN (ap1/ap2 reine APs, aus Nautobot generiert). Eigene Session.
+- Optional gleich mitnehmen: `bf4`-DDNS-Auto-Updater auf core (TP10-Follow-up).
+
+## Artefakte
+- `routeros/tp15-core-l3-staged.rsc` — die staged L3-Config (Vorlage = ap1-Live 2026-07-23).
+- `docs/tp15-core-swap-session-handoff-prompt.md` — ausführlicher Original-Auftrag/Runbook.
+- `nautobot/ingest-crs326-ports.py` — sw1-Belegung (`:190`) + core-Ziel-Layout (`:167`).
+- `~/.secrets/credentials.env` — `CRS326_CORE_*` (REST/MCP), `CF_API_TOKEN` (CF-Writes).