TP28 dokumentiert: CAPsMAN-Cutover durch, zwei Messfallen festgehalten

Der Cutover ist durch (34 Clients, iot=27, beide CAPs Ok, Roaming belegt).
Festgehalten sind vor allem die zwei Fallen, die mich Zeit und Christoph das
halbe IoT-Netz gekostet haben:

1. Unter CAPsMAN fuehrt der MANAGER die registration-table und die
   wireless-Logs, nicht der CAP. Auf ap1/ap2 sind beide leer, obwohl das WLAN
   laeuft — ich habe daraus zweimal faelschlich 'WLAN ist unten' geschlossen.

2. Drei uebereinstimmende .rsc-Dateien sind nicht drei Belege, wenn sie aus
   demselben Bring-up stammen. Genau daran habe ich wlan-psks.env fuer
   veraltet gehalten und ueberschrieben. Die Passphrasen sind am Geraet per
   REST lesbar — das ist der Weg, nicht der Dateivergleich.

Offen: das GC-Modell beschreibt weiter Standalone-APs; die 76/76 ist stale
(13:55 gemessen, Cutover 18:05). wifi-*-Features muessen auf den Core.

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

docs/teilprojekte.md

@@ -1184,6 +1184,50 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   liefert das Entscheidungskriterium). ⚠️ **Berührt TP5:** der Mesh-Verkehr braucht bei deny-by-default eine
   explizite `forward`-Zeile — s. TP5 Etappe 2.
 
+### TP28 — WLAN über CAPsMAN auf `crs326-core` ▸ ✅ **CUTOVER DURCH (2026-08-17)** — beide APs sind reine CAPs
+> **Methodenwechsel auf Christophs Anstoß:** *„ich möchte die methode in frage stellen … eine sot ist zwar nett,
+> aber wenn sie uns das leben zur hölle macht, verzichte ich auf diese governance."* Der Entscheid vom
+> 2026-07-22, CAPsMAN abzuschaffen, ist damit **revidiert**.
+
+- ✅ **Warum es diesmal trägt:** 2026-07-22 war **ap1 Manager UND AP** — und ein Manager kann seine eigenen
+  Radios nicht per CAPsMAN provisionieren (MikroTik-bestätigt). Genau diese Asymmetrie war die Ursache von
+  TP3.1. Mit dem **Core** als Manager sind beide APs symmetrisch. **Der Core braucht dafür kein `wifi-qcom`:**
+  das `capsman`-Menü steckt im Basis-`routeros`, die 3,35 MB freier Flash sind irrelevant. Die zweite
+  Begründung von damals („WLAN instabil") war ohnehin widerlegt — standalone blieb es instabil, die Ursachen
+  waren die Funkparameter aus TP25.
+- ✅ **Ist-Stand:** Manager auf `vlan99`, 4 Kanäle · 6 Datapaths · 6 Security · 2 Steering · 9 Configurations ·
+  4 Provisioning-Regeln je `radio-mac`. Beide `remote-cap` **`Ok`**, je 7 dynamische VAPs. Kanäle exakt wie in
+  TP25 gemessen (ap1 `5180/ax/Ce/I`+`2412/ax`, ap2 `5220/ax/Ce/I`+`2462/ax`). **34 Clients** (main 3, iot 27,
+  media 4), Roaming im Manager-Log belegt. **`ft-over-ds=yes`** ist jetzt aktiv (unter CAPsMAN erstmals
+  verfügbar), `-guest` hat eigenes `st-guest` mit **`neighbor-group=bf-guest`** — nicht `bf-main` mitbenutzen,
+  sonst meldet 802.11k Gast-Clients BSSIDs einer SSID, auf die sie nicht assoziieren können.
+- 📌 **Local-Forwarding ist keine Einstellung mehr:** im neuen `/interface/wifi` gibt es **kein** zentrales
+  Forwarding („There is no CAPsMAN-forwarding in WiFi (RouterOS 7.0+)"). Die `datapath`-Property existiert
+  deshalb nicht — `monitor` bestätigt `traffic processing on CAP`.
+- 🔴 **DIE MESSFALLE DIESES TPs — unter CAPsMAN führt der MANAGER die Tabellen, nicht der CAP.**
+  `/interface/wifi/registration-table` und die `wireless`-Logs sind auf ap1/ap2 **leer**, obwohl das WLAN
+  einwandfrei läuft. Ich habe daraus zweimal „WLAN ist unten" geschlossen, während Christophs Geräte mit
+  vollem Ausschlag verbunden waren und ein Speedtest gut lief. **Immer am Manager zählen.**
+- 🔴 **DIE ZWEITE FALLE — drei übereinstimmende Dateien sind nicht drei Belege.** `wlan-psks.env` wich für
+  iot/untrusted/infra von `ap1-prov-base.rsc`, `ap2-prov-base.rsc` und `ap1-standalone.rsc` ab. Ich habe die
+  drei als Bestätigung gelesen und die env-Datei „korrigiert" — **~20 Shellys waren 20 Minuten aus dem Netz.**
+  Die drei Dateien stammen alle aus dem Bring-up vom 2026-08-08, sind also **eine Quelle in drei Kopien**.
+  ✅ **Auflösung:** die Passphrasen sind am Gerät per REST **lesbar**
+  (`GET http://10.40.99.1/rest/interface/wifi/security`) — dort ausgelesen ergab sich exakt der env-Wert.
+  `wlan-psks.env` ist neu aus dem Live-Stand befüllt und trägt jetzt eine Kopf-Warnung; die drei Baselines
+  sind seit dem Cutover ohnehin nicht mehr deploybar und wurden entschärft (Passphrasen raus, HISTORISCH).
+- ⚠️ **OFFEN — das GC-Modell beschreibt weiter Standalone-APs.** Compliance meldet `76/76`, die Zahl ist aber
+  **stale**: sie lief um 13:55, der Cutover war um 18:05, und ap1s intended config trägt noch 22
+  `/interface wifi`-Zeilen. Nach dem nächsten Refresh driften ap1/ap2 auf allen fünf `wifi-*`-Features.
+  **Nächster Schritt:** die `wifi-*`-Features vom AP-Scope auf den Core umhängen, AP-Template auf die
+  Mini-Config (bridge/VLAN/Mgmt/`cap enabled`) eindampfen. Damit wird auch die bisher fehlende Rule auf
+  `/interface wifi` **gegenstandslos** — ein CAP hat keine Inline-Overrides, die driften könnten.
+- 📌 **Nebenbefund:** HAs `mikrotik`-Integration pollt alle 10 s und schreibt zwei Log-Zeilen pro Poll auf jedes
+  Gerät. Die AP-Logs sind dadurch für Diagnose praktisch unbrauchbar (`get_log` ohne `topics`-Filter liefert
+  nur `admin logged in/out via api`).
+- **Abh.:** TP25 ✅ (die Funkparameter sind übernommen), TP15/TP21.1 ✅ (Core als L3-Router = Manager-Standort).
+  Verwandt: **TP3** (dessen CAPsMAN-Ära hier revidiert wird), **TP22** (GC-Scope).
+
 ### TP-R — Router-Capabilities-Sweep ▸ FERTIG (`docs/research/routeros-capabilities.md`)
 - **Leitsatz: nativ vor Container, NAS vor Router** (128MB-Flash-Limit).
 - **Sofort nativ (~0 RAM):** RoMON · Netwatch · Scheduler + Auto-Backup/Mail · SNMP→externes Monitoring · **mDNS-Repeater** · spectral-scan · **802.11r/k/v (Fast-Roaming statt Mesh)** *(die Sweep-Fassung nannte hier CAPsMAN — das ist seit 2026-08-08 abgeschafft; 11r/k/v läuft standalone weiter, s. TP3/TP3.3)* · Back-to-Home/WireGuard.