Plan: zwei Fehler aus meinem eigenen Text, beide mit Ausfallfolge

Erstens: die neue Zuweisung stamp="$(docker compose exec …)" ist blank und laeuft
unter set -Eeuo pipefail. Auf jedem Wirt ohne laufenden Gateway beendet sie den
ganzen Update-Agenten — nach write_alive, der Takt sieht also gesund aus,
waehrend der Update-Knopf still nicht mehr funktioniert. Der Docblock derselben
Funktion warnt vor genau dieser Falle, nur fuer sed. Jetzt "|| stamp=''".

Zweitens: der Gesundheits-Port meldete Bereitschaft, sobald der Gateway laeuft.
Seit dieses Skript Namen ohne Zertifikat auslaesst, kann er laufen und auf 443
gar nichts bedienen — VPN_READY stuende auf true und ausgegebene
Client-Konfigurationen nennten einen Resolver, der auf eine ablehnende Adresse
zeigt. Er antwortet jetzt nur mit 204, wenn der Konsolenblock wirklich gerendert
wurde. Damit erscheint auch die Betreiber-Warnung wieder, ueber die vorhandene
Pruefung in update.sh.

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

docs/superpowers/plans/2026-08-04-oeffentliche-seiten-im-tunnel.md

@@ -630,14 +630,27 @@ echo "${VPN_TUNNEL_HOSTS:-}" | tr ',' '\n' | while read -r host; do
     emit_site "$host"
 done
 
-# Der Gesundheits-Port, ohne TLS und ohne Namen. Daran hängt VPN_READY und damit,
-# ob ausgegebene Client-Konfigurationen den Resolver überhaupt nennen — er darf
-# deshalb von keinem Zertifikat abhängen.
+# Der Gesundheits-Port. Er lauscht immer — aber er ANTWORTET nur mit 204, wenn
+# der Konsolenblock wirklich gerendert wurde.
+#
+# Daran hängt VPN_READY und damit, ob ausgegebene Client-Konfigurationen den
+# Resolver überhaupt nennen. Ein Port, der bloß „dieser Gateway läuft" sagte,
+# meldete den Tunnel auch dann bereit, wenn auf 443 gar nichts bedient wird —
+# und der Client bekäme einen Resolver genannt, der ihn auf eine Adresse
+# schickt, die die Verbindung ablehnt. Früher war das unmöglich, weil Caddy ohne
+# lesbares Zertifikat überhaupt nicht startete; genau diese Annahme hebt dieses
+# Skript auf, also muss die Bereitschaft neu beantwortet werden.
+if [ -n "${VPN_INTERNAL_HOST:-}" ] && grep -q "^https://${VPN_INTERNAL_HOST}:443 {" "$OUT"; then
+    HEALTH_CODE=204
+else
+    HEALTH_CODE=503
+fi
+
 {
     echo ""
     echo "http://${HUB}:${HEALTH} {"
     echo "	bind ${HUB}"
-    echo "	respond /healthz 204"
+    echo "	respond /healthz ${HEALTH_CODE}"
     echo "	respond 404"
     echo "}"
 } >> "$OUT"
@@ -780,9 +793,15 @@ schreibt, mit Rückfall auf den alten Pfad:
     # Gelesen wird weiterhin INNERHALB des Gateways: Caddys Speicher gehoert
     # seinem eigenen Dienstkonto, und dieser Agent laeuft unprivilegiert und
     # koennte ihn nicht einmal durchqueren.
+    # `|| stamp=''` ist nicht Kosmetik: eine blanke Zuweisung reicht unter
+    # `set -Eeuo pipefail` den Status von `docker compose exec` an `set -e`
+    # weiter, und auf jedem Wirt ohne laufenden Gateway endete damit der GANZE
+    # Agent — nach `write_alive`, der Takt saehe also gesund aus, waehrend der
+    # Update-Knopf still nicht mehr funktioniert. Genau die Falle, vor der der
+    # Docblock dieser Funktion schon fuer `sed` warnt.
     stamp="$(docker compose exec -T vpn-gateway sh -c \
         'xargs -r stat -c %Y < /tmp/vpn-certs.list 2>/dev/null | sort | tr "\n" ","' \
-        2>/dev/null | tr -d '\r\n')"
+        2>/dev/null | tr -d '\r\n')" || stamp=''
 
     # Rueckfall auf den alten Weg, solange ein Gateway von vor dieser Fassung
     # laeuft und die Liste noch nicht schreibt. Ohne ihn bliebe die Erneuerung
@@ -790,7 +809,7 @@ schreibt, mit Rückfall auf den alten Pfad:
     if [[ -z "$stamp" ]]; then
         path="$(sed -n 's/^VPN_CERT_PATH=//p' "$ROOT/.env" 2>/dev/null | tail -1)"
         [[ -n "$path" ]] || return 0
-        stamp="$(docker compose exec -T vpn-gateway stat -c %Y "$path" 2>/dev/null | tr -d '\r\n')"
+        stamp="$(docker compose exec -T vpn-gateway stat -c %Y "$path" 2>/dev/null | tr -d '\r\n')" || stamp=''
     fi
 
     [[ -n "$stamp" ]] || return 0