Doku-Drift beheben: Ist-Stand-Block, TP26/TP27, Fasttrack-Befund, Uebergabe

Eine parallele Session hat drei Befunde gemeldet, alle drei richtig. Sie sind
hier abgearbeitet.

1) Der "Ist-Stand (Kurz)"-Block war an vier Stellen ueberholt: Standalone-APs
   statt CAPsMAN, RouterOS 7.19.5/7.23 statt 7.24, "plain 1.1.1.1" statt DoH,
   68/68 statt 92/92. In der Nacht wurden die TP-Abschnitte und CLAUDE.md
   nachgezogen, aber ausgerechnet der Block, den eine frische Session zuerst
   liest, blieb stehen.

2) TP26 und TP27 existierten nur als Commits und .rsc-Dateien, ohne Abschnitt.
   Beide nachgetragen. TP27 (RouterBOOT 7.24) ist auf allen vier Geraeten
   abgeschlossen -- current-firmware = upgrade-firmware = 7.24, geprueft.

3) Fasttrack ist auf dem Core tot: 32,9 Mio Pakete auf der accept-Regel davor,
   0 auf Fasttrack, 0 von 445 Verbindungen fasttracked. Herkunft ist der
   Core-Cutover (ap1 hatte die Reihenfolge richtig). Und das Re-Baseline vom
   18. hat den Fehler als Absicht in die SoT geschrieben -- die Kehrseite von
   ingest-core-firewall.py, jetzt als Warnung in TP21.

Dazu: die TP6-Praemisse wackelt. call-quality-diagnosis.md misst A/A+ und
haelt CAKE fuer marginal; TP6 wird trotzdem als "DAS Ziel" gefuehrt. Naechster
Schritt ist deshalb eine Messung gegen den heutigen Edge, nicht eine Queue.

Uebergabe fuer die Doku-Session: docs/handoff-doku-session-20260818.md

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

docs/teilprojekte.md

@@ -21,28 +21,38 @@ Mgmt (VLAN99, Ist 2026-08-16): core `.99.1` · branch `.99.2` · ap1 `.99.11` ·
 
 ## Ist-Stand (Kurz)
 
-**Stand 2026-08-16 — live gegen die Geräte geprüft (MikroMCP), nicht aus der Doku abgeschrieben.**
+**Stand 2026-08-18 — live gegen die Geräte geprüft (MikroMCP/REST), nicht aus der Doku abgeschrieben.**
+*(Die Fassung vom 2026-08-16 stand bis zum 18. hier und war an vier Stellen überholt — Standalone-APs,
+RouterOS-Versionen, „plain 1.1.1.1", 68/68. Wer diesen Block liest, liest ihn als Erstes: er wird
+ab jetzt bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
 
-- **L3 + WAN-Edge = `crs326-core`** (CRS326-24G-2S+, RouterOS 7.19.5, Technik UG): Routing, DHCP (7 Server,
-  54 Reservierungen), DNS, NAT und der WG-Hub (TP10, Peers `fm`/`dw`) laufen hier. Mgmt-SVI **`10.40.99.1`**
-  (vlan99), Gateway `.1` je VLAN (vlan10/20/30/40/50/90/99 alle `running`). **WAN = `vlan100`** — DHCP-Client
+- **Alle vier MikroTik laufen auf RouterOS 7.24** (stable, 2026-08-17 von Christoph selbst gehoben, TP27),
+  **RouterBOOT ebenfalls 7.24** auf allen vieren (`current-firmware` = `upgrade-firmware`, geprüft 08-18).
+- **L3 + WAN-Edge = `crs326-core`** (CRS326-24G-2S+, Technik UG): Routing, DHCP (7 Server,
+  54 Reservierungen), DNS, NAT, **NTP-Server für den Standort** und der WG-Hub (TP10, Peers `fm`/`dw`)
+  laufen hier. Mgmt-SVI **`10.40.99.1`** (vlan99), Gateway `.1` je VLAN. **WAN = `vlan100`** — DHCP-Client
   hält die öffentliche Liwest-IP **`90.146.33.177/24`** direkt vom Arris (Bridge-Mode) → kein Double-NAT.
-  DNS-Upstream aktuell **plain `1.1.1.1`** (DoH-Gateway offen: TP21.1 TODO 1 = TP23 Stufe 1).
-- **L2-Branch = `crs326-branch`** (Technik OG, RouterOS 7.19.5): reiner L2-Switch, Mgmt **`10.40.99.2`**,
-  Uplink `ether1` → core `ether8`. ✅ **Bring-up-Reste entfernt (2026-08-16):** SVI `vlan10` + `10.40.10.2`
-  („TEMP Bring-up VLAN10") sind weg — Mgmt läuft ausschließlich über `vlan99`.
-- **WLAN = 2× hAP ax² als reine Standalone-APs** (RouterOS 7.23, **kein CAPsMAN**): ap1 **`10.40.99.11`**
-  (an core `ether15`), ap2 **`10.40.99.12`** (an branch `ether24`), Uplink je `ether1` (PoE-Port). 6 SSIDs
-  `dirtyvader-*`, jede mit eigenem `datapath` → kein ungetaggter VLAN1-Egress mehr. 802.11r/k/v aktiv
-  (`st-main`, seit TP3.3 fester Bestandteil des GC-Templates).
+  **DNS-Upstream = DoH zum CF-Gateway mit `verify-doh-cert=yes`** (TP23 Stufe 1 ✅ 08-18);
+  `servers=1.1.1.1` steht nur noch als Bootstrap für den DoH-Hostnamen.
+- 🔥 **Die Firewall ist deny-by-default — in BEIDEN Ketten** (TP5 E3/E4 ✅ 08-18). `TP10-seal-lan` ist
+  `disabled`; Mgmt-Input kommt nur noch aus VLAN10, von HA (`8728`), von Nautobot (`22`) und über
+  `cf-mesh`. Ein neuer Dienst über eine VLAN-Grenze braucht ab jetzt eine explizite Regel.
+- **L2-Branch = `crs326-branch`** (Technik OG): reiner L2-Switch, Mgmt **`10.40.99.2`**,
+  Uplink `ether1` → core `ether8`.
+- **WLAN = CAPsMAN auf dem Core** (TP28 ✅ 08-17, GC-Modell nachgezogen 08-18): ap1 **`10.40.99.11`**
+  (an core `ether15`), ap2 **`10.40.99.12`** (an branch `ether24`), beide **reine CAPs** —
+  `cap enabled=yes`, `discovery-interfaces=vlan99`. Die APs halten **keine eigene WLAN-Config** mehr;
+  Kanäle, SSIDs, Security und Steering kommen vom Manager. 802.11r/k/v aktiv, `ft-over-ds=yes`.
+- **SSDP-Relay** (TP7.1 ✅ 08-18): LXC **108 `mcast-relay`** auf pve, zweibeinig `10.40.10.21` (VLAN10) +
+  `10.40.40.21` (VLAN40) — dafür trägt `core ether13` beide VLANs. Die macOS-Sonos-App findet damit ihr
+  System; mDNS macht weiterhin der Core.
 - **Ausgebaut / gelöscht:** ALLNET-`sw1` und Omada-`sw2` sind **physisch weg** (2026-08-08 bzw. 2026-07-23,
   in Nautobot *Decommissioned*); Omada-Controller + `omada-mcp` gelöscht (2026-07-16); FritzBox 6660 raus
-  seit 2026-07-01 (Liwest-Tausch auf Arris). `cudy1` hängt noch an core `ether11`, hat aber **seit
-  2026-08-08 19:33 keinen Link** (live bestätigt) und steht in Nautobot auf *Offline*; `cudy2` tot.
-  → **Kein aktiver VLAN1-Leak mehr**, der formale Teardown bleibt TP19.
-- **Kontrolle / Governance:** MikroMCP für Reads/Debug (alle 4 Geräte in der Registry: `crs326-core`,
-  `crs326-branch`, `ap1`, `ap2`), **Config-Änderungen ausschließlich über Nautobot Golden Config**
-  (TP21/TP22 — Deploy-Pipeline scharf, **68/68 Compliance-Checks grün, 0 Drifts** seit 2026-08-16).
+  seit 2026-07-01 (Liwest-Tausch auf Arris). **VLAN1 ist leer** (`/ip arp` auf `bridge` = 0 Einträge,
+  08-18) — TP19 ist geschlossen; `cudy1` hängt stromlos an core `ether11`, physischer Ausbau ist hands-on.
+- **Kontrolle / Governance:** MikroMCP für Reads/Debug (alle 4 Geräte in der Registry),
+  **Config-Änderungen ausschließlich über Nautobot Golden Config** (TP21/TP22 — Deploy-Pipeline scharf,
+  **92/92 Compliance-Checks grün, 0 Drifts** bei **23 Rules**, Stand 2026-08-18).
 
 <details><summary>📜 Historische Fassung (Stand bis 2026-08-08, Topologie <b>vor</b> dem Core-Cutover — bewusst erhalten, nicht als Ist lesen)</summary>
 
@@ -54,7 +64,11 @@ Mgmt (VLAN99, Ist 2026-08-16): core `.99.1` · branch `.99.2` · ap1 `.99.11` ·
 
 </details>
 
-**Nächster Schritt (Stand 2026-08-18): TP6 — CAKE. Das ist das Projektziel, und es hat keine Blocker mehr.** TP5 ist in der Nacht auf den 18. abgeschlossen worden (Etappe 3 + 4: deny-by-default in `forward` **und** `input`, MGMT isoliert, `seal-lan` abgeschaltet), TP23 Stufe 1 (DoH auf dem Core) ebenfalls. Nebenher offen, blockiert nichts: **TP25** (Signal-Boden + Re-Walk), **TP28-Rest** (die fünf `wifi-*`-Features vom AP-Scope auf den Core umhängen — die einzigen verbliebenen Compliance-Drifts), **TP7.1** (SSDP-Relay für die macOS-Sonos-App), **TP16.3**, **TP24**.
+**Nächster Schritt (Stand 2026-08-18): die TP6-Prämisse messen, nicht CAKE bauen.**
+TP6 wird hier seit Monaten als „DAS Ziel" geführt, aber `docs/call-quality-diagnosis.md` hat den
+Bufferbloat 2026-06-16 bereits gemessen (**A/A+**, „CAKE wäre marginal, nicht deployt"). Die Messung
+stammt aus der FritzBox-Ära, der Edge ist seither getauscht — also **einmal gegen den heutigen Edge
+nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Nacht auf den 18. abgeschlossen worden (Etappe 3 + 4: deny-by-default in `forward` **und** `input`, MGMT isoliert, `seal-lan` abgeschaltet), TP23 Stufe 1 (DoH auf dem Core) ebenfalls. Nebenher offen, blockiert nichts: **TP25** (Signal-Boden + Re-Walk), **TP28-Rest** (die fünf `wifi-*`-Features vom AP-Scope auf den Core umhängen — die einzigen verbliebenen Compliance-Drifts), **TP7.1** (SSDP-Relay für die macOS-Sonos-App), **TP16.3**, **TP24**.
 > *Vorherige Fassung (Stand 2026-08-14, überholt): „TP5 — Deny-by-default am Ende von `forward`." Alles Davorliegende ist durch:* CRS326-Bring-up + L3-Umzug ap1→`crs326-core` (TP15/TP21.1 ✅ 2026-08-08), WLAN-Neuprovisionierung ohne CAPsMAN (TP3 ✅ 2026-08-08), Nautobot-Plattform + Fleet-Adoption + Deploy-Pipeline (TP21/TP22 ✅ 2026-08-13). Danach **TP6 (CAKE) = das Projektziel**. Kleine Follow-ups nebenher: DoH-Cloudflare auf core, DC-USV (**TP24**, seit 2026-08-16 eigener TP). ⚪ **Omada-PVID-Fix ist obsolet** (User-Entscheid 2026-07-22 — Omada spielt seit der TP15-Korrektur keine Rolle mehr im Netz, nie mehr aufgreifen).
 > *Vorherige Fassung (Stand 2026-07-22, erledigt): „TP15 CRS326-Bring-up als neuer L3-Core, danach WLAN-Neuprovisionierung ohne CAPsMAN; TP5 folgt nach TP21/CRS326-Adoption."*
 > 🎯 **Ziel: sauberes System „from scratch", keine Leichen/Altlasten.** Migrations-Session-Endstand = **VLAN1 + altes cudy-WLAN komplett weg** (VLAN1 nur noch Mgmt, `defconf`-Client-DHCP zurückgezogen, cudy-Uplinks aufs Ziel-Client-VLAN getaggt oder cudy abgebaut). **Unterpunkte/Aufräum-Liste bei Migration:** (a) die Interim-Härtung ap2 `wifi1/wifi2 frame-types=admit-only-vlan-tagged` (TP3.1, 2026-07-06) bleibt gültig — verschwindet automatisch mit VLAN1; (b) ~~`st-main rrm/wnm` = reines Roaming-Provisorium~~ → **kein Provisorium mehr (2026-08-13, TP3.3): Steering ist fester Bestandteil des Golden-Config-Templates + ComplianceFeature `wifi-steering`** — es war die Neuprovisionierung, die es stillschweigend verloren hatte; (c) ~~**cudy1 = verbleibender aktiver VLAN1-Leak**~~ → **ERLEDIGT (User-bestätigt + verifiziert 2026-08-14): cudy1 ist offline.** `core ether11` trägt **kein Link** (kein `R`-Flag), Nautobot-Status *Offline* (TP22 Schritt 5). Damit existiert kein aktiver VLAN1-Leak mehr; der Dual-DHCP-Race aus `project_vlan1_dhcp_incident` ist Historie. Der formale Teardown (Gerät ausbauen, Doku/Inventar) bleibt TP19.
@@ -348,10 +362,39 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - **(b) Live-Torch als Ad-hoc-Observability:** DNS ist bei direktem 1.1.1.1 blind, **Flows nicht** (NATen über ap1). `torch` auf `vlan30`/`vlan50` gefiltert auf die Geräte-IP zeigt Ziel-IPs live (Versuni → AWS `eu-west-1` IoT erkennbar). Voraussetzung: Gerät aktiv. Merkregel: Airfryer nur online wenn er kocht → Capture ans Einschalten koppeln.
 - **Abh.:** UNTRUSTED-Move des Airfryers (Kandidat, s. VLAN50) + TP5-Deny-by-default. Kein Blocker.
 
-### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ DAS Ziel
-- **CAKE am WAN-Upload** (~85–95 % Linerate) → Bufferbloat weg. Verifikation waveform.com → A/A+.
-- ⚠️ **Vor „Erfolg":** A/B-Test, denn Kollegen-Befund sagt DE-Calls = **internat. Pfad AT↔DE**, nicht Heimnetz → ggf. **WARP** statt/zusätzlich CAKE. Nicht am einen Telefonat festmachen.
-- Abh.: TP4.
+### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ 🟠 **PRÄMISSE PRÜFEN, BEVOR gebaut wird** (2026-08-18)
+- 🔴 **Der Widerspruch, der zuerst aufzulösen ist:** dieser TP wird seit Monaten als „DAS Ziel" geführt —
+  aber `docs/call-quality-diagnosis.md` hat den Bufferbloat **bereits gemessen** und kommt zum
+  gegenteiligen Schluss. Wörtlich in dessen Ergebnistabelle:
+  `CAKE / QoS | kein Bufferbloat-Spielraum | ❌ nicht deployt (wäre marginal)`, und im Kopf:
+  TP6 „hat sich als **Nicht-QoS-Problem** entpuppt".
+  **Messwerte (2026-06-16):** 3 Flows = **10,3 Mbit** Upload gesättigt · idle **12 ms** ·
+  Vollast avg **17,5 ms** / max **26 ms** → **A/A+**. Bei solchen Zahlen holt CAKE nichts mehr.
+- ⚖️ **Was das relativiert:** die Messung stammt aus der **FritzBox-Ära**. Seither ist der Edge komplett
+  getauscht (Arris im Bridge-Mode, NAT und Queuing liegen auf `crs326-core`). Die Leitung ist dieselbe,
+  das Pufferverhalten des neuen Edge ist **ungemessen**.
+- ➡️ **Erster Schritt ist deshalb keine Konfiguration, sondern eine halbe Stunde Messen:**
+  Bufferbloat-Test gegen den heutigen Edge. Kommt wieder A/A+ heraus, ist TP6 **erledigt statt offen**
+  und der kritische Pfad ist leer. Kommt es schlechter heraus, ist die Ursache neu und CAKE ist die
+  Antwort darauf — dann aber mit einer Zahl als Begründung.
+- 🔎 **Fasttrack ist auf dem Core faktisch tot — und das ist kein Entwurf, sondern ein Unfall**
+  (Befund 2026-08-18): die Regel `defconf: accept est,rel,untracked` steht **vor**
+  `defconf: fasttrack`, also wird Fasttrack nie erreicht. Live: **32.979.171 Pakete** auf der
+  accept-Regel, **0** auf der Fasttrack-Regel, **0 von 445** Verbindungen fasttracked.
+  - **Herkunft:** `ap1` hatte die Reihenfolge vor dem Cutover **richtig** (Fasttrack zuerst, wie im
+    MikroTik-defconf). Umgedreht wurde sie beim handgebauten Core-Aufbau (TP21.1).
+  - **Für TP6 ist das günstig:** Fasttrack umgeht die Queues, CAKE braucht sie — ein Konflikt, den man
+    sonst erst auflösen müsste, existiert hier gar nicht.
+  - ⚠️ **Ungemessen ist der Preis:** ohne Fasttrack läuft **jedes** geroutete Paket durch die volle
+    Kette samt Conntrack, auf der Core-CPU. Für 10 Mbit WAN irrelevant, für **Inter-VLAN**-Transfers
+    (NAS ↔ MAIN, Synology Drive) möglicherweise nicht. Das ist messbar und sollte gemessen werden,
+    bevor jemand die Reihenfolge „repariert".
+  - 🔴 **Und es steht seit 2026-08-18 als ABSICHT in der SoT:** das Re-Baseline
+    (`ingest-core-firewall.py --apply`) hat die Reihenfolge unverändert nach Nautobot geschrieben,
+    Rule `ip-firewall-filter` mit `config_ordered=true`. **Entscheidung nötig:** Reihenfolge korrigieren
+    (Fasttrack lebt wieder) · Fasttrack-Regel entfernen (ehrlich: wir nutzen sie nicht) · so lassen und
+    hier begründet stehen lassen. Bis dahin ist der Zustand wenigstens dokumentiert statt still.
+- **Abh.:** TP5 ✅ (keine Blocker mehr). Vorgelagert: die Messung oben.
 
 ### TP7 — Media-Discovery (mDNS) für VLAN 40 ▸ ✅ FERTIG (2026-07-02) — `docs/tp7-mdns.md`
 - ✅ **Built-in mDNS-Repeater** aktiv — **Live-Stand `crs326-core` (verifiziert 2026-08-14):**
@@ -841,6 +884,14 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   - 🎯 **Strukturell bleibt es eng:** Nautobot teilt sich die DS923+ (4 Kerne) mit einer VMM-VM,
     Active Backup und ~14 weiteren Containern. Der Stack bleibt vorerst dort (User-Entscheid
     2026-08-18); **ein groesserer Server ist gedanklich bereits vorgemerkt**.
+- 🔴 **Die Kehrseite des Re-Baselines, am eigenen Leib gelernt (2026-08-18):** `ingest-core-firewall.py`
+  erklärt den **Ist-Stand zum Soll** — es prüft nicht, ob der Ist-Stand sinnvoll ist. Beim Lauf nach
+  TP5 E3/E4 ist damit die **kaputte Fasttrack-Reihenfolge** des Core als Absicht in den Config-Context
+  gewandert (s. TP6). Der Warnhinweis im Skriptkopf („nur nach einer bewusst durchgeführten,
+  verifizierten Änderung laufen lassen") ist also **notwendig, aber nicht hinreichend**: die Änderung
+  war bewusst, die *Umgebung*, die mitgeschrieben wurde, hat aber niemand angesehen.
+  **Merkregel: nach dem ersten Re-Baseline einer Sektion deren Diff einmal ganz lesen**, nicht nur die
+  Zeilen, die man selbst angefasst hat.
 - 🔧 **Zwei echte Template-Fehler, beim Re-Baseline 2026-08-18 gefunden** (beide gepusht):
   - `/ip service set … **address=**` → RouterOS 7.23/7.24 exportiert **`available-from=`**. Das
     erzeugte vier Dauer-Drifts (ap1/ap2/branch/core), bei denen das **Geraet** recht hatte und das
@@ -1358,6 +1409,42 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   liefert das Entscheidungskriterium). ⚠️ **Berührt TP5:** der Mesh-Verkehr braucht bei deny-by-default eine
   explizite `forward`-Zeile — s. TP5 Etappe 2.
 
+### TP26 — `/ip firewall filter` unter Drift-Kontrolle ▸ ✅ **DURCH (2026-08-17)**
+> **Nachgetragen 2026-08-18.** TP26 existierte bis dahin nur als zwei Commits und eine `.rsc` — ohne
+> Abschnitt in dieser Datei. Genau die Lücke, die eine frische Session nicht finden kann.
+
+- **Auslöser:** vor TP26 gab es eine ComplianceRule auf `/ip firewall nat`, aber **keine** auf
+  `/ip firewall filter`. Die vielzitierte „72/72 grün" sagte über die Firewall damit **gar nichts** —
+  und das ausgerechnet, während TP5 den Deny-by-default vorbereitete. Der Drop wäre die einzige Regel
+  im Netz gewesen, die niemand überwacht.
+- ✅ **Rule `ip-firewall-filter` angelegt**, `config_ordered=true` — bei Firewallregeln ist die
+  Reihenfolge semantisch, nicht kosmetisch. Ergebnis damals: **76/76**. Damit war TP5 Etappe 3 entblockt.
+- ✅ **Zweiter Teil: die defconf-Firewall auf beiden APs abgeräumt** (`routeros/tp26-ap-firewall-cleanup.rsc`).
+  ap1/ap2 trugen je 12 Werksregeln — input-seal, fasttrack, ipsec-Zeilen, sogar „accept to local loopback
+  (for CAPsMAN)". Inert, weil ein reiner AP nichts routet. **Entscheid: abräumen statt ins Template
+  schreiben** — sonst erklärt man Werksmüll zur Absicht. Dasselbe Argument hat 2026-08-18 auch die alten
+  WLAN-Objekte auf den APs erledigt (TP28).
+- 📌 **`--assert` hat dabei zwei Fehlschläge gefangen**, die der Job-Status als Erfolg gemeldet hätte.
+  Seitdem ist die Gegenprüfung am Gerät fester Bestandteil von `gc-manual-plan.py`.
+- **Abh.:** TP22 ✅. Direkte Folge: TP5 E3/E4.
+
+### TP27 — RouterBOOT-Firmware auf 7.24 nachziehen ▸ ✅ **DURCH (2026-08-17/18)**
+> **Nachgetragen 2026-08-18.** Auch TP27 hatte keinen Abschnitt — die Arbeit steckt in Christophs Commit
+> `b93514a` plus `routeros/tp27-routerboot-firmware-724.rsc` und
+> `docs/routerboot-firmware-klickanleitung.md`.
+
+- **Kontext:** Christoph hat alle vier MikroTik selbst auf **RouterOS 7.24 stable** gehoben
+  (core/branch 7.19.5 → 7.24, ap1/ap2 7.23.2 → 7.24). Offen blieb die zweite Hälfte jedes
+  MikroTik-Upgrades: die **RouterBOOT-Firmware** hängt danach zurück.
+- 🔑 **Die Falle, wegen der es ein eigener TP ist:** `/system routerboard upgrade` **schreibt** die
+  Firmware nur — wirksam wird sie erst beim **nächsten Reboot**, und `current-firmware` zeigt bis dahin
+  weiter den alten Wert. Wer direkt nach dem Befehl prüft, hält den Schritt fälschlich für gescheitert.
+  Reihenfolge also: schreiben → gezielt rebooten → `current-firmware` gegenprüfen.
+- ⚠️ **`/system routerboard upgrade*` steht auf der MikroMCP-Deny-Liste** (zu Recht — es schreibt den
+  Bootloader). Der Weg führt über Golden Config; der Reboot dann über `sshpass`/MikroMCP.
+- ✅ **Abnahme 2026-08-18:** auf allen vier Geräten `current-firmware = upgrade-firmware = 7.24`.
+- **Abh.:** keine. Berührt TP28 insofern, als CAPsMAN erst ab 7.2x das neue `/interface/wifi` mitbringt.
+
 ### TP28 — WLAN über CAPsMAN auf `crs326-core` ▸ ✅ **KOMPLETT (2026-08-18)** — mit Nachtrag: **`slaves-datapath` fehlte, IOT+MEDIA lagen ~14 h**
 
 - 🔴🔴 **POST-MORTEM 2026-08-18 (gemeldet von Christoph: „die -iot-geräte sind offline … connect möglich, aber kein dhcp"):**
@@ -1489,15 +1576,19 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 
 ## Reihenfolge / Abhängigkeiten
 
-### 🎯 Kritischer Pfad (Stand 2026-08-17)
+### 🎯 Kritischer Pfad (Stand 2026-08-18)
 
 ```
 TP5 E1 ✅ ──► E2 ✅ ──► E2-Nachtrag ✅ ──► E3 Drop ✅ ──► E4 input+MGMT ✅ ──► TP6 (CAKE) ◄ Projektziel
                                                                                   ▲
                                                                         ab hier ist alles frei
 ```
-**TP5 ist am 2026-08-18 abgeschlossen.** Der kritische Pfad besteht damit nur noch aus **TP6 (CAKE)** —
-dem eigentlichen Projektziel. Alles andere laeuft nebenher und blockiert nichts.
+**TP5 ist am 2026-08-18 abgeschlossen.** Damit steht rechnerisch nur noch **TP6** auf dem kritischen Pfad —
+🟠 **aber dessen Prämisse ist offen**: eine Messung von 2026-06-16 (`docs/call-quality-diagnosis.md`)
+bescheinigt dem Netz bereits **A/A+** und hält CAKE für „marginal". Der nächste Schritt ist deshalb ein
+**Bufferbloat-Test gegen den heutigen Edge**, nicht der Bau einer Queue. Fällt er gut aus, ist der
+kritische Pfad **leer** und das Projekt in seinem Kern fertig — dann entscheidet Christoph, was das neue
+Ziel ist. Alles andere läuft nebenher und blockiert nichts.
 
 1. ✅ **TP5 Etappe 1–4 — komplett durch** (2026-08-16 bis 2026-08-18). Details im TP5-Abschnitt oben.
    Die Wartezeit-Position, die hier bis 2026-08-17 als eigener Schritt stand, ist eingeloest: statt
@@ -1535,6 +1626,9 @@ den Weg, über den man den Fehler zurücknehmen wollte.
 - **TP10 —** DDNS-Auto-Updater für `bf4.emsenhuber.net` (auf dem Core möglich, `device-mode` erlaubt scheduler).
 - **TP14.4 —** CF-Access-Service-Token rotieren.
 - **Doku-Aufräumen** (`docs/doku-cleanup-session.md`) — Punkte A–D am 2026-08-16 abgearbeitet, E teilweise.
+  📌 **Läuft in einer eigenen Session** — Übergabe: `docs/handoff-doku-session-20260818.md`.
+  ⚠️ **Solange die läuft, `teilprojekte.md` nicht parallel bearbeiten** (in der Nacht auf den 18.
+  viermal committet, das kollidiert sonst).
 
 ### Nachgelagert / research-getrieben
 
@@ -1548,7 +1642,7 @@ steht unten unter „Durch". Nachfolger ist **TP16.3**, das oben unter Follow-up
 
 TP1 · TP2 · TP2.1 · TP3 (Rebuild 2026-08-08) · TP3.1 · TP4 (Rolle seit 08-08 auf dem Core) · TP7 · TP7.2 ·
 TP10 (Kern) · TP14 (+14.1/14.2/14.2a/14.3/14.5) · TP15 · TP16 (Kern) · TP17 · TP19.1 · TP20 · TP21 · TP21.1 ·
-TP22 · TP-R · **TP3.2** (2026-08-17) · **TP5** (2026-08-18) · **TP19** (2026-08-18) · **TP28** (2026-08-17). **Verworfen:** TP9 (Gateway-HA, User-Entscheid 2026-08-08). **Obsolet:** Omada-PVID-Fix
+TP22 · TP-R · **TP3.2** (08-17) · **TP5** (08-18) · **TP7.1** (08-18) · **TP19** (08-18) · **TP23 Stufe 1** (08-18) · **TP26** (08-17) · **TP27** (08-17/18) · **TP28** (08-17, GC-Modell 08-18). **Verworfen:** TP9 (Gateway-HA, User-Entscheid 2026-08-08). **Obsolet:** Omada-PVID-Fix
 (User-Entscheid 2026-07-22 — „nie wieder aufgreifen").
 
 <details><summary>📜 Historische Fassung dieses Abschnitts (bis 2026-08-14 fortgeschrieben, hier bewusst erhalten)</summary>