CluPilotCloud/app/Services/Deployment
nexxo 8733686dd3 Fix-Welle Schlussreview: Tunnel-Rettung und Waechter melden Misserfolg ehrlich
C1: rescue-tunnel.sh zaehlt Probleme (kein Zugang geladen, conntrack ohne
Root) und gibt sie als Exit-Code zurueck, statt bei jedem Fehlschlag Exit 0
zu melden. Die Konsole zeigt jetzt zusaetzlich das Protokoll der letzten
Tunnel-Rettung (UpdateChannel::rescueLog(), dasselbe <details>-Muster wie
das Update-Protokoll), und "erfolgreich" ist einem zurueckhaltenderen
"durchgelaufen"/"completed" gewichen, das nicht mehr behauptet als das
Skript wirklich weiss.

I1: watchdog.sh gewann `geheilt=true` bisher unmittelbar nach `up -d`,
`--force-recreate` und `artisan up`, ohne nachzupruefen, ob der Griff
gewirkt hat. Ein neues `fehlgeschlagen`-Flag laesst einen Misserfolg den
Lauf-Ausgang gewinnen, auch wenn ein anderer Zweig im selben Lauf
erfolgreich war -- die Konsole zeigt jetzt outcome=tried statt sich hinter
outcome=healed zu verstecken.

M3: watchdog_stood_down nennt nicht mehr nur "ein Update" als Sperrenhalter
-- die Sperre haelt inzwischen auch proxy-hosts, restart, archive-key und
rescue-tunnel.

M4: das Runbook nennt den Konsolen-Knopf jetzt vor der Kommandozeile.

M7: ConfirmRescueTunnel hat jetzt einen Test, nach dem Vorbild von
ConfirmReleaseUpdateLock -- mount()s authorize und die Ereignisverdrahtung
Modal -> Seite waren ungeprueft.

Volle Suite: 3036 bestanden, 0 fehlgeschlagen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-04 19:09:02 +02:00
..
Release.php feat(deploy): releases you can pin to, and a version that tells the truth 2026-07-26 15:21:38 +02:00
UpdateChannel.php Fix-Welle Schlussreview: Tunnel-Rettung und Waechter melden Misserfolg ehrlich 2026-08-04 19:09:02 +02:00
UpdateWindow.php Update on a schedule if the owner wants one, and say where incidents go 2026-07-29 15:01:54 +02:00
WatchdogLog.php Der Waechter hinterlaesst, was er getan hat 2026-08-04 17:06:02 +02:00