Ü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 §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 <IoT-MAC>, dazu /log print where message~"<MAC>" 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 <lauf>`	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:

cap-wifiN-Nummern sind dynamisch — nie hartkodieren, nie live auf alte Daten anwenden. Die Karte gehört zum Messlauf (ap-map.txt).
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).
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.

6.6 KiB Raw Blame History Unescape Escape