TP25: ft=no auf sec-main als Dauerzustand (User-Entscheid 2026-09-04)

Hebel 2 (ft=no) doch gezogen: sec-main von ft=yes ft-over-ds=yes auf
ft=no ft-over-ds=no. Template (nautobot/mikrotik_routeros.j2) + Push nach
bf-golden-config + Nautobot-Sync; wifi-security damit gruen (Live stand
schon auf ft=no, das Template war der Drift).

Doku nachgezogen (CLAUDE.md Punkt 5, teilprojekte.md Ist-Stand/Quick-Index/
Fund-E-Block): Soll ft=yes ft-over-ds=yes -> ft=no ft-over-ds=no, 802.11r aus.

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

docs/teilprojekte.md

@@ -28,7 +28,10 @@ Mgmt (VLAN99, Ist 2026-08-16): core `.99.1` · branch `.99.2` · ap1 `.99.11` ·
 ## Ist-Stand (Kurz)
 
 **Stand 2026-09-04 — live gegen die Geräte geprüft (MikroMCP/REST/SSH), nicht aus der Doku abgeschrieben.**
-**Compliance 140/140** (nach TP42, 2026-09-02).
+**Compliance 138/140** — 2 Drifts, beide aus der Kanalplan-Arbeit: `wifi-channel` (offene Transaktion
+`TP25-kanalplan-ap1-live`, im Scope) + `wifi-provisioning` (ap1-Provisioning-Regeln, **AUSSERHALB** des
+Transaktions-Scopes — Side-Effect des ap1-Reaktivierens). `wifi-security` gruen seit 2026-09-04 (`ft=no`
+auf `sec-main`, s. unten).
 *(Die Fassung vom 2026-08-16 stand bis zum 18. hier und war an vier Stellen überholt. Wer diesen Block
 liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
 - ✅ **TP25 Multi-Pin-Konsole (2026-09-04):** die Klick-Konsole (`docs/tp6-marker/server.py`) ist auf
@@ -41,7 +44,9 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
   `reauthenticating` am 09-02 nur noch **4 in 8,6 h** (alle iPhone `F2:62`, isolierte Einzel, 0 Ausfälle)
   gegen Baseline 93 bzw. Hebel-1 **19/h**. Verlauf **218 → 40 → 4**; Vorbedingung geprüft (Core-Uptime
   1d18h, `caps joined=0` → keine Reboot-Artefakte). ⇒ **7.24.1 (TP27) war die Ursache/der Fix, nicht
-  `ft-over-ds`.** Hebel 1 widerlegt+zurückgebaut, Hebel 2–4 entfallen, **kein Geräte-Write**. Offen in
+  `ft-over-ds`.** Hebel 1 widerlegt+zurückgebaut, Hebel 2–4 entfallen, **kein Geräte-Write**. **Am
+  2026-09-04 hat Christoph `ft=no` auf `sec-main` als Dauerzustand entschieden** (Hebel 2 doch gezogen,
+  Template + bf-golden-config + Nautobot-Sync, `wifi-security` gruen). Offen in
   TP25 bleibt nur der separate Punkt **ap2 unterperformt** (2 m/−80 dBm). Handoff:
   [`docs/handoff-20260902-tp25-fund-e-messung.md`](handoff-20260902-tp25-fund-e-messung.md).
 - ⏸️ **TP41 CF-Access-Reparatur — ZURÜCKGESTELLT 2026-09-01 (User-Entscheid; Rest wartet auf Info):** Session 720h,
@@ -268,7 +273,8 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
 - **WLAN = CAPsMAN auf dem Core** (TP28 ✅ 08-17, GC-Modell nachgezogen 08-18): ap1 **`10.40.99.11`**
   (an core `ether15`), ap2 **`10.40.99.12`** (an branch `ether24`), beide **reine CAPs** —
   `cap enabled=yes`, `discovery-interfaces=vlan99`. Die APs halten **keine eigene WLAN-Config** mehr;
-  Kanäle, SSIDs, Security und Steering kommen vom Manager. 802.11r/k/v aktiv, `ft-over-ds=yes`.
+  Kanäle, SSIDs, Security und Steering kommen vom Manager. 802.11k/v aktiv; **802.11r (FT) aus** —
+  `ft=no` auf allen SSIDs (sec-main seit 2026-09-04, User-Entscheid).
   🆕 **Dritter AP `ap3` (cAP ax) ✅ LIVE seit 2026-08-30** (TP28 dafür wieder geöffnet):
   `10.40.99.13`, Uplink `ether1` → **core `ether21`** (Trunk), reiner CAP, **RouterOS 7.24.1**
   (🆕 **seit 2026-08-31 die ganze Flotte** — die frühere Versionsdifferenz ist aufgelöst). Kanäle
@@ -512,7 +518,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 ✅ geschlossen 09-02: 7.24.1 war die Ursache, nicht `ft-over-ds` (4/8,6 h, 0 Ausfälle)**; **Konsole auf N Clients + Pin-UI ✅ 09-04**; offen nur ap2 unterperformt (2 m/−80, In-situ) | 2026-09-04 |
+> | TP25 | ⏳ | WLAN-Stabilisierung (Kern ✅) — **Fund E ✅ geschlossen 09-02: 7.24.1 war die Ursache, nicht `ft-over-ds` (4/8,6 h, 0 Ausfälle)**; **`ft=no` auf `sec-main` als Dauerzustand ✅ 09-04**; **Konsole auf N Clients + Pin-UI ✅ 09-04**; offen nur ap2 unterperformt (2 m/−80, In-situ) | 2026-09-04 |
 > | TP28 | ✅ | WLAN/CAPsMAN — dritter AP `ap3` (cAP ax) **live** | 2026-08-30 |
 > | TP29 | 💡 | Anwesenheitserkennung (Idee) | — |
 > | TP30 | 🔜 | Credentials (Etappe 1 ✅, Rest gebündelt) | — |
@@ -1772,7 +1778,7 @@ die alte Liste führte `2g-probe-delay` an, das aber **Band-Steering** adressier
 | # | Hebel | Begründung der Reihenfolge | Risiko | Stand |
 |---|---|---|---|---|
 | 1 | **`ft-over-ds=no`** auf `sec-main` | nimmt die Änderung vom 08-17 zurück; FT bleibt über `ft=yes` (over-the-air) erhalten. Kleinster Eingriff, der die verdächtige Achse trifft | gering | ❌ **widerlegt** — lief 6,4 h allein → 124× (≈19/h) + 2 Ausfälle, **zurückgebaut 2026-09-01** |
-| 2 | `ft=no` auf `sec-main` | falls (1) nicht reicht: FT komplett aus. Kostet Roaming-*Geschwindigkeit*, nicht Roaming | mittel | ⏹️ entfällt — 7.24.1 löste Fund E (Messung 09-02) |
+| 2 | `ft=no` auf `sec-main` | falls (1) nicht reicht: FT komplett aus. Kostet Roaming-*Geschwindigkeit*, nicht Roaming | mittel | ✅ **gezogen 2026-09-04** (User-Entscheid, Dauerzustand — Template + bf-golden-config + Nautobot-Sync) |
 | 3 | `2g-probe-delay=yes` (2,4-GHz-Configs) | MikroTiks *dafür gebautes* Werkzeug; verzögert nur Probe-Antworten und **kann keinen Client stranden lassen**. Adressiert die **Band-Oszillation** — ein anderes Symptom | sehr gering | ⏹️ entfällt (Fund E geschlossen) |
 | 4 | `signal-range`-Boden per `access-list` (Fund E im Original) | **kann Clients aussperren** — genau das war 08-22 das Gegenargument; nur mit gemessenem Wert | hoch | ⏹️ entfällt (Fund E geschlossen) |
 
@@ -1780,7 +1786,8 @@ die alte Liste führte `2g-probe-delay` an, das aber **Band-Steering** adressier
 > `ft-over-ds=yes` **und** 7.24.1 verschwunden — 09-02 nur **4 reauth in 8,6 h** (alle iPhone `F2:62`, isolierte
 > Einzel, 0 Ausfälle), Verlauf **218 → 40 → 4**. Vorbedingung geprüft (Core-Uptime 1d18h, `caps joined=0`).
 > ⇒ **7.24.1 war die Ursache/der Fix, nicht `ft-over-ds`.** Hebel 1 widerlegt+zurückgebaut, Hebel 2–4 entfallen,
-> **kein Geräte-Write** (Soll steht: `ft=yes ft-over-ds=yes`, Compliance 140/140). Der folgende Detailblock zu
+> **kein Geräte-Write** (Soll stand: `ft=yes ft-over-ds=yes`, Compliance 140/140). **Am 2026-09-04 hat
+> Christoph `ft=no` auf `sec-main` als Dauerzustand entschieden** (Hebel 2 doch gezogen). Der folgende Detailblock zu
 > Hebel 1 ist historisch.
 
 #### 🔬 Hebel 1 — gezogen am 2026-08-31 08:09, Messung läuft bis 2026-09-01