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/handoff-20260831-tp16.3-vorort-session.md

@@ -80,10 +80,16 @@ kann nur vom Server kommen, die Firewall-Freigabe trägt also. cloudflared schic
 
 ## 5. Offene Punkte, die NICHT in diese Session gehören
 
-1. 🔴 **Compliance-Drift `crs326-core` / `wifi-security` (134/135).** `sec-main` hat am Gerät
-   `ft-over-ds=no`, Soll `yes` (`ft=yes` ist korrekt). **Kam mit dem 7.24.1-Upgrade.** Braucht eine
-   Entscheidung — Gerät korrigieren *oder* neuen Wert zum Soll erklären — plus Re-Provisionierung der
-   CAPs. ⚠️ **Kein Re-Baseline ohne Entscheid**, das macht die Drift-Erkennung wertlos.
+1. ✅ **Die 134/135 sind ABSICHT — nichts tun.** `crs326-core` / `wifi-security`: `sec-main` hat
+   `ft-over-ds=no` statt `yes`. Das ist **TP25 Fund E, Hebel 1**, am 2026-08-31 um 08:09 bewusst gesetzt
+   und als **offene Transaktion `TP25-fund-e-ft-over-ds`** geführt (Scope `wifi-security`, Ablauf
+   2026-09-03, gehört einer anderen Session). **Nicht anfassen, nicht grün machen, nicht re-baselinen** —
+   das würde einen laufenden Versuch unsichtbar machen.
+   *(Eine frühere Fassung dieses Handovers schrieb die Drift dem 7.24.1-Upgrade zu. Falsch: der Hebel
+   kam um 08:09, der Core wurde erst 14:36 gehoben.)*
+   🔑 **Merkregel für die Session:** wenn Compliance nicht 135/135 zeigt, **zuerst**
+   `nautobot/gc-transaktion.py status` lesen. Drift aus einem laufenden Versuch sieht genauso aus wie
+   ein Versehen.
 2. 🆕 **[TP37](teilprojekte.md#tp37) — OOB-Management, angelegt 2026-08-31.** Je ein untagged-VLAN99-Port
    auf beiden Switches (Kandidat `ether23`, auf core **und** branch frei). Auslöser: beim Core-Neustart
    war `crs326-branch` nicht erreichbar, weil sein Mgmt **ausschließlich** über den Core läuft.
@@ -123,4 +129,5 @@ Gerät (wie die genehmigte Ausnahme #2 beim CRS326-Bring-up). Die GC-Pflicht gil
 - [ ] `.tar` je AP gelöscht (Flash zurück)
 - [ ] `bf-public` meldet `healthy` mit Connectoren > 0
 - [ ] WLAN je AP zurück — **frische DHCP-Lease pro SSID**, nicht Registration-Table
-- [ ] Compliance nicht schlechter als **134/135** (die `wifi-security`-Drift aus Punkt 5.1 bleibt bestehen)
+- [ ] Compliance nicht schlechter als **134/135** — die `wifi-security`-Drift ist die offene
+      TP25-Transaktion aus Punkt 5.1 und **muss** bestehen bleiben

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