Korrektur: die wifi-security-Drift ist TP25 Fund E, nicht das Upgrade

Ich hatte die 134/135 dem 7.24.1-Upgrade zugeschrieben. Falsch. Auf main steht
a0a650e "TP25 Fund E Hebel 1: ft-over-ds=no auf sec-main, Messung laeuft" --
der Hebel wurde am 2026-08-31 um 08:09 bewusst gesetzt, der Core erst um 14:36
gehoben. gc-transaktion.py status fuehrt TP25-fund-e-ft-over-ds als OFFEN
(Scope wifi-security, Ablauf 2026-09-03, Drift im Scope).

Die 134/135 sind also Absicht, kein Schaden, und brauchen keine Entscheidung
von Christoph -- sie gehoeren einer anderen, laufenden Session. Gruen machen
wuerde den Versuch unsichtbar machen.

Lehre, in beiden Dateien festgehalten: vor jeder Drift-Bewertung
gc-transaktion.py status lesen. Drift aus einem laufenden Versuch sieht
identisch aus wie ein Versehen -- genau dafuer existiert das Werkzeug, und ich
habe es nicht benutzt.

Handover-Punkt 5.1 von "braucht eine Entscheidung" auf "nicht anfassen"
umgestellt, Abnahme-Checkliste entsprechend.

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

docs/teilprojekte.md

@@ -47,11 +47,14 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
   Schutz ist heute allein die Erreichbarkeit über den gehärteten Core. Das ist die Hauptauflage des TPs.
 - 🆕 **ROS-Upgrade 7.24.1 auf allen fünf (2026-08-31, User).** In Nautobot nachgezogen: **ap1** stand
   als einziges Gerät noch auf `7.24` (die anderen vier waren schon richtig) ⇒ auf `7.24.1` gesetzt.
-  🔴 **Eine Drift kam mit dem Upgrade: `crs326-core` / `wifi-security`** — `sec-main` hat am Gerät
-  `ft-over-ds=no`, Soll ist `yes` (`ft=yes` steht korrekt). **134/135 compliant.** Bewusst **nicht**
-  angefasst: das ist eine Roaming-Einstellung und braucht eine Entscheidung (Gerät korrigieren **oder**
-  den neuen Wert zum Soll erklären) plus Re-Provisionierung der CAPs — **nicht nebenbei**.
-  ⚠️ Ein Re-Baseline ohne Entscheid würde die Drift-Erkennung wertlos machen.
+  ⚠️ **Korrektur (2026-08-31, nachträglich):** die dabei gesehene `wifi-security`-Drift auf
+  `crs326-core` (`sec-main` `ft-over-ds=no` statt `yes`) hatte **nichts mit dem Upgrade zu tun** — sie
+  ist **TP25 Fund E, Hebel 1**, um 08:09 bewusst gesetzt (Core-Upgrade war erst 14:36) und als
+  **offene Transaktion `TP25-fund-e-ft-over-ds`** geführt (Scope `wifi-security`, Ablauf 2026-09-03).
+  **Die 134/135 sind Absicht**, nicht Schaden: grün machen würde den laufenden Versuch unsichtbar
+  machen, und `gc-transaktion.py` verweigert den Commit ohnehin, solange der Scope driftet.
+  🔑 **Lehre:** vor jeder Drift-Bewertung `nautobot/gc-transaktion.py status` lesen — Drift aus einem
+  laufenden Versuch sieht identisch aus wie ein Versehen, und genau dafür gibt es das Werkzeug.
 - 🆕 **TP16.3 §1-Blocker remote erledigt (2026-08-31):** Ingress von `bf-public` auf
   `https://10.40.20.40:443` + `originServerName`; Firewall-Freigabe `vlan99 → vlan20:443` **über
   Nautobot GC** (Plan `Completed`, Re-Baseline `ingest-core-firewall.py --apply`, danach