Eine Runde per Ein-Befehl -- und das gruene Licht log

docs/tp25-runde.sh startet Konsole und Messung zusammen, friert die AP-Karte
ein, sagt die vom Interface GELESENE Adresse fuers Telefon an und loest beim
Beenden den Pin. Grund: beide Einzelteile hatten als Standard-Laufverzeichnis
einen Pfad in ein Sitzungs-Scratchpad -- wer sie ohne die passende
Umgebungsvariable startete, mass in ein totes Verzeichnis und merkte es erst
bei der Auswertung.

Der Probelauf hat dabei sofort einen Fehler in der eigenen Anzeige aufgedeckt:
die Seite meldete "✅ beide angemeldet, auf verschiedenen APs", waehrend beide
Telefone auf ap2 hingen. Das Kriterium prueft "beide angemeldet" -- nicht, ob
sie auf VERSCHIEDENEN APs sitzen. Das ist ein gruenes Licht fuer einen
Messpunkt, den es nicht gibt: Piep, weitergehen, kein Gegen-AP gemessen.
Wieder dieselbe Klasse wie der 14-h-Ausfall -- Anzeige geprueft statt Wirkung.

Jetzt vier Zustaende, gegen sechs Faelle geprueft (inkl. "gleicher AP, anderes
Band" -> zaehlt NICHT):
  bereit           verschiedene APs        -> Piep, weitergehen
  wird nachgezogen gleicher AP, Automatik  -> warten
  kein Gegen-AP    gleicher AP, ohne Auto  -> Warnung statt gruen
  S22 sucht        S22 nicht angemeldet    -> stehenbleiben

teilprojekte.md: Passwort-Rotation als offener Follow-up eingetragen (User:
"machen wir, aber erst spaeter") -- inkl. der noch offenen sshpass -p in
tp6-monitor-core.sh und tp25-pin-s22.sh, die vorher nachgezogen gehoeren.

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

docs/teilprojekte.md

@@ -1394,6 +1394,10 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 > des Rundgangs Stille. Die Konsole schlägt deshalb mit Ton, Vibration und Vollbanner Alarm,
 > sobald das gepinnte Gerät nirgends hängt, und schreibt nach 45 s vergeblicher Suche
 > `UNERREICHBAR=apX` — denn „der Gegen-AP trägt hier nicht" **ist das Messergebnis**.
+> ▶️ **Start ohne Werkzeugkette: `bash docs/tp25-runde.sh [name]`.** Legt den Lauf unter
+> `docs/messdaten/tp25-runde-<name>/` an, friert die AP-Karte ein, startet Konsole (Port 3031)
+> und Messung, sagt die **vom Interface gelesene** Adresse fürs Telefon an und löst beim
+> Beenden (Ctrl-C) den Pin wieder. Auswertung danach mit `tp25-gehweg-auswertung.py --dir …`.
 > ⏸️ **Stand bei Sitzungsende 2026-08-22: Rundgang noch nicht gegangen.** Pin gelöst,
 > Automatik aus, `crs326-core` unverändert (die `access-list` steht unter keiner
 > ComplianceRule, es gibt also nichts zu committen). Erster Messwert nebenbei: am Arbeitsplatz
@@ -1958,6 +1962,16 @@ den Weg, über den man den Fehler zurücknehmen wollte.
   Re-Walk + Dead-Spot-Kartierung laufen als Schritt 5 von TP25 — und zwar erst **nach** den Funkparameter-Fixes,
   weil vorher gemessene Werte wertlos sind.
 - **TP10 —** DDNS-Auto-Updater für `bf4.emsenhuber.net` (auf dem Core möglich, `device-mode` erlaubt scheduler).
+- 🔑 **Admin-Passwort der vier MikroTik rotieren (offen seit 2026-08-22, User: „machen wir,
+  aber erst später").** Anlass: das Core-Passwort ist bei einer Debug-Ausgabe im Klartext in
+  ein Sitzungstranskript geraten. Ursache war `sshpass -p`, das es in die **Kommandozeile**
+  schreibt — sichtbar in `ps` und in jedem argv-Trace. `docs/tp6-marker/server.py` ist auf
+  `sshpass -e` umgestellt (Passwort nur in der Umgebung des Kindprozesses); **`docs/tp6-monitor-core.sh`
+  und `docs/tp25-pin-s22.sh` haben dieselbe Schwäche noch** und gehören vor der Rotation
+  nachgezogen — sonst ist die Rotation nach dem nächsten Messlauf wieder wertlos.
+  Weg: `manage_user set-password` (⚠️ `/user set*` ist per Deny-Policy blockiert), danach
+  `~/.secrets/credentials.env` (`ROUTER_*_PASS`/`CRS326_*_PASS`) und `~/.claude.json` nachziehen.
+  Es ist **ein** Passwort für alle vier Geräte — die „Überlebensversicherung" aus CLAUDE.md.
 - **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`.