# Übergabe 2026-08-22 — was als Nächstes, jeweils als eigene Session Jeder Block unten ist **eine Session mit frischem Kontext**. Reihenfolge = Empfehlung, nicht Zwang; die Blöcke hängen nicht voneinander ab. Einstieg immer: `docs/teilprojekte.md` lesen. --- ## 1️⃣ TP6 — CAKE bauen **oder begründet schließen** (das eigentliche Projektziel) **Warum jetzt:** TP25 hat den kritischen Pfad seit dem 08-20 blockiert und ist erledigt. TP6 ist damit der einzige verbliebene Punkt — und das Ziel, mit dem dieses Projekt angefangen hat. 🔴 **Diese Session misst NICHT neu. Sie entscheidet.** Die Prämisse ist am 08-20/21 geprüft ([`tp6-praemisse-messrunbook.md`](tp6-praemisse-messrunbook.md) §5): | | idle | Upload-Last | Download-Last | |---|---|---|---| | gemessen | 12,9 ms | **60,4 ms** | 41,3 ms | | Referenz 06-16 | 12 ms | 17,5 ms | — | Linerate 9,6 Mbit up / 54,6 Mbit down. Der Anstieg liegt bei **+28 bis +47 ms** in der Senderichtung und damit über der §3-Schwelle → **formal Fall B, CAKE ist begründet.** 🔴 **Aber:** durch alle sechs Lastphasen lief ein Telegram-Videocall, und es wurde **kein einziger Problem-Button gedrückt**. waveform gab zeitgleich Grade A. **Die zu beantwortende Frage ist also nicht „ist es messbar", sondern „lohnt es".** Argumente für Bauen: 9,6 Mbit Upload ist wenig, ein einzelner Upload sättigt sie; Bufferbloat trifft dann alles andere. Argumente für Schließen: nicht wahrnehmbar, und jede Queue ist dauerhafte Komplexität in einem Pfad, der heute funktioniert. **Wenn gebaut wird, Reihenfolge zwingend** (§4.1): erst `/queue` ins GC-Template **plus** ComplianceRule, dann die Queue deployen, dann dieselbe Messung als A/B-Nachweis. Nicht am Gerät vorbei — `project_ap_config_freeze_until_nautobot`. **Wenn geschlossen wird:** in `teilprojekte.md` als „gemessen, bewusst nicht gebaut" mit den Zahlen dokumentieren. Dann ist der kritische Pfad **leer** und Christoph setzt das nächste Ziel. --- ## 2️⃣ Admin-Passwort der vier MikroTik rotieren **Warum:** das Core-Passwort ist am 2026-08-22 durch eine Debug-Ausgabe im Klartext in ein Sitzungstranskript geraten. Ursache war `sshpass -p`, das es in die Kommandozeile schreibt. ✅ **Vorbedingung ist erledigt:** alle Werkzeuge laufen auf `sshpass -e` (`tp6-monitor-core.sh`, `tp25-walk-messung.sh`, `tp25-pin-s22.sh`, `tp6-marker/server.py`). `grep -rn "sshpass -p" docs/ nautobot/` findet nur noch die Erwähnung in der Doku. **Weg:** `manage_user set-password` über MikroMCP (⚠️ `/user set*` ist per Deny-Policy blockiert), für **alle vier** Geräte — es ist ein gemeinsames Passwort („Überlebensversicherung"). Danach nachziehen: `~/.secrets/credentials.env` (`ROUTER_*_PASS`, `CRS326_*_PASS`), `~/.claude.json`. **Abnahme:** je Gerät ein Lesezugriff mit dem neuen Passwort — nicht die Anzeige des Jobs. --- ## 3️⃣ TP25 abschließen: Fund F messen + 20-MHz-Entscheidung Zwei Reste, beide klein. **Fund F — IoT-Clients trennen exakt alle ~5:05.** Nie gemessen, nur beobachtet. 🔴 Unter CAPsMAN ist die Registration-Table **am Manager** zu lesen, die AP-Tabellen sind leer (`ref_capsman_slaves_datapath`). Werkzeug: `docs/tp6-monitor-core.sh --mac `, dazu `/log print where message~""` am Core. Verdacht: DHCP-Lease-Zeit oder ein Sleepy-End-Device- Intervall — vor der Diagnose die Lease-Zeit des VLAN30-Servers prüfen. **5 GHz auf 20 MHz (+3 dB):** die letzte offene Funkmaßnahme. Der Lauf vom 08-22 zeigt: die **Alltagsabdeckung braucht sie nicht** (17 von 21 Abschnitten 0 % Verlust). Sie würde die dünne **Rückfallebene** stärken (Schlafzimmer −85, Bad −82, Küche −82 auf dem Gegen-AP). Kosten: Durchsatz, der laut TP6-Messung nicht knapp ist. **Entscheidung, keine Messung.** Danach kann TP25 geschlossen werden. ⚠️ **Fund E (`signal-range`-Boden) NICHT umsetzen**, bevor ein Sticky-Fall erneut gemessen ist — am 08-22 reproduzierte er sich nicht (Treppe: sauberer Wechsel, 0 % über 57 s). --- ## 4️⃣ Governance-Lücke: ComplianceRule für `/interface wifi access-list` **Warum:** es gibt Regeln für `wifi-configuration/-datapath/-security/-steering/-provisioning/ -channel/-cap/-capsman`, aber **keine** für `access-list`. Änderungen dort erzeugen **keinen Drift** und lassen sich nicht als Transaktion führen (`gc-transaktion.py` verlangt eine ComplianceRule als `--scope`). Das ist seit dem 08-22 nicht mehr theoretisch: `docs/tp25-pin-s22.sh` schreibt bei jedem Rundgang access-list-Regeln, und Fund E würde dort dauerhaft landen. **Aufwand: klein** (Feature + Rule anlegen, Template ergänzen, `gc-configplan.py --refresh-compliance`). --- ## 5️⃣ Danach, ohne Rangfolge - **TP12.1** — IPv6/ULA + v6-Firewall. 🔴 Reihenfolge zwingend: **v6-Firewall nachbauen, DANN Adressen vergeben**, sonst steht IOT→MAIN an TP5 vorbei offen. Blockiert nur neue Thread-Geräte; bis dahin ist die `-infra`-SSID der Standardweg (User-Entscheid: kein ESP32). - **TP16.3** — cloudflared-Reduktion, Runbook liegt (`tp16.3-nautobot-mesh-only-runbook.md`). - **TP24** — DC-USV · **TP20.1** — Vaultwarden→PG · **TP18** — Garage · **TP16.2** — Härtung - **TP14.4** — CF-Access-Token · **TP13** — Botschafts-WLANs (fun) · **TP29** — Anwesenheitserkennung --- ## Werkzeugstand (damit niemand neu baut, was existiert) | Werkzeug | was es tut | |---|---| | `docs/tp25-runde.sh [name]` | kompletter Messlauf: Konsole + beide Pings + AP-Karte einfrieren, räumt beim Beenden auf | | `docs/tp6-marker/server.py` | Klick-Konsole (Port 3031, 0.0.0.0), Raumkacheln, AP-Pin, Gegen-AP-Automatik, Ton, **Stopp-Knopf** | | `docs/tp25-pin-s22.sh {ap1\|ap2\|off\|status\|map\|which}` | Client per access-list auf einen AP festnageln; `map` liest die AP-Zuordnung **live** | | `docs/tp25-gehweg-auswertung.py --dir ` | Raumtabelle, **beide Rollen nebeneinander** | | `nautobot/gc-transaktion.py` | Teständerungen als Transaktion (begin/status/commit/rollback) | | `nautobot/gc-configplan.py` | der **einzige** legitime Config-Weg für Netzgeräte | 🔴 **Drei Fallen, die in dieser Sitzung Zeit gekostet haben und wiederkommen werden:** 1. **`cap-wifiN`-Nummern sind dynamisch** — nie hartkodieren, nie live auf alte Daten anwenden. Die Karte gehört zum Messlauf (`ap-map.txt`). 2. **Ein abgewiesener Verbindungsversuch sieht aus wie ein Funkloch** und steht in keinem Log. Bei gepinnten Messungen immer prüfen, wie viele Funkproben „absent" sind (08-22: 2,8 %, also sauber). 3. **Anzeige ≠ Wirkung.** In dieser Sitzung dreimal: „beide angemeldet, verschiedene APs" bei gleichem AP · „AP-Pin gelöst" bei stehenden Regeln · „Ruhezustand" bei eigenem Pin-Wechsel.