TP13: Technikteil war seit TP28 falsch, plus ein Denkfehler

Zwei Sachen standen in TP13, die so nicht stimmen.

Erstens beschrieb der Technikteil noch Standalone-APs und wollte die
Beacon-SSIDs in ap{1,2}-prov-base.rsc ergaenzen. Seit dem CAPsMAN-Cutover
entstehen SSIDs am Manager auf dem Core -- was fuer TP13 sogar einfacher
ist, ein Deploy statt zwei.

Zweitens der eigentliche Fund: der Entwurf wollte "nur ssid=, kein
Security" und begruendete das damit, dass Namens-SSIDs ohne offenen Zugang
rechtlich unkritisch seien. Eine SSID ohne Security IST aber ein offenes
WLAN, also genau der Fall, den der Rechtsvorbehalt ausschliessen will.
Richtig ist ein PSK, den niemand kennt: beacont den Namen, niemand kommt
rein. Kostet nichts.

Dazu die Datapath-Falle: ein Slave-VAP ohne explizite vlan-id am Manager
landet ungetaggt in der Bridge, weil der CAP vom Manager-Datapath nur die
vlan-id uebernimmt. Gleiche Mechanik wie der 14-h-Ausfall. Die
Botschafts-SSID braucht deshalb beides -- PSK und toten Datapath.

VAP-Budget am Geraet nachgesehen statt geschaetzt: max-interfaces=16 je
Radio, belegt sind 4 bzw. 5. Die Zahl ist also nicht die Grenze, Airtime
ist es -- jeder VAP beacont eigenstaendig. Empfehlung steht im Runbook.

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

docs/teilprojekte.md

@@ -529,10 +529,15 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 
 ### TP13 — „Botschafts-WLANs" ▸ 🔜 VORBEREITET (2026-08-08), fun/low-prio
 - **Idee:** eine/mehrere **Broadcast-only-SSIDs als „schwarzes Brett"** an die Funk-Nachbarschaft — der SSID-Name *ist* die Botschaft (z.B. `Kanal-11-bitte-freihalten`, `WLAN-Tuning-siehe-Portal`). Optional ein **offenes WLAN mit Captive-Portal** auf eine **statische Info-HTML** (Kanalabsprache, Auto-Kanalwechsel-Bitte). Leitgedanke: wer die SSID sieht, kann auch stören → die Infoseite erreicht genau die Zielgruppe.
-- **Technik (jetzt einfach, da WLAN standalone seit TP3-Rebuild):** reine Namens-SSIDs = zusätzliche `/interface/wifi` Slave-VAPs auf wifi1/wifi2 mit eigener `configuration` (nur `ssid=`, kein Security/Datapath) bzw. in ein isoliertes Dummy-VLAN → reine Beacon-SSID (kein DHCP/Uplink). Captive-Portal-Variante: RouterOS-**Hotspot** auf eigenem isoliertem VLAN (Guest-Ableger) mit `walled-garden` auf die lokale Info-Seite (HTML als hotspot-Ordner am Gerät oder via NAS-nginx).
-- **Umsetzungs-Skizze:** (1) SSID-Namen + Info-Text final; (2) Beacon-SSIDs in `routeros/.secrets/ap{1,2}-prov-base.rsc` ergänzen (identisch auf beiden APs, via Nautobot-GC generierbar); (3) optional Hotspot-VLAN + walled-garden + Info-HTML; (4) beide APs deployen.
+- ~~**Technik (jetzt einfach, da WLAN standalone seit TP3-Rebuild):** reine Namens-SSIDs = zusätzliche `/interface/wifi` Slave-VAPs auf wifi1/wifi2 mit eigener `configuration` (**nur `ssid=`, kein Security/Datapath**)~~ ⚠️ **Überholt 2026-08-19, in zwei Punkten:**
+  - **(a) WLAN ist seit TP28 nicht mehr standalone.** SSIDs entstehen am **Manager `crs326-core`** (9 `configuration`-, 6 `datapath`-Objekte, 4 `provisioning`-Zeilen — live gelesen 08-19). Das ist für TP13 sogar einfacher: **ein** Deploy statt zwei.
+  - **(b) 🔴 „kein Security" *ist* ein offenes WLAN** — genau das, was der Rechtsvorbehalt unten ausschließen will. Richtig ist eine SSID **mit** WPA2/WPA3-PSK, den niemand kennt: sie beacont den Namen, ist aber nicht beitretbar.
+  - Captive-Portal-Variante (RouterOS-**Hotspot**, isoliertes VLAN, `walled-garden`) bleibt als Option bestehen — s. Rechts-Gate unten.
+- ~~**Umsetzungs-Skizze:** … Beacon-SSIDs in `routeros/.secrets/ap{1,2}-prov-base.rsc` ergänzen …~~ → diese Dateien sind für den WLAN-Teil **Historie** (die CAPs sind auf die `cap`-Zeile eingedampft). **Aktuelle Umsetzung: `docs/tp13-botschafts-wlan-runbook.md`** (2026-08-19).
+  - 🔴🔴 **Die Falle, die dort ausführlich steht:** ein Slave-VAP **ohne explizite `vlan-id` am Manager** landet ungetaggt in `bridge` — weil der CAP vom Manager-Datapath **nur die `vlan-id`** übernimmt. Das ist dasselbe Leck wie TP3.1 (`cfg-main-2g` ohne datapath) und dieselbe Mechanik wie der 14-h-Ausfall vom 08-18. Die Botschafts-SSID braucht deshalb einen Datapath mit **totem** `vlan-id` — PSK **und** toter Datapath, nicht eines von beidem.
+  - ✅ **VAP-Budget geprüft (live 08-19), unkritisch:** `max-interfaces=16` je Radio, belegt sind 4 (5 GHz) bzw. 5 (2,4 GHz). **Die Grenze ist Airtime, nicht die Zahl** — jeder VAP beacont eigenständig. Empfehlung: **genau eine SSID, auf 2,4 GHz** (mehr Reichweite = mehr Nachbarn, und 5 GHz bleibt für Nutzverkehr frei).
 - ⚠️ **Recht vor Scharfschalten prüfen (User privat, AT):** offenes WLAN + Portal berührt Impressumspflicht/Störerhaftung — **reine Namens-SSIDs ohne offenen Zugang sind unkritisch** (kein Fremd-Datenverkehr); im Zweifel nur die Beacon-Variante.
-- **Abh.:** TP3-Rebuild ✅ (Standalone-APs — SSID-Änderung = 1 Deploy/GC-Job); ideal nach TP21/TP22 (dann via Golden Config statt Direkt-Edit).
+- **Abh.:** ~~TP3-Rebuild ✅ (Standalone-APs — SSID-Änderung = 1 Deploy/GC-Job)~~ → **TP28 ✅** (CAPsMAN auf dem Core) + **TP22 ✅** (GC-Deploy-Pipeline). SSID-Änderung = **ein** Deploy auf den Core; Direkt-Edit am Gerät ist durch den Governance-Entscheid ausgeschlossen.
 
 ### TP14 — Host/Container-IP-Migration VLAN1→VLAN20 (Docker-Cutover NAS+pve) ▸ ✅ DURCH (2026-07-13; live re-verifiziert 2026-08-08) — `docs/nas-vlan20/RUNBOOK.md`, Handoff `docs/nas-vlan20/handoff/`
 - ✅ **ABGESCHLOSSEN — Migration komplett** (Live-Check 2026-08-08 vom core: NAS `.20.10`, pve `.20.100`, Docker-LXC `.20.126`, platform-pg `.20.20`, Nautobot `.20.30` alle 0% Loss). Alle Hosts + Container auf VLAN20. **TP14.4** (CF-Access-Token-Rotation) = kleiner, nicht-blockierender Standalone-Follow-up (CF/TP11-Umfeld); **TP14.5** war nie ein eigener Change (nur ein Reihenfolge-Gate) → erfüllt, TP5 damit entblockt.