diff --git a/docs/handoff-doku-session-20260818.md b/docs/handoff-doku-session-20260818.md
index 52e80cf..fad119a 100644
--- a/docs/handoff-doku-session-20260818.md
+++ b/docs/handoff-doku-session-20260818.md
@@ -83,9 +83,34 @@ Chronologisch, alles verifiziert und committet:
    Quelle, DHCP-Option 42, ComplianceRule `system-ntp`.
 6. **TP7.1 — SSDP-Relay** als LXC 108 auf pve. User-bestätigt: „sonos ist da!"
 7. **TP28-Rest — GC-Modell auf CAPsMAN umgebaut.** Die APs trugen noch die komplette
-   Standalone-WLAN-Config aus TP3; abgeräumt ohne einen Client zu verlieren.
+   Standalone-WLAN-Config aus TP3; abgeräumt.
 8. **TP19 und TP3.2 geschlossen.**
 
+### ⚠️ Korrektur zu Punkt 7 — und die wichtigste Lehre der ganzen Nacht
+
+Ich hatte den AP-Cleanup mit „30 Clients vorher, 30 nachher, kein Aussetzer" abgenommen. **Das war der
+falsche Maßstab.** Parallel lief bereits ein Ausfall, den genau diese Zahl verdeckt hat:
+
+Seit dem CAPsMAN-Cutover vom **08-17** war `/interface wifi cap slaves-datapath` auf beiden APs **leer**
+— das einzige Feld, das die vom Manager erzeugten Slave-VAPs lokal in die Bridge hängt. Der Core schickt
+`datapath.bridge=bridge` mit, der CAP übernimmt davon aber **nur die `vlan-id`**. Folge: `-iot`, `-media`,
+`-untrusted` und `-guest` hingen **in gar keiner Bridge**. Clients assoziierten sauber und bekamen
+**nie DHCP** — **14 Stunden lang**. `dirtyvader-main` lief weiter, weil `wifi1`/`wifi2` statische
+Bridge-Ports sind, und hat den Ausfall getarnt.
+
+Gefunden und behoben hat es Christoph am 08-18 um 09:13 (Commit `1ba8260`): `dp-caps-slaves`
+(`bridge=bridge`, bewusst **ohne** `vlan-id`) + `slaves-datapath` darauf, auf beiden APs.
+
+**Zwei Konsequenzen, die du kennen solltest:**
+
+1. **Die Registration-Table ist kein Abnahmekriterium.** Sie zeigte während des Ausfalls zufriedene
+   IOT-Clients — und ich habe damit „kein Aussetzer" attestiert. **Richtig ist eine frische DHCP-Lease
+   pro SSID.** Steht inzwischen so in `CLAUDE.md`.
+2. **Es war nicht die TP5-Härtung**, obwohl der zeitliche Zusammenfall das nahelegt: `torch` auf vlan30
+   am Core war leer **und** der TP5-Drop-Log zeigte nichts. Beides leer heißt: es kommt nichts an, es
+   wird nichts verworfen → **L2-Problem, nicht Firewall**. Diese Merkregel steht jetzt ebenfalls in
+   `CLAUDE.md` und ist bei künftigen „connect ok, kein DHCP"-Fällen der erste Griff.
+
 **Nautobot-Betrieb:** der Stack hat sich zweimal selbst umgebracht. Ursache war der **Image-Healthcheck**
 (voller Django-Start alle 10 s, Aufrufe stapeln sich → ENOMEM → DSM räumt ab), nicht Celery. Behoben.
 Steht in TP21.