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.