TP6-Praemisse: Messrunbook + Fasttrack entschieden

Der kritische Pfad widersprach sich selbst: der Einleitungsabsatz sagte seit
dem 18. "Praemisse offen, erst messen", Punkt 2 der Liste darunter sagte
weiter "keine offenen Blocker mehr". Punkt 2 nachgezogen.

Neu: docs/tp6-praemisse-messrunbook.md. Reproduziert die Methode von
2026-06-16 (3 Flows Saettigung + 24 Pings idle/Last), damit die Zahlen
vergleichbar sind, und misst erstmals die Download-Richtung -- die wurde
damals nie gemessen und ist beim asymmetrischen Kabelanschluss die
wahrscheinlichere Problemseite. Das Abbruchkriterium steht VOR der Messung:
A/A+ heisst TP6 wird geschlossen statt gebaut.

Fasttrack (die Entscheidung, die der Handoff Christoph vorbehalten hat):
bleibt wie er ist, gilt ab jetzt aber als Absicht statt als Unfall. Bei
~10 Mbit WAN kostet der Verzicht nichts, fuer CAKE ist er sogar die
bequemere Ausgangslage. Gegenbedingung notiert: wer Inter-VLAN je auf
Gigabit will, muss vorher messen, was die Core-CPU ohne Fasttrack traegt.

Damit sind zwei offene Stellen zu -- das "Entscheidung noetig" in TP6 und
die TP21-Warnung, dass das Re-Baseline den Zustand zum Soll erklaert hat.
Die Merkregel dort bleibt: dass es diesmal gut ausging, war Glueck.

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

docs/teilprojekte.md

@@ -385,15 +385,35 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
     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.
+  - ✅ **ENTSCHIEDEN (Christoph, 2026-08-19): der Zustand bleibt — und gilt ab jetzt als Absicht, nicht
+    als Unfall.** Begründung: bei ~10 Mbit WAN kostet der Verzicht nichts (die Core-CPU trägt den
+    Forward-Pfad ohnehin, 32,9 Mio Pakete sind der Beleg), und für CAKE ist er die bequemere Ausgangslage.
+    Damit ist auch die TP21-Warnung „das Re-Baseline hat den Fehler zum Soll erklärt" **aufgelöst**: die
+    Reihenfolge in der SoT ist jetzt gewollt. Sie war es bei der Aufnahme nur nicht.
+    - ⚠️ **Gegenbedingung, unter der neu bewertet wird:** wenn **Inter-VLAN** je auf Gigabit soll
+      (NAS ↔ MAIN läuft geroutet über dieselbe 800-MHz-CPU), ist der Verzicht teuer. **Die Messung dafür
+      steht aus** — und sie, nicht die WAN-Zahl, ist die Vorbedingung jeder Neubewertung.
   - ⚠️ **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
+    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.
+    hier begründet stehen lassen.~~ → **entschieden am 2026-08-19, s. oben: so lassen.** Damit stimmen
+    SoT und Absicht wieder überein — bisher stimmten sie nur zufällig überein.
+- 📋 **Runbook liegt bereit: `docs/tp6-praemisse-messrunbook.md`** (2026-08-19). Es reproduziert die
+  Methode von 2026-06-16 (3 Flows + 24 Pings idle/Last), misst erstmals auch die **Download-Richtung**
+  (die 2026-06-16 **nie** gemessen wurde — beim asymmetrischen Kabelanschluss die wahrscheinlichere
+  Problemseite), und trägt das Abbruchkriterium **vor** der Messung: A/A+ → TP6 wird **geschlossen statt
+  gebaut**. Enthält außerdem den Bau-Kontext für den Fall B, damit er nicht neu recherchiert wird —
+  vor allem: **`/queue` fehlt im GC-Template und hat keine ComplianceRule** (dieselbe blinde Stelle, die
+  TP26 für `/ip firewall filter` geschlossen hat), eine handgesetzte Queue wäre also driftend und
+  ungeschützt.
+- 📌 **Nicht im Repo dokumentiert und deshalb Teil der Messung: die tatsächliche Liwest-Linerate.**
+  Die „~10 Mbit" stammen aus der Sättigungsmessung von 2026-06-16, nicht aus einem Tarifdatenblatt.
+  Ohne diese Zahl ist die übliche CAKE-Vorgabe „85–95 % Linerate" geraten.
 - **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`
@@ -892,6 +912,10 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   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.
+  - ✅ **Nachtrag 2026-08-19: der konkrete Fall ist aufgelöst** — Christoph hat entschieden, die
+    Fasttrack-Reihenfolge **so zu lassen** (Begründung in TP6). Der Eintrag in der SoT ist damit
+    nachträglich korrekt. **Die Merkregel bleibt trotzdem gültig:** dass ein versehentlich
+    mitgeschriebener Zustand sich hinterher als brauchbar herausstellt, ist Glück, kein Verfahren.
 - 🔧 **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
@@ -1598,7 +1622,11 @@ Ziel ist. Alles andere läuft nebenher und blockiert nichts.
    Anlernen eines IoT-Geraets (User 2026-08-17). Wer im IOT-SSID sitzt, ist im selben VLAN wie das
    Geraet und beruehrt die `forward`-Kette gar nicht; fuer Ad-hoc-Zugriffe aus MAIN gibt es jetzt die
    selbstverfallende Gruppe `jit-admin`.
-2. 🔜 **TP6 — QoS/CAKE + Call-Quality-A/B-Test.** Das eigentliche Projektziel; **keine offenen Blocker mehr**.
+2. 🟠 **TP6 — QoS/CAKE + Call-Quality-A/B-Test.** ~~Das eigentliche Projektziel; **keine offenen Blocker mehr**.~~
+   **Korrigiert 2026-08-19:** kein *Blocker*, aber eine offene **Prämisse** — der Satz oben und dieser
+   Punkt widersprachen sich seit dem 18. Richtig ist: der nächste Schritt ist eine **Messung**, kein Bau.
+   Runbook liegt bereit: `docs/tp6-praemisse-messrunbook.md`. Fällt sie A/A+ aus, wird TP6 **geschlossen
+   statt gebaut** — dann ist der kritische Pfad leer und das Projekt in seinem Kern fertig.
 
 **Eine harte Reihenfolge-Regel dazwischen:** TP5 darf die **DNS-Bypass-Sperre erst schließen, wenn TP23s
 Ausnahme-Oberfläche steht** — der bisherige Workaround „Client von Hand auf `1.1.1.1`" *ist* genau dieser