Kein ESP32: die -infra-SSID ist damit der Standardweg

User-Entscheid 2026-08-22: es wird kein ESP32 als ESPHome-BT-Proxy
angeschafft. ble_proxy bleibt an, ist aber wirkungslos -- HA hat keine
connectable BLE-Quelle (Shellys: slots=0 auf allen dreien, gemessen) und
bekommt keine. Konsequenz, die beim naechsten Thread-Geraet zaehlt: der Weg
ist wieder die temporaere -infra-SSID. Runbook entsprechend von "Plan B" auf
Standardweg umgeschrieben, Blocker-Abschnitt als erledigt markiert (aber mit
dem Hinweis, dass Regel 3 jederzeit wieder greifen kann).

Neuer Nebenbefund unter TP12.1, bewusst als thread-, nicht ipv6-Thema
markiert: die Knoten @1:a (Diele OG/Treppenauge), @1:f und @1:10 flappen seit
Stunden (Resolving address is unreachable -> offline grace period expired),
waehrend die uebrigen ~20 stabil sind -- also kein Fabric-Problem. Vor jeder
Diagnose die Sonderlage von heute abziehen: OTBR-Neustart um 17:33 und ap1
zwischenzeitlich vom Netz. Erst pruefen, ob es danach noch besteht.

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

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

@@ -5,25 +5,28 @@ OpenThread-Border-Router auf **demselben L2-Link** sitzen. Dann wirbt der OTBR d
 *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.
+**Status:** ✅ **einmal durchgespielt am 2026-08-22** (TIMMERFLOTTE angelernt, danach zurückgebaut).
+Dies ist ab jetzt **der Standardweg** für jedes neue Thread-Gerät, nicht der Plan B.
 
-> **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.**
+> **Warum es keinen bequemeren Weg gibt.** Der Matter-Server läuft seit 2026-08-22 mit
+> `ble_proxy: true` (`BLE is enabled (proxy mode)`, Handshake steht). Damit könnte **HA selbst**
+> kommissionieren und das Telefon wäre raus — es fehlt nur eine **connectable** BLE-Quelle.
+> Die Shellys sind es nicht: gemessen `slots: 0, free: 0` auf allen dreien, also reine
+> Advertisement-Scanner ohne GATT. Ein ESP32 als ESPHome-BT-Proxy wäre die Lösung, ist aber per
+> **User-Entscheid 2026-08-22 abgelehnt**. Bleibt dieses Runbook — oder TP12.1 wirklich bauen.
+
+> ✅ **Was seit dem ersten Durchlauf leichter ist:** `cfg-infra`, `dp-infra` und `sec-infra` bleiben
+> auf User-Wunsch dauerhaft am Manager stehen (inaktiv, in keiner `provisioning`-Zeile). Der Change
+> ist deshalb wirklich nur noch das Hinzufügen von `cfg-infra` zu zwei Slave-Listen.
 
 ---
 
-## 🔴 Blocker: eine offene Transaktion je Gerät
+## ~~🔴 Blocker: eine offene Transaktion je Gerät~~ — erledigt 2026-08-22
 
-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.
+Die ether3-Akte wurde am 2026-08-22 zurückgerollt, `crs326-core` ist transaktionsfrei — der Blocker
+besteht nicht mehr. **Er kann jederzeit wiederkommen:** Regel 3 erlaubt genau *eine* offene Akte je
+Gerät. Steht beim nächsten Mal etwas anderes auf `crs326-core` offen, muss das erst geschlossen werden.
+`gc-transaktion.py status` sagt es in einer Zeile.
 
 ## Vorbedingungen (alle live geprüft 2026-08-22 ✅)
 

docs/teilprojekte.md

@@ -658,7 +658,26 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   2026.06, hier 2026.8.3). Dann kommissioniert **HA selbst** über seinen Bluetooth-Stack; das Telefon ist
   raus und die VLAN-Grenze wird nie berührt. Braucht eine **connectable** BLE-Quelle — Shelly-Proxies sind
   reine Advertisement-Scanner (kein GATT), ein **ESP32 als ESPHome-BT-Proxy** (`active: true`) reicht.
-  Der **ESPHome Device Builder ist bereits installiert**. Damit wird TP12.1 für Matter **optional**.
+  Der **ESPHome Device Builder ist bereits installiert**. Damit wäre TP12.1 für Matter **optional**.
+  🔴 **User-Entscheid 2026-08-22: ESP32 wird NICHT angeschafft.** Damit bleibt `ble_proxy` zwar an
+  (schadet nicht, kostet nichts), ist aber **wirkungslos** — HA hat keine connectable BLE-Quelle und
+  wird auch keine bekommen. **Konsequenz, die man beim nächsten Thread-Gerät kennen muss:** der Weg ist
+  dann wieder die temporäre `-infra`-SSID nach dem Runbook. Die ist inzwischen ein Zweizeiler, weil
+  `cfg-infra`/`dp-infra`/`sec-infra` am Manager stehen bleiben — aber sie ist jedes Mal ein
+  Config-Change am Core plus eine Transaktion. Wer das dauerhaft loswerden will, muss **TP12.1 bauen**
+  (v6-Firewall zuerst); ein dritter Weg ist damit nicht mehr vorgesehen.
+
+- 🔎 **Nebenbefund 2026-08-22, gehört zur Thread-Gesundheit, NICHT zu IPv6:** drei Matter-Knoten
+  flappen dauerhaft — **`@1:a` („Diele OG/Treppenauge")**, **`@1:f`** und **`@1:10`**. Muster im
+  Matter-Server-Log: `IpServiceStatus … Resolving (address is unreachable)`, dann
+  `offline grace period expired, marking unavailable`, im Abstand von 15–30 Minuten, über Stunden.
+  Die übrigen ~20 Knoten sind stabil, es ist also **kein** Border-Router- oder Fabric-Problem.
+  ⚠️ **Vor einer Diagnose die Sonderlage von heute abziehen:** der OTBR ist am 2026-08-22 um 17:33
+  neu gestartet (Knoten fielen kurzzeitig von OMR `fd92:…` auf Mesh-Local `fd66:…` zurück), und ap1
+  war zwischenzeitlich vom Netz. Erst nachsehen, ob das Flappen **danach** noch besteht — sonst
+  diagnostiziert man das Nachbeben eines Umbaus. Erste Verdachtsrichtungen, wenn es bleibt:
+  Thread-Routing/Parent-Wechsel dieser drei Knoten, schwache Funkstrecke zum nächsten Router-Knoten,
+  oder eine ICD-/Sleepy-End-Device-Eigenheit dieser Geräteklasse.
 - **Abh.:** hängt an nichts. **Blockiert nichts** — außer künftige Thread-Geräte, solange weder
   `ble_proxy` noch die `-infra`-SSID steht. Reihenfolge innerhalb des TP ist zwingend:
   **v6-Firewall nachbauen → dann erst Adressen vergeben.** Gehört unter TP12 (Gesamtkonzept 3 Standorte),