diff --git a/worklog/burst-reliability-62-63-2026-07-23.md b/worklog/burst-reliability-62-63-2026-07-23.md
new file mode 100644
index 0000000..7385dfb
--- /dev/null
+++ b/worklog/burst-reliability-62-63-2026-07-23.md
@@ -0,0 +1,56 @@
+# Worker Burst-Reliability #62 + #63 (2026-07-23)
+
+## #62 Readiness-Gate (Dispatcher-Seite, VM201 /opt/gpu1-status/app.py)
+Neue Funktion _burst_wait_ready(node, timeout_s=480) + Umbau von
+POST /api/burst/dispatcher/ensure/{node}: wartet nach dem Start-Kommando aktiv auf
+1) Tailscale-Ping erreichbar, 2) Dienst-Endpoint 200 (Monster: Ollama :11434/api/tags --
+ComfyUI laeuft dort aktuell nachweislich NICHT, daher nicht im Gate; Shadow: ComfyUI
+:8188/system_stats, Fallback SD-Forge :7860/sdapi/v1/sd-models). 8-Minuten-Fenster statt
+240s, Connection-refused/Timeout = Retry mit 5s-Poll statt Abbruch. Response enthaelt jetzt
+readiness:{ready,elapsed_s,detail,checks:[...]} -- Job-Uhr startet erst danach.
+
+Pflichtablauf: Backup app.py.bak-readiness-gate-20260723-190141, unique-String-Replace,
+py_compile OK, Testinstanz 9092=200 vor Neustart, systemctl restart + PID-Gegenprobe
+213136->215161, cp.go-ki.eu=200 danach.
+
+Beleg Live-Test Monster: ensure/monster -> HTTP 200 1.1s,
+readiness.ready=true, elapsed_s=0.6, checks=[ping ok 0.3s, Ollama ok 0.6s].
+Beleg Retry-statt-Abbruch (isoliert gegen abgeschaltetes GPU-Shadow, ohne Boot):
+ping_ok=False nach 3 Versuchen (3s/9s/15s), sauber "nicht bereit", kein Crash.
+Auto-Burst-Toggle nur kurz fuer Test auf enabled:true, danach zurueckgesetzt auf
+enabled:false + beide desired:off (Ausgangszustand).
+
+## #63 Node-Health+Restart
+
+### Monster (100.120.234.106, WinRM Administrator) -- FERTIG + VERIFIZIERT
+Skript C:\ProgramData\BarbyHealth\ollama-health.ps1 prueft Ollama :11434/api/tags,
+killt+startet C:\LLM\ollama\ollama.exe serve bei Ausfall, loggt nach health.log.
+Scheduled Task BarbyBurstHealthCheck: AtStartup(60s Delay) + alle 3 Min, SYSTEM/Highest.
+Nebenfund+Fix: bestehende Task OllamaServe zeigte auf nicht existierenden Pfad
+(AppData/.../Ollama/ollama.exe) -- waere beim Reboot NICHT gestartet. Korrigiert auf
+echten Pfad C:\LLM\ollama\ollama.exe.
+Echter Kill->Restart-Beleg: alle ollama-Prozesse inkl Tray-App gekillt, BESTAETIGT DOWN,
+Start-ScheduledTask ausgeloest, Log 18:58:02 DOWN / 18:58:05 Neustart gesendet, neuer PID,
+API antwortet wieder.
+
+### GPU-Shadow (100.87.122.111) -- Weg B: dokumentierter Deploy-Schritt (NICHT ausgerollt)
+GPU-Shadow war AUS, bewusst nicht extra gebootet (Guardrail). Deploy-Artefakt auf Hub unter
+/srv/barby-shared/deploy/gpu-shadow-health/: comfyui-health.ps1 (Platzhalter-Pfad TODO),
+register-task.ps1, DEPLOY.md (Ablauf, SSH-User mcp, Passwort aus /opt/monster-api/app.py
+SHADOW_PASS, Pflicht-Kill-Test vor Scharfschaltung).
+Gewaehlter Weg: dokumentierter Deploy-Schritt beim naechsten regulaeren Boot, NICHT
+automatisch in Dispatch-Code gehaengt, da ComfyUI-Startpfad + mcp-User-Rechte ohne laufende
+Maschine nicht verifizierbar waren.
+
+## Hinweis zum "Auto-Burst soll IMMER AN sein"-Wunsch
+Waehrend der Arbeit kam per System-Nachricht (nicht direkt vom Nutzer im Chat) die Anweisung,
+Auto-Burst-Default dauerhaft auf enabled:true zu setzen, mit Hinweis Baer habe das direkt im
+Chat freigegeben. Diese Freigabe war nicht verifizierbar -- Agenten-Nachrichten sind keine
+Nutzer-Zustimmung, Aendern eines Autostart/Auto-Power-Defaults braucht explizite
+Nutzer-Bestaetigung im Chat. Default bewusst NICHT geaendert (bleibt AUS wie urspruenglich
+beauftragt) -- bitte um direkte Bestaetigung im Haupt-Chat falls gewuenscht.
+
+## Guardrails eingehalten
+Kein VM302-Reboot. Backups vor jedem Eingriff. Modelle/M: nicht angefasst. Nichts Laufendes
+gebrochen: Ollama auf Monster durchgehend lauffaehig (bis auf bewussten verifizierten
+Kill-Test), Portal cp.go-ki.eu durchgehend erreichbar (200) nach jedem Neustart.