TP25 Fund E geschlossen: 7.24.1 war die Ursache, nicht ft-over-ds

Abschlussmessung 2026-09-02: reauthenticating 218->40->4 (09-02 nur 4 in
8,6 h, alle iPhone F2:62, 0 Ausfaelle). Vorbedingung geprueft (Core-Uptime
1d18h, caps joined=0 -> keine Reboot-Artefakte). Hebel 1 widerlegt+
zurueckgebaut, Hebel 2-4 entfallen, kein Geraete-Write (Compliance 140/140).
Offen bleibt nur ap2-Unterperformance.

- neu: docs/handoff-20260902-tp25-fund-e-messung.md
- teilprojekte.md: Quick-Index + Ist-Stand + TP25-Abschnitt + Hebel-Tabelle
- CLAUDE.md: Pflichtlektuere Punkt 5 auf geschlossen

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

docs/handoff-20260902-tp25-fund-e-messung.md

@@ -0,0 +1,57 @@
+# Handoff 2026-09-02 — TP25 Fund E: die Abschlussmessung, und was sie entschieden hat
+
+**Kurz:** Die für heute früh vorgemerkte Messung ist gelaufen. **7.24.1 hat den
+`reauthenticating`-Sturm aufgelöst, nicht `ft-over-ds`.** Hebel 1 war widerlegt und ist zu Recht
+zurückgebaut; Hebel 2–4 entfallen. **Fund E ist geschlossen** — ohne Geräte-Write.
+
+## Was Fund E war
+
+Ein `reauthenticating`-Sturm, sauber isoliert auf **einen** Client (iPhone
+`F2:62:4C:E1:AF:09`) und **eine** SSID (`dirtyvader-main`, die einzige mit
+`ft=yes ft-over-ds=yes`). Baseline: 93/93 auf genau diesem Client und dieser SSID. Hebel 1
+(`ft-over-ds=no`) lief am 31.08. **6,4 h allein** und machte es **schlimmer** (124 ≈ 19/h + 2
+erlebte Ausfälle) → am 01.09. zurückgebaut, Transaktion `TP25-fund-e-ft-over-ds` geschlossen.
+Der Einbruch auf ~0/h fiel exakt auf das **TP27-Upgrade 7.24.1** (Core-Reboot 31.08. 14:36).
+
+## Vorbedingung zuerst (CLAUDE.md-Gotcha: „grep caps + uptime vor Client-Diagnose")
+
+- Core-Uptime **1d18h** → letzter Reboot 31.08. 14:36; **kein** Reboot am 01./02.09.
+- `caps joined = 0` an beiden Tagen.
+- ⇒ Die Zahlen unten sind echte Client-Ereignisse, keine Reboot-Artefakte.
+
+## Messung (Kollektor `/opt/tp5-syslog/log/10.40.20.1/`, via pve→`pct exec 400`)
+
+| Tag | reauth total | davon iPhone F2:62 | distinct MACs | data loss / deauth | Kontext |
+|---|---|---|---|---|---|
+| 08-31 | 225 | 218 | 6 | (Upgrade+Hebel1) | Hebel-1-Fenster + 2 Upgrade-Reboots |
+| 09-01 | 44 | 40 | 4 | 0 | 7.24.1, Hebel 1 mittags zurückgebaut |
+| **09-02** (00:00–08:37) | **4** | **4** | **1** | **0** | 7.24.1 + `ft-over-ds=yes`, sauberes Fenster |
+
+- **218 → 40 → 4.** Am 09-02 vier isolierte Einzelereignisse (01:13, 02:00, 03:14, 08:01),
+  **kein Burst**, alle `dirtyvader-main` (Interface `cap-wifi3`/`cap-wifi6` — die `cap-wifiN`-Karte
+  wandert, deshalb NICHT einem AP zugeschrieben). ≈ **0,46/h** gegen Baseline 93 bzw. Hebel-1 **19/h**.
+- Der iPhone ist **präsent und stabil** — er verbindet und erzeugt die 4 Zeilen, ist also nicht
+  „still, weil abwesend".
+- Die 97 `association rejected` am 09-01 fallen auf den **Rollback-/Re-Provisioning-Vorgang**
+  (viele MACs = Infrastruktur, per Gotcha), nicht auf einen Client; am 09-02 nur 5.
+
+## Schluss & Entscheidung
+
+**7.24.1 war die Ursache/der Fix, nicht `ft-over-ds`.** Der Restwert (~0,5/h isolierte
+Einzel-Reauth eines iPhones, 0 Ausfälle) ist normales iOS-Roaming, kein Defekt.
+**Hebel 2–4 (`ft=no`, `2g-probe-delay`, `signal-range`) werden NICHT gezogen. Fund E geschlossen.**
+
+Kein Geräte-Write: Sollzustand steht bereits (`sec-main` = `ft=yes ft-over-ds=yes`, Flotte 7.24.1,
+Transaktion `zurueckgebaut`, Compliance **140/140**).
+
+## Bleibt offen (nicht Fund E)
+
+- **ap2 unterperformt** (2 m / −80 dBm, 23:02-Befund) — eigener In-situ-Unterpunkt in TP25,
+  kein FT-/Auth-Thema. TP25 bleibt deshalb als Sammel-TP offen.
+
+## Merkregel bestätigt
+
+Der Fall ist ein Lehrstück für zwei CLAUDE.md-Regeln: (a) **Reboots zuerst ausschließen** hätte am
+31.08. verhindert, den Upgrade-Reboot-Burst für Client-Instabilität zu halten; (b) **eine Drift/ein
+Symptom im offenen Versuch sieht aus wie ein Defekt** — Hebel 1 „verbesserte auf 0/h" war in
+Wahrheit das parallele Upgrade. Die einzelne Messung nach dem Rückbau hat beides getrennt.