Sideboard-Test zurueckgebaut, und was dabei nicht verschwindet

TEST-ether3-trunk-ap1-sideboard ist zurueckgerollt und geschlossen: ether3
faellt aus allen tagged-Listen und ist in VLAN40 wieder untagged (Sideboard-
Access-Port). Am Geraet gegengeprueft, Snapshot-Diff leer. crs326-core ist
damit transaktionsfrei.

TP25 Fund (G): ap1 am Sideboard richtet das Wohnzimmer nicht und kostet das
Schlafzimmer (-61 -> -83 dBm). Die Idee "ap1 ersetzt den Sideboard-Switch" ist
damit entschieden -- nein, Platzierung vor eingespartem Geraet. ap2 haengt
jetzt auf 2,5 m, Terrasse subjektiv besser, Nachmessung steht aus.

Korrektur im selben Zug: die erste Fassung von (G) behauptete, der Steering-
Fall entfalle mit dem Rollback. Falsch -- es entfaellt nur die konkrete
Auspraegung. Fund B und C wurden am 08-20 mit ap1 auf ether15 gemessen, also
in genau der Stellung, in die wir zurueckgebaut haben; der Defekt ist
platzierungsunabhaengig und verlagert sich nur. Fund E bleibt die Massnahme
und ist jetzt oberster offener Punkt.

TP12.1 neu (unter TP12, kein Duplikat daneben): Matter/Thread-Commissioning
scheitert an fehlendem IPv6-Routing zwischen VLAN10 und VLAN20 -- nicht an der
Firewall. Der Kostenpunkt des TP ist aber nicht die Adressvergabe, sondern
dass /ipv6 firewall filter leer ist: heute harmlos, ab der ersten Adresse ein
Loch an TP5 vorbei. Reihenfolge deshalb zwingend v6-Firewall vor Adressen.

Runbook + Kommandodateien fuer die temporaere dirtyvader-infra-SSID
(cfg-infra existiert bereits, haengt nur in keiner provisioning-Zeile).
Vorbereitet, nicht deployt.

Repo-lokalen projektstatus-Skill geloescht: er war seit 11. Juli stale
(harte Themenblöcke, kritischer Pfad von TP14.3) und wurde nicht geladen --
aktiv ist der globale.

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

docs/matter-pairing-infra-ssid-runbook.md

@@ -0,0 +1,94 @@
+# Runbook — `dirtyvader-infra` temporär ausstrahlen (Matter/Thread-Pairing)
+
+**Zweck:** ein iPhone für die Dauer eines Matter-Commissionings auf **VLAN20** bringen, damit Telefon und
+OpenThread-Border-Router auf **demselben L2-Link** sitzen. Dann wirbt der OTBR dem Telefon On-Link-Prefix
+*und* Route in den Thread-OMR-Prefix per RA, iOS wertet beides aus — und die fehlende IPv6-Route zwischen
+VLAN10 und VLAN20 (**TP12.1**) wird gar nicht erst berührt.
+
+**Status:** 🟠 vorbereitet 2026-08-22, **nicht deployt** — s. Blocker.
+
+> **Erst prüfen, ob dieses Runbook überhaupt nötig ist.** Seit 2026-08-22 läuft der Matter-Server mit
+> `ble_proxy: true` (`BLE is enabled (proxy mode)`). Wenn HA eine **connectable** BLE-Quelle hat,
+> kommissioniert HA selbst und das Telefon wird nicht gebraucht. Shelly-BLE-Proxies sind
+> **Advertisement-Scanner ohne GATT** und reichen dafür vermutlich nicht; ein ESP32 als
+> ESPHome-BT-Proxy (`active: true`) reicht. **Dieses Runbook ist der Plan B.**
+
+---
+
+## 🔴 Blocker: eine offene Transaktion je Gerät
+
+Auf `crs326-core` ist **`TEST-ether3-trunk-ap1-sideboard`** offen (Scope `bridge-vlan`, Frist 2026-09-04,
+TP25-Standorttest). `gc-transaktion.py begin` verweigert deshalb eine zweite Akte auf demselben Gerät
+(Regel 3). Vor dem Deploy also **eines von beiden**:
+
+- die ether3-Akte `commit`en oder `rollback`en — sie gehört TP25, das ist Christophs Entscheidung; **oder**
+- bewusst ohne Transaktion deployen — dann ist es **undokumentierter Drift**, genau das, was
+  `docs/transaktionen/README.md` abschaffen wollte. Nicht empfohlen.
+
+## Vorbedingungen (alle live geprüft 2026-08-22 ✅)
+
+| | |
+|---|---|
+| `cfg-infra` existiert am Manager | ✅ SSID `dirtyvader-infra`, `datapath=dp-infra` mit **explizitem `vlan-id=20`** |
+| `sec-infra` hat einen PSK | ✅ 13 Zeichen gesetzt — **kein offenes Netz**. Passphrase steht am Core (`/interface/wifi/security`), nicht in diesem Repo |
+| `slaves-datapath` auf ap1 | ✅ `dp-caps-slaves` (`bridge=bridge`, **ohne** `vlan-id`) |
+| `cfg-infra` in einer `provisioning`-Zeile | ❌ **in keiner** — genau das ist der Change |
+
+⚠️ Die ersten drei sind zusammen die Falle, die am 2026-08-18 **14 Stunden** gekostet hat: fehlt
+`slaves-datapath`, assoziieren Clients auf Slave-VAPs sauber und bekommen **nie** DHCP. Hier ist sie
+entschärft — deshalb steht sie in der Tabelle und nicht im Kleingedruckten.
+
+## Deploy
+
+Scope für die Transaktion ist **`wifi-provisioning`** (keine `bridge-vlan`!).
+
+```bash
+python3 nautobot/gc-transaktion.py begin --device crs326-core \
+    --scope wifi-provisioning --change-id TEST-infra-ssid-matter-pairing \
+    --expires 2026-08-29 \
+    --reason "dirtyvader-infra temporaer auf ap1, iPhone fuer Matter-Commissioning auf VLAN20 (TP12.1)"
+```
+
+```bash
+python3 nautobot/gc-manual-plan.py --device crs326-core \
+    --commands-file docs/transaktionen/TEST-infra-ssid-matter-pairing.commands.rsc \
+    --change-id TEST-infra-ssid-matter-pairing --dry-run
+```
+
+Erst nach gelesenem Dry-Run dasselbe mit `--deploy` statt `--dry-run`.
+
+Ändert `cfg-infra` auf **ap1** (beide Bänder). ap2 bleibt bewusst außen vor: kleinerer Blast-Radius, und
+zum Anlernen steht man ohnehin an einem Ort. Reicht die Abdeckung nicht, dieselben zwei Zeilen für
+`ap2 5GHz` / `ap2 2.4GHz` ergänzen.
+
+Erscheint der VAP nicht, hat der CAP nicht re-provisioniert — dann am Manager
+`/interface/wifi/capsman/remote-cap/provision [find]` nachziehen.
+
+## Abnahme
+
+**Eine frische DHCP-Lease aus `dhcp-v20` vom iPhone.** *Nicht* die Registration-Table — die zeigte während
+des 14-Stunden-Ausfalls 25 zufriedene Clients, die kein DHCP hatten.
+
+```bash
+# am Core
+/ip dhcp-server lease print where server=dhcp-v20
+```
+
+## Rückbau — **nicht vergessen**
+
+Ein WLAN nach INFRA ist nichts, was stehen bleiben soll. Nach erfolgreichem Pairing:
+
+```bash
+python3 nautobot/gc-manual-plan.py --device crs326-core \
+    --commands-file docs/transaktionen/TEST-infra-ssid-matter-pairing.rollback.rsc \
+    --change-id TEST-infra-ssid-matter-pairing-rollback --deploy
+python3 nautobot/gc-transaktion.py rollback --change-id TEST-infra-ssid-matter-pairing
+```
+
+Danach `gc-transaktion.py status` — die Akte muss geschlossen und `wifi-provisioning` wieder driftfrei sein.
+
+## Siehe auch
+
+- **TP12.1** in [`teilprojekte.md`](teilprojekte.md) — warum es ohne VLAN20-SSID nicht geht, und was der
+  saubere Weg wäre (v6-Firewall zuerst, dann Adressen).
+- [`transaktionen/README.md`](transaktionen/README.md) — die drei Regeln des Transaktions-Werkzeugs.