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>

.claude/skills/projektstatus/SKILL.md

@@ -1,58 +0,0 @@
----
-name: projektstatus
-description: Rendert den BF-Netzwerk-Projektstatus als Baum (alle Teilprojekte mit Status + kritischem Pfad). Use when Christoph nach "Projektstatus", "Fortschritt", "Baum", "Stand", "Übersicht" der TPs fragt, oder einen aktuellen Statusbaum sehen will.
----
-
-# BF-Netzwerk Projektstatus (Baumform)
-
-Ziel: einen **aktuellen, kompakten Statusbaum aller Teilprojekte (TP)** ausgeben — gruppiert
-nach Themenblöcken, mit Status-Marker je TP und einer Zeile „kritischer Pfad" darunter.
-
-## Quelle (immer frisch lesen — NIE aus dem Gedächtnis)
-
-Kanonischer Stand = **`docs/teilprojekte.md`** (SSoT). Das ist die einzige Pflichtlektüre.
-Bei Detailfragen ergänzend: `MEMORY.md`-Index im Memory-Ordner + einzelne `project_*`-Memories.
-
-**Ablauf:**
-1. `docs/teilprojekte.md` komplett lesen (Datei ist groß → ggf. in 2 Reads: Zeilen 1–290, dann 291–Ende).
-2. Status je TP aus den `▸ …`-Headern und ✅/⏳/🔜/⏸️-Markern ableiten — **nicht** aus diesem Skill
-   oder aus alten Memories raten; die Datei überschreibt alles.
-3. Baum rendern (Format unten). Datum aus dem Kontext (`currentDate`) in die Überschrift.
-
-## Status-Marker (Legende)
-
-`✅` fertig · `⏳` WIP/teil-erledigt · `🔜` TODO/geplant · `⏸️` vertagt · `◄` Kern-Ziel
-
-## Themenblöcke (Gruppierung des Baums)
-
-Immer diese Reihenfolge — spiegelt Fundament → Ausbau → Ziel:
-
-1. **FUNDAMENT** — TP1, TP2, TP4
-2. **WLAN / CAPsMAN** — TP3, TP3.1, TP3.2, TP3.3 (+ Sonos-Migration unter TP3)
-3. **DISCOVERY (mDNS/SSDP)** — TP7, TP7.1, TP7.2
-4. **IP-MIGRATION VLAN1→VLAN20** — TP14 (+ 14.1–14.5) + Omada-PVID-Fix
-5. **SHELLY-MIGRATION** — TP17
-6. **CF-TUNNEL / EXTERNER ZUGANG** — TP16
-7. **FIREWALL / QoS** — TP5, TP5.1, TP6 (TP6 = Kern-Ziel ◄)
-8. **HARDWARE** — TP15
-9. **VPN** — TP10
-10. **RESEARCH-GATED / SPÄTER** — TP8, TP9, TP11, TP12, TP13, TP-R
-
-## Ausgabeformat
-
-- ASCII-Baum in einem ```-Codeblock (├── │ └── ─).
-- Je TP: `<marker> TP<n>  <Kurztitel>   (<Datum falls fertig>)`.
-- Wichtige Unterpunkte/Caveats als eingerückte `└─`-Zeile (max. 1–2 je TP, nur das Entscheidende).
-- Legende als letzte Zeile im Codeblock.
-- Nach dem Codeblock **eine** Zeile **„Kritischer Pfad gerade:"** mit der aktuellen Arbeitskette
-  (aktuell: Omada-PVID-Fix + TP14.3-Sweep → TP14.5-Gate → TP5 Deny-by-default → TP6 CAKE/QoS;
-  TP17 + TP3.3 laufen unabhängig daneben) — diese Kette aber ebenfalls aus `teilprojekte.md`
-  §„Reihenfolge / Abhängigkeiten" verifizieren, nicht hart übernehmen.
-
-## Ergänzungen vor/nach dem Baum
-
-Christoph ergänzt oft Kontext **vor oder nach** dem Baum (z.B. „…und pack die offenen
-Firewall-Punkte drüber" / „…mit Fokus auf TP17"). Solche Zusatzwünsche:
-- **vor** dem Baum → als kurzer Vorspann (z.B. Highlight/Frage beantworten), dann Baum.
-- **nach** dem Baum → als Nachtrag (Detailauszug, nächste Schritte, offene Entscheidungen).
-Der Baum selbst bleibt im obigen Format stabil; die Ergänzungen rahmen ihn.

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.

docs/teilprojekte.md

@@ -605,6 +605,57 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 ### TP12 — IPv6 (intern + extern, 3 Standorte) ▸ research-gated
 - Konzept für FM/BF/DW. → TP-R.
 
+#### TP12.1 — IPv6 im LAN (ULA) + v6-Firewall ▸ 🟠 **KONKRET GEWORDEN (2026-08-22), Treiber: Matter/Thread**
+> **Anlass:** der runde IKEA-Fühler **TIMMERFLOTTE** (Matter over Thread) ließ sich nicht anlernen —
+> „pairing failed" in der Companion-App. Ursache ist **nicht** die Firewall, sondern dass zwischen
+> VLAN10 und VLAN20 **überhaupt kein IPv6 geroutet wird**. Damit ist TP12 vom Konzept-TP zu einem
+> Punkt mit einem konkreten, wiederkehrenden Schaden geworden.
+
+- **Befund am `crs326-core` (live gelesen 2026-08-22):**
+  - IPv6-Adressen: **ausschließlich Link-Local** (`fe80::…`) auf jedem Interface. Keine ULA, keine GUA.
+  - IPv6-Routing-Tabelle: nur `::1/128` und `fe80::/64` je Interface. **Keine Route** auf den
+    Thread-OMR-Prefix `fd92:505a:c64e:1::/64` und keine auf `fd03:cace:953f:e13d::/64` (den On-Link-Prefix,
+    den der OTBR auf VLAN20 wirbt).
+  - `/ipv6 nd`: Default-Eintrag, `advertise-dns=no` — es gibt aber ohnehin keine Prefixe zu werben.
+- 🔴🔴 **Der eigentliche Kostenpunkt ist nicht IPv6, sondern die Firewall:** `/ipv6 firewall filter` ist
+  **komplett leer**. Heute harmlos, weil ohne Adressen nichts geroutet wird. In der Sekunde, in der
+  Adressen vergeben werden, steht **IOT→MAIN offen, GUEST→INFRA offen — an TP5 vorbei**. Das gesamte
+  TP5-Regelwerk muss **vorher** in v6 nachgebaut sein, sonst reißt dieser TP genau die Segmentierung
+  auf, die TP5 am 2026-08-18 geschlossen hat. **Das ist die Arbeit, nicht die Adressvergabe.**
+- 🔎 **Warum Matter das braucht:** Commissioning läuft in zwei Etappen. Etappe 1 (BLE zum Gerät) ist
+  netzunabhängig. In Etappe 2 muss der Commissioner — das iPhone — das Gerät auf dem **operativen
+  Thread-Netz** wiederfinden (DNS-SD `_matter._tcp`, dann CASE). Dafür braucht das Telefon eine
+  IPv6-Route in den OMR-Prefix hinein. iPhone hängt auf VLAN10, OTBR auf VLAN20 → Etappe 2 bricht ab.
+  Die ~30 bereits laufenden Matter-Knoten widersprechen dem nicht: HA und OTBR sitzen auf **demselben
+  Host** (`wpan0` ist lokal), im Betrieb quert nichts die VLAN-Grenze. Nur das *Anlernen* tut es.
+- ⚠️ **Zwei Fallen, die den naiven Weg verbauen:**
+  - **(a) Der OMR-Prefix ist generiert und wandert.** Am 2026-08-22 um 17:33 (OTBR-Neustart) sind alle
+    Knoten von `fd92:505a:c64e:1::/64` auf **Mesh-Local** `fd66:986:170:bb1a::/64` gefallen — und
+    Mesh-Local ist per Definition *nicht* off-mesh routbar. Eine statische Route auf den OMR-Prefix ist
+    also nur so stabil wie der nächste Neustart. Ihn im Thread-Dataset festzunageln formiert das Netz
+    neu — mit 30+ produktiven Knoten daran kein Nebenbei-Change.
+  - **(b) RouterOS lernt fremde RAs nicht.** Der OTBR wirbt den OMR-Prefix per RA mit Route-Information-Option
+    auf VLAN20. Der Core müsste die annehmen — als forwardender Router für dieses Interface tut er das
+    nicht sauber.
+- 📡 **Dritter Baustein: DNS-SD über die VLAN-Grenze.** `mdns-repeat-ifaces` am Core (vlan10/20/30/40/90)
+  ist **IPv4**. Für Matter-Discovery bräuchte es zusätzlich einen v6-fähigen Reflector — der
+  `mcast-relay`-LXC (108) kann das prinzipiell, aber als **zweite Instanz** mit Beinen in VLAN10+VLAN20
+  (SSDP-Instanz ist VLAN10+VLAN40, s. Gotcha in CLAUDE.md).
+- ✅ **Der Workaround, der das umgeht statt löst:** iPhone zum Anlernen auf **VLAN20** — dann sind Telefon
+  und Border Router auf demselben L2-Link, der OTBR wirbt dort On-Link-Prefix *und* Route, und iOS wertet
+  beides aus. `cfg-infra` / SSID `dirtyvader-infra` (`dp-infra`, VLAN20, `sec-infra` mit PSK) existiert am
+  Manager **bereits**, ist nur in **keiner** `provisioning`-Zeile als Slave hinterlegt. Runbook:
+  [`docs/matter-pairing-infra-ssid-runbook.md`](matter-pairing-infra-ssid-runbook.md).
+- ✅ **Der Weg, der das Problem dauerhaft erledigt:** Matter-Server-Option **`ble_proxy: true`** (ab HA
+  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**.
+- **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),
+  ist aber allein für BF ausführbar.
+
 ### TP13 — „Botschafts-WLANs" ▸ 🔜 **AUSFÜHRBAR (Runbook 2026-08-19)** — `docs/tp13-botschafts-wlan-runbook.md` · fun/low-prio
 > 📌 Am 2026-08-19 überarbeitet: der Technikteil beschrieb noch Standalone-APs (SSIDs entstehen seit
 > TP28 am **Manager**, also ein Deploy statt zwei), und der Entwurf „nur `ssid=`, kein Security" war ein
@@ -1259,6 +1310,32 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 > die erste Stelle im Haus, an der **Fund E (`signal-range`-Boden) wirklich hilft**, weil es hier eine
 > bessere Alternative gibt. **Test steht aus** (Handover §5). Korrektur zur Terrasse: der Platz, an dem
 > das Telefon normalerweise steht, ist mit **−46…−66 dBm gut**; schlecht ist der Teil dahinter.
+> **(G) 2026-08-22 — Sideboard-Test BEENDET, ap1 geht zurück auf `core ether15`.** Ergebnis nach einem
+> Tag, User-Befund: **ap1 am Sideboard richtet das Wohnzimmer nicht** — womit die RF-Vorhersage aus der
+> Idee von 2026-08-13 (geschlossenes Media-Möbel, Metallgehäuse, niedrig) bestätigt ist — **und der
+> Preis ist ein dunkles Schlafzimmer** (Fund F: −61 → −83 dBm). Damit ist die Idee **„ap1 ersetzt den
+> Sideboard-Switch" entschieden: nein.** Die User-Vorgabe „Platzierung hat Vorrang vor dem eingesparten
+> Gerät" greift — und die bessere Platzierung ist die alte. Transaktion
+> `TEST-ether3-trunk-ap1-sideboard` wird zurückgerollt (`ether3` wieder **untagged VLAN40** =
+> Sideboard-Access-Port); Compliance geht damit auf 92/92 zurück.
+> 🔴 **Reihenfolge beim Rückbau:** erst ap1 physisch auf `ether15` umstecken, **dann** die Config
+> zurückrollen. Umgekehrt hängt ap1 im Moment des Deploys ungetaggt in MEDIA und verliert vlan99/Manager.
+> `ether15` ist durchgehend in allen VLANs getaggt geblieben, das Umstecken allein genügt also.
+> ↗️ **Stattdessen als Nächstes:** ap2 wurde auf **2,5 m Höhe** gehievt (User 2026-08-22) — der billigste
+> verbliebene Hebel unter der Randbedingung „kein neuer AP, solange nicht alles aus den vorhandenen
+> rausgeholt ist". Wirkung **noch ungemessen**: Raumkarte mit [`tp25-walk-messung.sh`](tp25-walk-messung.sh)
+> neu laufen, sonst steht Höhengewinn gegen Fund F ohne Zahlen im Raum. **Erster Eindruck des Users
+> (2026-08-22): die Terrasse ist damit besser ausgeleuchtet** — subjektiv, Nachmessung steht aus und
+> ist genau der Punkt, an dem der Dead Spot aus (E)/(F) zu prüfen wäre.
+> ⚠️ **Korrektur 2026-08-22 (User):** die Formulierung „der Steering-Fall entfällt mit dem Rollback" war
+> **falsch**. Was entfällt, ist nur die *konkrete Ausprägung* aus (F) — Schlaf-/Kinderzimmer bei 2 m zu
+> ap1 an ap2 klebend. **Der Defekt selbst bleibt**, er verlagert sich nur: Übergabe bzw. Abriss passieren
+> dann an anderen Stellen im Haus. Das ist auch belegt: **Fund B** (Sticky Client, dreimal an ap1 bei
+> −43 dBm vorbei, eine einzige Übergabe) und **Fund C** (Band-Ping-Pong, 12 Wechsel in 9 min) wurden am
+> **2026-08-20 gemessen — mit ap1 auf `ether15`**, also in genau der Stellung, in die wir jetzt
+> zurückgebaut haben. Der Sticky-Client-Defekt ist damit **platzierungsunabhängig**.
+> ⇒ **Fund E** (`signal-range`-Boden am Manager) bleibt unverändert die richtige Maßnahme und ist nach
+> dem Rückbau der **oberste offene Punkt** in TP25 — nicht erledigt, nicht gegenstandslos.
 > 📋 **Übergabe: [`handoff-tp25-session-20260821.md`](handoff-tp25-session-20260821.md).**
 > ⚠️ **Auf `crs326-core` ist eine Config-Transaktion OFFEN** (`TEST-ether3-trunk-ap1-sideboard`, Scope
 > `bridge-vlan`, Frist 2026-09-04) — die Compliance ist deshalb **absichtlich** nicht 92/92.

docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.json

@@ -8,7 +8,8 @@
   "reason": "ap1 testweise am Sideboard, Uplink auf core ether3 statt ether15 (TP25 Standorttest)",
   "started": "2026-08-21",
   "expires": "2026-09-04",
-  "state": "open",
+  "state": "rolledback",
   "snapshot": "docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.snapshot.rsc",
-  "device_backup": "vor-ether3-trunk-20260821.backup"
+  "device_backup": "vor-ether3-trunk-20260821.backup",
+  "closed": "2026-08-22"
 }

docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.rollback-deployed.rsc

@@ -0,0 +1,15 @@
+# TATSAECHLICH DEPLOYT am 2026-08-22 (Plan 55ff3f32-3bc6-4c16-9ddb-613e335474df, Status Completed,
+# am Geraet gegengeprueft). Beleg fuer den Rueckbau von TEST-ether3-trunk-ap1-sideboard.
+# Abgeleitet aus dem Snapshot vom 2026-08-21, aber angepasst:
+#   - `add` -> `set [find ... and !dynamic]` (der Generator-Vorschlag haette neu angelegt)
+#   - Backslash-Fortsetzungen aufgeloest (Netmiko bricht daran)
+#   - VLAN 1 und 100 ausgelassen: ether3 kommt dort nicht vor
+# Hinweis: `gc-transaktion.py rollback` ueberschreibt die .rollback.rsc bei jedem Aufruf neu —
+# deshalb liegt der Beleg hier unter eigenem Namen.
+/interface bridge vlan set [find where vlan-ids=10 and !dynamic] tagged=ether1,ether8,ether13,ether15
+/interface bridge vlan set [find where vlan-ids=20 and !dynamic] tagged=ether8,ether13,ether15
+/interface bridge vlan set [find where vlan-ids=30 and !dynamic] tagged=ether1,ether8,ether15
+/interface bridge vlan set [find where vlan-ids=40 and !dynamic] tagged=ether1,ether8,ether13,ether15 untagged=ether2,ether3,ether4,ether5
+/interface bridge vlan set [find where vlan-ids=50 and !dynamic] tagged=ether1,ether8,ether15
+/interface bridge vlan set [find where vlan-ids=90 and !dynamic] tagged=ether1,ether8,ether15
+/interface bridge vlan set [find where vlan-ids=99 and !dynamic] tagged=ether8,ether15,bridge

docs/transaktionen/TEST-ether3-trunk-ap1-sideboard.rollback.rsc

@@ -0,0 +1,16 @@
+# Rueckbau-VORSCHLAG fuer TEST-ether3-trunk-ap1-sideboard (crs326-core, Scope bridge-vlan)
+# Aus dem Snapshot vom 2026-08-21. NICHT ungeprueft deployen:
+# `add`-Zeilen legen neu an, statt zu aendern — was hier gebraucht wird,
+# ist in der Regel ein `set [find ...]`. Zeilen entsprechend anpassen.
+
+/interface bridge vlan
+add bridge=bridge untagged=ether1,ether2 vlan-ids=1
+add bridge=bridge tagged=ether1,ether8,ether13,ether15 vlan-ids=10
+add bridge=bridge tagged=ether8,ether13,ether15 vlan-ids=20
+add bridge=bridge tagged=ether1,ether8,ether15 untagged=ether14 vlan-ids=30
+add bridge=bridge tagged=ether1,ether8,ether13,ether15 untagged=\
+ether2,ether3,ether4,ether5 vlan-ids=40
+add bridge=bridge tagged=ether1,ether8,ether15 vlan-ids=50
+add bridge=bridge tagged=ether1,ether8,ether15 vlan-ids=90
+add bridge=bridge tagged=ether8,ether15,bridge vlan-ids=99
+add bridge=bridge tagged=ether1 untagged=ether16 vlan-ids=100

docs/transaktionen/TEST-infra-ssid-matter-pairing.commands.rsc

@@ -0,0 +1,2 @@
+/interface wifi provisioning set [find where comment="ap1 5GHz"] slave-configurations=cfg-media,cfg-untrusted,cfg-guest,cfg-infra
+/interface wifi provisioning set [find where comment="ap1 2.4GHz"] slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest,cfg-infra

docs/transaktionen/TEST-infra-ssid-matter-pairing.rollback.rsc

@@ -0,0 +1,2 @@
+/interface wifi provisioning set [find where comment="ap1 5GHz"] slave-configurations=cfg-media,cfg-untrusted,cfg-guest
+/interface wifi provisioning set [find where comment="ap1 2.4GHz"] slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest