TP25 Fund E: Hebel 1 widerlegt und zurueckgebaut -- Ringpuffer-Messfehler korrigiert

Zwei Sessions haben denselben Fall bewertet und kamen zu entgegengesetzten
Schluessen. Aufgeloest zugunsten der Kollektor-Messung.

Der Widerspruch und sein Beleg:
- Die Nacht-Session las `get_log ... sinceMinutes=1440` -> total 0 und schloss
  auf "Fund E geheilt, Hebel 1 committen". Das ist der FLUECHTIGE Ringpuffer des
  Routers: live nachgemessen 1000 Zeilen, aeltester Eintrag 01.09. 00:38:58 --
  keine 9 h Tiefe. Der Core-Reboot 14:36 hatte ihn geleert, der 31.08. Vormittag
  war darin nicht enthalten. "total 0" hiess "im Puffer nichts", nicht "in 24 h
  nichts" -- genau die Falle, wegen der am 30.08. der Kollektor gebaut wurde.
- Im Kollektor stehen fuer 08:09-14:36 (Hebel 1 ALLEIN, vor dem Upgrade) 124x
  reauthenticating: 09h=1, 11h=2, 12h=20, 13h=31, 14h=70 -- alle vom iPhone
  allein, also Client-Befund nach der eigenen Merkregel. Dazu Christophs zwei
  erlebte Ausfaelle 13:16 und 14:23. Zwischen 09:00 und 14:36 lag kein Reboot.

Daraus gehandelt (User-Entscheid: symmetrisch am Geraet, jetzt):
- Backup pre-tp25-funde-rollback, dann ft-over-ds=yes + remote-cap provision
- Rueckbau-Diff zeigte genau eine Abweichung, kein Kollateral
- Abnahme: CAPs durchgehend Ok, ap2 9/9 und ap3 9/9 running, frische DHCP-Lease
  (~1 min alt), Transaktion "zurueckgebaut", Compliance 140/140
- Der Rueckbau IST das Experiment: bleibt es ruhig, war 7.24.1 die Ursache;
  kehrt das Haemmern zurueck, hatte die Nacht-Session recht. Bis zur Messung
  am 2026-09-02 frueh committet niemand.

Zwei Nebenbefunde:
- gc-configplan.py --refresh-compliance scheitert STILL ohne NAUTOBOT_TOKEN:
  Meldung ausgegeben, aber Exit-Code 0. Gehoert gefixt.
- Compliance ist 140/140, nicht 135/135: es gibt eine 28. ComplianceRule
  `interface-veth`, angelegt 31.08. 20:04, Urheber offen.

Der ap2-Befund der Nacht-Session (2 m Abstand, -80 dBm, 0 Clients auf ap2)
bleibt unberuehrt gueltig und ist weiter der beste Hinweis auf die
23:02-Stoerung. CLAUDE.md enthaelt in diesem Commit auch deren TP16.3-Zeile
(gemeinsame Datei, Hunks nicht trennbar).

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

docs/teilprojekte.md

@@ -266,14 +266,26 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
   in den TP5-Kollektor (`10.40.20.18:514`); `/system logging` steht unter der **27. ComplianceRule**
   `system-logging`. Vorher nur Ringpuffer → ein seit Wochen gemeldeter iPhone-Abbruch war rückwirkend
   nicht diagnostizierbar.
-- 🟢 **TP25 Fund E — Hebel 1 wirkt DOCH, im sauberen Fenster (Stand 2026-09-01 ~01:20):** die
-  „GESCHEITERT"-Wertung darunter beruhte auf 08:09–14:36, also **vor** dem 14:36-Core-Reboot und
-  mitten in den TP27-Upgrade-Reboots (Infrastruktur-Burst, viele MACs). Das **erste ungestörte
-  Fenster** — seit dem Reboot 14:36 bis 01:20, **10,7 h** — zeigt am Manager **0× `reauthenticating`**
-  (Tages-Query `sinceMinutes=1440`, `prefix=reauthenticating`, total 0), Baseline war 93×.
-  ⇒ Das reauth-Symptom ist **weg**; die 124× fielen in die Upgrade-Reboots. **Empfehlung: Hebel 1
-  committen** (`ft-over-ds=no` ins Template Z.220, dann Nautobot-Resync + Compliance + `gc-transaktion
-  commit`) — **git-push-Kette, wartet auf Christophs Go.**
+- ⚖️ **TP25 Fund E — Hebel 1 ZURÜCKGEBAUT, Entscheidung faellt am 2026-09-02 (Stand 09-01 09:2x):**
+  Zwei Sessions haben denselben Fall bewertet und kamen zu entgegengesetzten Schluessen. **Aufgeloest
+  zugunsten der Kollektor-Messung:**
+  - Die Nacht-Session las `get_log … sinceMinutes=1440` → `total 0` und schloss auf „geheilt". Das ist
+    der **fluechtige Ringpuffer des Routers**: live nachgemessen **1000 Zeilen, aeltester Eintrag
+    01.09. 00:38:58** — keine 9 h Tiefe. Der Core-Reboot 14:36 hatte ihn geleert, der 31.08. Vormittag
+    war darin **nicht sichtbar**. 🔴 Genau die Falle, wegen der am 30.08. der persistente Kollektor
+    eingerichtet wurde.
+  - Im **Kollektor** stehen fuer 08:09–14:36 (Hebel 1 **allein**, vor dem Upgrade) **124×
+    `reauthenticating`**, Stundenverteilung 09h=1 · 11h=2 · 12h=20 · 13h=31 · 14h=70, **alle vom
+    iPhone allein** (= Client-Befund nach der eigenen Merkregel „viele MACs = Infrastruktur"), dazu
+    Christophs **zwei erlebte Ausfaelle** um 13:16 und 14:23. Zwischen 09:00 und 14:36 gab es
+    **keinen Reboot**, der sie erklaeren koennte.
+  - ⇒ Hebel 1 hat im upgrade-freien Fenster **nichts** bewirkt; der Einbruch faellt exakt auf 7.24.1.
+  **Deshalb am 2026-09-01 zurueckgebaut** (`ft-over-ds=yes`, Provisionierung nachgezogen, frische
+  DHCP-Lease abgenommen, Transaktion **`zurueckgebaut`**, **Compliance 140/140**). Der Rueckbau **ist
+  das Experiment**: bleibt es ruhig, war 7.24.1 die Ursache; kehrt das Haemmern zurueck, hatte die
+  Nacht-Session recht und Hebel 1 wird als neue Transaktion erneut gezogen. **Bis zur Messung am
+  2026-09-02 frueh committet niemand.** Handoff:
+  [`handoff-20260901-fund-e-hebel1-zurueckgebaut.md`](handoff-20260901-fund-e-hebel1-zurueckgebaut.md).
 - 🔴 **ABER: neuer Teilbefund am 23:02 (2026-08-31) — `ap2` unterperformt, NICHT FT.** Christoph am
   Schreibtisch, 5G, kein Telefonat. Log: iPhone `F2:62:4C:E1:AF:09` ping-pongt im Sekundentakt
   `cap-wifi5 ↔ cap-wifi6` = **beide Radios von ap2** (5G 5220 ↔ 2,4G ch11/2462, Band-Steering-Thrash
@@ -450,7 +462,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
 > | TP20.1 | 🔜 | Vaultwarden → Platform-PG | — |
 > | TP23 | ✅ | DNS-Policy (Stufe 1+2 ✅) | 2026-08-26 |
 > | TP24 | 🔜 | DC-USV | — |
-> | TP25 | 🔬 | WLAN-Stabilisierung (Kern ✅) — **Fund E reauth geheilt (0×/10,7 h), Hebel 1 commit-bereit; NEU ap2 unterperformt (2 m/−80, In-situ)** | 2026-09-01 |
+> | TP25 | 🔬 | WLAN-Stabilisierung (Kern ✅) — **Fund E: Hebel 1 widerlegt + zurückgebaut, Messung bis 09-02; ap2 unterperformt (2 m/−80, In-situ)** | 2026-09-01 |
 > | TP28 | ✅ | WLAN/CAPsMAN — dritter AP `ap3` (cAP ax) **live** | 2026-08-30 |
 > | TP29 | 💡 | Anwesenheitserkennung (Idee) | — |
 > | TP30 | 🔜 | Credentials (Etappe 1 ✅, Rest gebündelt) | — |
@@ -1451,7 +1463,7 @@ des Dimmers (= Lichtausfall in Diele UG/Wohnzimmer) wurde daraufhin **nicht** au
 - **Abh.:** keine harten. **TP15 ✅** (die zu versorgende Hardware steht und hat DC-Eingänge). Verwandt: **TP18** (Garage-Nodes brauchen je Site eine Stromversorgung), **TP11** (USV-Zustand ins Monitoring). **Kein Blocker für TP5/TP6.**
 - **Historie:** war bis 2026-08-16 Unterpunkt von TP15 („🔋 DC-USV: MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt"). Vollständige Recherche inkl. Schaltbild, Effizienzvergleich und Gerätetabelle: `docs/hw-refresh-requirements.md §9` (+ §10 D/E/F für die offenen Fragen).
 
-### TP25 — WLAN-Stabilisierung ▸ 🔬 **FUND E: reauth im sauberen Fenster geheilt (0×/10,7 h, 2026-09-01) → Hebel 1 commit-bereit; NEU: ap2 unterperformt (2 m/−80 dBm, 23:02-Befund) als eigener In-situ-Unterpunkt** · Kern erledigt: 🟢 **(2026-08-22) Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). **Fund F ✅ aufgelöst (08-24, geräteseitig — kein Netzfehler)**, **5-GHz-Umfeldscan ✅ (08-24)**, Kanalplan für AP 3 ✅ gerechnet. Offen nur noch die Umsetzung, wenn der dritte AP kommt. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6
+### TP25 — WLAN-Stabilisierung ▸ 🔬 **FUND E: Hebel 1 widerlegt (124× im upgrade-freien Fenster) und am 2026-09-01 ZURÜCKGEBAUT — Entscheidung faellt mit der Messung am 09-02; NEU: ap2 unterperformt (2 m/−80 dBm, 23:02-Befund) als eigener In-situ-Unterpunkt** · Kern erledigt: 🟢 **(2026-08-22) Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). **Fund F ✅ aufgelöst (08-24, geräteseitig — kein Netzfehler)**, **5-GHz-Umfeldscan ✅ (08-24)**, Kanalplan für AP 3 ✅ gerechnet. Offen nur noch die Umsetzung, wenn der dritte AP kommt. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6
 > 📚 **Kondensiert am 2026-08-23 (Doku-Session, Punkt F).** Dieser Abschnitt war mit 394 Zeilen
 > 18 % der Datei. Die **Langfassung steht vollständig und unverändert** im Archiv:
 > [`teilprojekte-archiv.md` → TP25 (Langfassung)](teilprojekte-archiv.md#tp25-lang) — Messchronik (A)–(G),
@@ -1823,7 +1835,7 @@ die Redundanzfrage oben.
 - **Abh.:** TP22 ✅ (GC-Deploy-Pipeline). Verwandt **TP3.2** (`docs/wifi-p750w-coverage-and-map.md`),
   **TP29** (nutzt dieselbe Datenquelle als Sensor). **Kein Blocker für irgendetwas.**
 
-#### 🔬 Fund E — 2026-09-01: Hebel 1 wirkt im sauberen Fenster + neuer Teilbefund `ap2`
+#### 🔬 Fund E — 2026-09-01: der `ap2`-Teilbefund (gültig) und eine widerlegte Heilungs-Wertung
 
 **Anlass:** Christoph meldete **2026-08-31 23:02** eine Störung am Schreibtisch (5G, iPhone, kein
 Telefonat). Analyse (alles read-only am Manager `crs326-core`):
@@ -1844,10 +1856,24 @@ Telefonat). Analyse (alles read-only am Manager `crs326-core`):
   auf ap2 temporär deaktivieren (ap3 übernimmt den Schreibtisch), ap2-Antenne/HW prüfen. **Keine
   Änderung ohne diese Messung.**
 
-**Fund E (`reauthenticating`) ist davon getrennt und im sauberen Fenster geheilt:** seit dem
-14:36-Core-Reboot bis 01:20 (**10,7 h, ungestört**) **0× `reauthenticating`** (`sinceMinutes=1440`,
-`prefix=reauthenticating`, total 0), Baseline 93×. Die „GESCHEITERT/124×"-Wertung fiel in die
-TP27-Upgrade-Reboots (Infrastruktur-Burst über viele MACs). ⇒ **Hebel 1 hat sein Ziel erreicht.**
+🔴 **WIDERRUFEN am 2026-09-01 vormittags — der zweite Teil dieses Abschnitts war ein Messfehler.**
+Ursprünglich stand hier: „Fund E ist im sauberen Fenster geheilt — 0× `reauthenticating` seit dem
+14:36-Reboot (`sinceMinutes=1440`, total 0), also hat Hebel 1 sein Ziel erreicht."
+
+**Warum das nicht trägt:** `get_log` liest den **flüchtigen Ringpuffer des Routers**, nicht den
+Kollektor. Live nachgemessen fasst er **1000 Zeilen und reicht bis 01.09. 00:38:58 zurück** — keine
+9 Stunden. Der Core-Reboot um 14:36 hatte ihn geleert; der 31.08. Vormittag war darin gar nicht
+enthalten. `total 0` hieß **„im Puffer nichts", nicht „in 24 h nichts"**. Das ist exakt die Falle,
+wegen der am 30.08. das persistente Logging gebaut wurde.
+
+**Was der Kollektor zeigt:** im upgrade-freien Fenster 08:09–14:36 (Hebel 1 **allein**) **124×
+`reauthenticating`** — 09h=1 · 11h=2 · 12h=20 · 13h=31 · 14h=70, **alle vom iPhone allein**, dazu
+Christophs zwei erlebte Ausfälle 13:16 und 14:23. Zwischen 09:00 und 14:36 lag **kein Reboot**.
+⇒ Hebel 1 wurde am 2026-09-01 **zurückgebaut**; der Rückbau ist das entscheidende Experiment
+(s. Ist-Stand-Block oben).
+
+✅ **Der `ap2`-Teilbefund oben bleibt davon unberührt und gültig** — er ist unabhängig gemessen und
+erklärt die 23:02-Störung, die weder FT noch Coverage erklärt.
 
 **Commit-Weg (wartet auf Christophs Go — git-push-Kette):** Template `nautobot/mikrotik_routeros.j2`
 **Z. 220** `sec-main` von `ft-over-ds=yes` → `ft-over-ds=no`; dann Template-Repo nach Nautobot syncen,