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