diff --git a/burst-compute/w44-a40-guard-step1-2026-07-23.md b/burst-compute/w44-a40-guard-step1-2026-07-23.md
new file mode 100644
index 0000000..be6aaad
--- /dev/null
+++ b/burst-compute/w44-a40-guard-step1-2026-07-23.md
@@ -0,0 +1,29 @@
+# W44 Burst-Compute: A40-Einzelinstanz-Garde, Schritt 1 (2026-07-23)
+
+**Datei:** `/opt/gpu1-status/app.py` (VM201, 100.114.24.89), Portal-Service `gpu1-portal.service`
+
+## Was gebaut wurde
+- Neues Modul-Level-Lock `_A40_GUARD` (threading.Lock, additiv, default aktiv) direkt nach `KASM_VM`/`HUB_BRAIN`-Konstanten (Zeile ~10636 vor Edit).
+- `_a40_guard_try_acquire(job_label)` / `_a40_guard_release()` — einfache Belegt/Frei-Semaphore.
+- Neuer Endpoint `GET /api/burst/a40-guard/status` (auth-gated wie alle anderen `/api/*`-Routen).
+- Erster geguardeter Call-Site: `POST /api/hermes/generate/video` (`hermes_generate_video`) — gibt bei belegter A40 sofort `{"status":"busy",...}` zurueck statt den Job durchzureichen; released im `finally`-Block auch bei Exception.
+
+## Warum nur dieser eine Endpoint (Schritt 1 von geplanten 4)
+Kleinschrittig wie von Koordinator gefordert: erst EIN Call-Site guarden + verifizieren, dann in Folgeschritten CPU-Offload, Burst-Dispatcher, Portal-Toggle. Weitere Heavy-Endpoints (ACE-Step, ggf. weitere Wan2.2-Pfade) folgen in Schritt 2+, sobald dieser Baustein bestaetigt sauber laeuft.
+
+## Ablauf (Portal-Skill, vollstaendig durchlaufen)
+1. Backup: `/opt/gpu1-status/app.py.bak-w44-garde-20260723_175843` (md5 `50fb440aa4ea55e0f49fbc42809e59d4`)
+2. Fresh-Read vor Edit: md5 von Backup == md5 der Live-Datei zum Zeitpunkt des Edits (kein Drift durch andere Worker)
+3. Edit: reiner unique-String-Replace (kein Zeilennummern-Patch), zwei Anker (`KASM_VM = "100.104.5.57"...` und die komplette `hermes_generate_video`-Funktion), je `assert count==1` vor dem Replace
+4. `python3 -m py_compile app.py` → OK
+5. Testinstanz Port 9092 (`venv/bin/uvicorn app:app --port 9092`) → `GET /` = 200, `GET /api/burst/a40-guard/status` = 401 (korrekt auth-gated, Route existiert), danach sauber gestoppt (`fuser -k 9092/tcp`)
+6. **Erste `systemctl restart` wurde durch einen 502-Gateway-Abbruch der SSH-Session unterbrochen — Prozess lief mit ALTER PID/altem Code weiter (Startzeit 16:10, vor dem Edit).** Erkannt durch PID/Startzeit-Check, sofort korrigiert:
+7. Sauberer `systemctl restart gpu1-portal.service` #2 → neue PID 195211, Startzeit 18:04:47 (nach dem Edit)
+8. Verifiziert: `GET http://127.0.0.1:9090/api/burst/a40-guard/status` = 401 (Route jetzt live), `GET /` = 200
+9. `https://cp.go-ki.eu/` von aussen = 200
+
+## Sicherheitsaspekt der laufenden Arbeit
+Der aktuell laufende Video-Build rendert direkt gegen ComfyUI `:8188` (VM302), NICHT ueber `app.py`/`hermes_generate_video`. Der neue Guard betrifft ausschliesslich den `:8190`-Pfad (separates Video-Pipeline-Dashboard) und wurde durch die zwei `systemctl restart` NICHT unterbrochen — kein VM302-Reboot, kein Eingriff in den 8188-Prozess.
+
+## Lehre fuer die naechsten Schritte
+Nach JEDEM `systemctl restart` MainPID + Startzeit gegenpruefen (`systemctl show ... -p MainPID` + `ps -o lstart`), nicht nur `is-active` — ein abgebrochener SSH-Call durch die 502-Flakiness des Hub-Gateways kann einen Restart-Befehl verschlucken, ohne dass `is-active` das anzeigt (alter Prozess ist ja noch aktiv).