TP38 bestaetigt + Uebergabeprompt fuer TP16.3 §5 (CNAME-Flip)

- TP38 (OOB-Mgmt, untagged-VLAN99-Port je Switch): Nummer von Christoph
  bestaetigt, Herkunft des Nummernwechsels im TP-Abschnitt vermerkt.
- Neu: docs/tp16.3-paragraph5-session-handoff-prompt.md -- fertiger
  Prompt fuer die Flip-Session, nach der Konvention der drei bereits
  vorhandenen *-session-handoff-prompt.md.
  Enthaelt als erste Auflage die offene Drift-Entscheidung (128/135),
  die vor dem ersten Flip fallen muss.

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

docs/tp16.3-paragraph5-session-handoff-prompt.md

@@ -0,0 +1,115 @@
+# Übergabeprompt — TP16.3 §5: CNAME-Flip auf `bf-public`
+
+> **Zum Einfügen in eine frische Session.** Erstellt 2026-08-31, direkt nach §2/§3.
+> Alles unterhalb der Linie ist der Prompt.
+
+---
+
+TP16.3 / TP31 Schritt 5 — **§5 CNAME-Flip** (Repo `~/dev/bf-infra`).
+
+Aufgabe: **§5 des Runbooks** `docs/tp16.3-bf-public-ap-connector-runbook.md` ausführen — die vier
+öffentlichen Namen von den Alttunneln auf `bf-public` umhängen. **§6 (Abbau) gehört NICHT dazu**,
+frühestens 7 Tage nach dem Flip.
+
+## PFLICHTLEKTÜRE ZUERST, in dieser Reihenfolge
+
+1. `docs/handoff-20260831-tp16.3-paragraph2-3-durch.md` — Ergebnis und Funde der Vorsession
+2. `docs/tp16.3-bf-public-ap-connector-runbook.md` **§5** (und §7 Rollback)
+3. `docs/teilprojekte.md` (Quick-Index + Ist-Stand + TP16.3-Abschnitt)
+
+## AUSGANGSLAGE — nicht nochmal machen
+
+- `bf-public` ist **healthy mit 12 Connectoren** (ap1/ap2/ap3, je ein `cloudflared 2026.6.1`,
+  Container `running`, `start-on-boot=yes`). Tunnel-ID `48d3b0b6-7233-4781-a76a-1de4a5e957ce`.
+- Ingress steht auf `https://10.40.20.40:443` mit `originServerName` je Regel (Blocker A behoben).
+- Firewall-Freigabe `vlan99 → vlan20:443` auf `crs326-core` liegt und ist verifiziert (Blocker B).
+- Caddy antwortet **mit korrektem SNI 200, ohne SNI 000** — gemessen, das ist gesundes Verhalten.
+- Rollback-Material: `docs/cf-backup/` — Ingress-Configs, CNAMEs **inklusive Record-IDs**, und für
+  drei Tunnel zusätzlich der ältere Stand als `*-vor-hostname-schnitt.json`.
+
+## 🔴 ZUERST ENTSCHEIDEN, BEVOR EIN NAME GEFLIPPT WIRD
+
+**Compliance steht auf 128/135.** Sechs `extra`-Drifts, zwei je AP: `ip-address`
+(`172.17.0.1/24 interface=veth-cf`) und `ip-firewall-nat` (`masquerade`, Kommentar
+`TP31: cloudflared egress`). Sie sind **inhaltlich richtig** — ohne sie läuft kein Container —, aber
+sie stehen nicht im Soll, weil Runbook §3.4 Direkt-Writes vorschreibt für Features, die unter
+Golden-Config-Kontrolle stehen.
+
+Der saubere Weg ist, sie ins **Soll** zu heben (AP-Template bzw. ConfigContext `ap-common`).
+🔴 **Kein Re-Baseline** (macht die Drift-Erkennung wertlos), **kein Rückbau** (killt die Tunnel).
+⚠️ Dabei mitentscheiden, ob `/interface veth` überhaupt erfasst sein soll — dafür existiert heute
+keine ComplianceRule, deshalb erzeugt `veth` auch keine Drift.
+
+Mit ungeklärter Drift in den Produktivpfad zu gehen ist die eine Sache, die diese Session
+**nicht** tun sollte. Christoph entscheidet, nicht die Session.
+
+*(Die siebte Drift, `crs326-core` / `wifi-security` / `ft-over-ds`, ist die bekannte aus dem
+7.24.1-Upgrade und gehört weiterhin nicht in diese Session.)*
+
+## REIHENFOLGE
+
+**Erst `test-tp163` (§5.1), dann `n8n` → `gitea` → `hass` → `vw`** — steigende Kritikalität, `vw`
+zuletzt. Nach **jedem** Namen die Abnahme aus §5.3, erst dann der nächste.
+
+## WICHTIGSTE FALLEN
+
+- 🔴 **`healthy` beweist nichts über das Origin.** Der Tunnelstatus sagt nur, dass der Connector mit
+  Cloudflare redet. Die Wildcard-Access-App `*.emsenhuber.net` liefert für **jeden** Namen ein
+  sauberes 302 — ein toter Dienst sieht so monatelang gesund aus (der `grafana`-Fall). Der einzige
+  Streckenbeweis ist §5.1 gegen einen Testnamen.
+- 🔴 **WARP muss AUS sein.** Mit aktivem WARP läuft der Test über den Mesh und beweist den
+  öffentlichen Weg nicht — dieselbe Fehldiagnose-Klasse wie der ICMP-Fall 2026-08-13. Testen von
+  außerhalb des LAN, über Mobilfunk.
+- 🔴 **`vw` = Bitwarden läuft auf Access-Bypass.** **Vor** dem Flip prüfen, dass die Bypass-Policy
+  für `vw.emsenhuber.net` steht — sonst sperrt der Flip alle Bitwarden-Clients aus.
+- 🔴 **`gitea`: Access gilt nur der Web-UI**, Git-/API-Pfade laufen daran vorbei. Push von außen
+  **vor** und **nach** dem Flip testen, nicht nur die UI.
+- 🔴 **`hass`: die Companion-App kann kein Access-Login.** Nach dem Flip die App auf dem Handy über
+  Mobilfunk prüfen, nicht nur den Browser.
+- ⚠️ **`ERR_TOO_MANY_REDIRECTS` nach einem Flip = Blocker A ist zurück** (Ingress auf `:80` statt
+  `:443`, oder `originServerName` fehlt). Sofort zurückflippen, nicht debuggen während der Name tot ist.
+- ⚠️ **`~/.secrets/credentials.env` lässt sich in zsh nicht sourcen** (rohe WireGuard-Zeilen ab
+  ~Zeile 69) — Variablen bleiben still leer, das sieht aus wie ein ungültiger Token. **Immer `bash -c`.**
+- 🔴 **Maskierung: Muster auf den Schlüsselnamen ankern, nie auf ein Trennzeichen.**
+  `grep -n "TOKEN" datei | sed 's/:.*TOKEN/…/'` maskiert **nicht** — `grep -n` stellt `<zeile>:`
+  voran, und das matcht das Muster. So sind in der Vorsession zwei Nautobot-Tokens ins Transkript
+  geraten. Sicher ist nur `sed -E 's/(TOKEN|PASSWORD|SECRET|KEY|PASS)=.*/\1=<redacted>/'`.
+
+## GOVERNANCE
+
+- Config-Änderungen an MikroTik-Geräten **ausschließlich** über Nautobot Golden Config
+  (`nautobot/gc-manual-plan.py`), nicht per Direkt-Write. Nautobot: **`http://10.40.20.30:8080`**
+  (Port 8080, **nicht** 80 — der Runbook-Stand nannte lange nur den Host), Token in
+  `docs/nas-vlan20/stacks/210-nautobot.yml` (gitignored, nur im Haupt-Checkout).
+- Cloudflare-Änderungen sind **outward-facing**: DNS-Flip und Ingress-Edits vor der Ausführung mit
+  Christoph bestätigen, einer nach dem anderen.
+- **MCP-Lifecycle aktiv melden**, falls sich daran etwas ändert.
+
+## OFFENE PUNKTE, DIE NICHT IN DIESE SESSION GEHÖREN
+
+1. **Rotation zweier Nautobot-Tokens** (`NAUTOBOT_SUPERUSER_API_TOKEN`, `NAUTOBOT_GITEA_TOKEN`) —
+   in der Vorsession ins Transkript geraten, als verbrannt zu behandeln. Gehört zu **TP30**.
+2. **`crs326-core` / `wifi-security` / `ft-over-ds`** — bekannte Drift, braucht eigenen Entscheid
+   plus CAP-Re-Provisionierung.
+3. **`mcp/mikromcp/config/routers.yaml`** meldet `rosVersion: "7.24"` für alle fünf, live ist
+   `7.24.1` — kosmetisch, gehört auf `main`.
+4. **§6 Abbau** (sechs Container, drei Alttunnel) — frühestens 7 Tage nach dem Flip.
+   🚫 `terpene-cloudflared` (LXC 400) und `fm.emsenhuber.net` bleiben, sie stehen im `docker ps`
+   direkt neben den zu löschenden. **Namen lesen, nicht Zeilen zählen.**
+
+## ABNAHME DIESER SESSION
+
+- [ ] Entscheidung zu den sechs Drifts getroffen und umgesetzt (Compliance erklärt oder bereinigt)
+- [ ] `test-tp163` von außerhalb des LAN ohne WARP: Access-Login, **keine** Redirect-Schleife
+- [ ] Testname **und** Testregel danach wieder entfernt
+- [ ] Alle vier Namen geflippt, je einzeln mit 15 min Beobachtung, kein 530/1033
+- [ ] `gitea`-Push von außen funktioniert nach dem Flip
+- [ ] `hass`-Companion-App über Mobilfunk funktioniert nach dem Flip
+- [ ] `vw` Bitwarden-Clients funktionieren nach dem Flip
+- [ ] Caddy-Log zeigt die Requests (`ssh root@10.40.20.100 'pct exec 130 -- journalctl -u caddy -n 20'`)
+
+## ARBEITSWEISE
+
+Bestandsaufnahme vor Plan. Eine große Fragenrunde statt vieler kleiner. Bei Abweichungen zwischen
+Doku und Live-Stand: **Drift melden, nicht stillschweigend korrigieren.** Vor jedem Flip den
+Rollback-Weg (§7, Record-IDs in `docs/cf-backup/cnames-tunnel-*.json`) parat haben.