diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md
index 5a6971f..735bf2a 100644
--- a/docs/teilprojekte.md
+++ b/docs/teilprojekte.md
@@ -1160,10 +1160,14 @@ Cloud-Updates** startet die DTU eine neue TCP-Session — und dabei (unser Log-B
 sich mit dem Befund aufs Minutenkomma. Ursache war hmsmqtt mit **30 500 ms** (Grenzzone);
 DTU-Firmware aelter, hmsmqtt funktioniert (⇒ #134-Key-Rotation-Falle nicht primaer).
 **Hebel = Poll-Rate, nicht DNS-Hoheit:** Christoph hat **30500 → 45000 ms** gesetzt (09-14 abends;
-Community-Wert, 10 Monate stabil). **Verifikation ab 09-15 frueh:** morgendlicher Log-Lauf muss ohne
-4–5-min-Zyklen bleiben — zugleich Fund-F-Abschlussbeweis. Fallback bei fortbestehendem Zyklus:
-DTU-Firmware klaeren (01.01.00+ ⇒ ~90 s oder Downgrade, ha-hoymiles-wifi#134). Messplan #225 wird
-damit zur Verifikationsmessung nach der Umstellung.
+Community-Wert, 10 Monate stabil). ✅ **Verifikation DURCH (09-15, 12:11; [Issue #17, Kommentar
+#230](https://gitea.emsenhuber.net/admin/bf-infra/issues/17#issuecomment-230)): DTU online seit 06:41:49,
+uptime 5 h 29 min, 0 Disconnects** (Vergleich 09-14 mit 30,5 s: fuenf Zyklen in den ersten 18 min).
+Die DTU sitzt heute auf **ap3-2,4** (cap-wifi4-virtual1, −49; cap-Karte unveraendert, Attribution
+belastbar) — also aktuell auch vom Terrassen-Band ch11 weg. **Fund F ist damit abgeschlossen** —
+Ursache war die DTU-Cloud-Recovery, getriggert durch hmsmqtt-Polling-Kollision. Messplan #225 ist
+gegenstandslos (der zu messende Effekt existiert nicht mehr); eine ch11-Tagzeitmessung bleibt nur
+sinnvoll, falls die Terrasse tagsueber weiterhin Call-Probleme zeigt.
 Randnotizen: ap1 „FUNKSTILL" im CLAUDE.md ist überholt (dient live, Radar-Event 16:51 auf 5280
 sauber abgehandelt); Template-Abschnitt [6c] („Fund E WIEDER OFFEN", Stand 08-30) ist inhaltlich
 überholt — beim nächsten Template-Edit mit aktualisieren, kein separater Edit nur für den Kommentar.