diff --git a/docs/handoff-20260831-tp16.3-paragraph2-3-durch.md b/docs/handoff-20260831-tp16.3-paragraph2-3-durch.md
index b29e995..16c4979 100644
--- a/docs/handoff-20260831-tp16.3-paragraph2-3-durch.md
+++ b/docs/handoff-20260831-tp16.3-paragraph2-3-durch.md
@@ -116,8 +116,8 @@ nie auf ein Trennzeichen, das auch im Präfix vorkommt.
 
 - Branch `claude/nervous-williams-acf000` ist hier **hereingemergt**. Konflikte aufgelöst:
   - **Nummernkonflikt TP37**: `main` hatte TP37 = *Nautobot als Netzwerkdoku* (User-Okay 08-30),
-    der Branch TP37 = *OOB-Mgmt*. Letzterer ist auf **TP38** umnummeriert. ⚠️ **Braucht dein Okay** —
-    Nummernvergabe ist laut Konvention deine Entscheidung.
+    der Branch TP37 = *OOB-Mgmt*. Letzterer ist auf **TP38** umnummeriert.
+    ✅ **Von Christoph bestätigt (2026-08-31).**
   - **Drei CF-Rollback-Snapshots hatten denselben Dateinamen bei verschiedenem Inhalt**
     (`bf-mm` v4/6 Regeln vs. v6/2 Regeln, analog `bf-nas`, `bf-pve`) — zwei Zeitpunkte, beide
     „vor-tp16.3-schnitt" genannt. **Keiner verworfen:** der ältere liegt jetzt als
@@ -133,6 +133,7 @@ nie auf ein Trennzeichen, das auch im Präfix vorkommt.
 1. **Entscheidung zu Punkt 2** (sechs Drifts ins Soll heben) — vor dem Flip, sonst geht man mit
    erklärter, aber ungeklärter Drift in den Produktivpfad.
 2. **§5 CNAME-Flip**, einzeln mit Abnahme dazwischen, Testname zuerst (§5.1).
+   ▸ Fertiger Übergabeprompt: [`tp16.3-paragraph5-session-handoff-prompt.md`](tp16.3-paragraph5-session-handoff-prompt.md).
    🔴 `healthy` beweist nur, dass der Connector mit Cloudflare redet — **nicht**, dass das Origin
    antwortet. Der Streckenbeweis bis Caddy ist §5.1.
 3. **§6 Abbau** frühestens 7 Tage nach dem Flip.
diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md
index e59e827..e953d8a 100644
--- a/docs/teilprojekte.md
+++ b/docs/teilprojekte.md
@@ -2495,6 +2495,9 @@ kann in Ruhe nachziehen.
 <a id="tp37"></a>
 ### TP38 — Out-of-Band-Management: ein untagged-VLAN99-Port je Switch ▸ 🔜 **ANGELEGT 2026-08-31**
 
+*(Nummer 2026-08-31 von 37 auf 38 korrigiert und von Christoph bestätigt: TP37 war zeitgleich in
+einem zweiten Branch für „Nautobot als Netzwerkdoku" vergeben worden.)*
+
 > **Auslöser (User 2026-08-31, aus eigener Anschauung):** *„ich durfte beim Neustart vom core gerade
 > erleben, dass ich nicht mehr auf den branch zum verbinden kam. weil das eben alles über den core
 > läuft."*
diff --git a/docs/tp16.3-paragraph5-session-handoff-prompt.md b/docs/tp16.3-paragraph5-session-handoff-prompt.md
new file mode 100644
index 0000000..63c8c8c
--- /dev/null
+++ b/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.