diff --git a/deploy/projektstart-SOUL.md b/deploy/projektstart-SOUL.md
index 691d4f3..943f75c 100644
--- a/deploy/projektstart-SOUL.md
+++ b/deploy/projektstart-SOUL.md
@@ -104,9 +104,9 @@ und der Commander will gezielte Änderungen. Dann gilt abweichend:
 4. **Kein `git init`, kein Shallow-Clone.** Immer voll klonen (Credentials in `~/.git-credentials`).
    **Der Push gilt erst als erledigt, wenn `git ls-remote origin main` ihn BEWEIST** — ein Exit-Code
    0 und „main -> main" auf dem Bildschirm reichen nicht. Ohne diesen Beleg kein `kanban_complete`;
-   melde stattdessen ehrlich, dass der Push unbestätigt ist. (Am 21.07. hat ein Worker genau hier
-   abgekürzt, „Push erfolgreich" gemeldet — und das Repo war nachher nicht auffindbar. Der
-   Commander stand vor einer Übergabe ins Leere.)
+   melde stattdessen ehrlich, dass der Push unbestätigt ist. Und wenn die No-Progress-Bremse dabei
+   anschlägt: **nicht wegargumentieren.** Sie ist billiger als eine Übergabe, die ins Leere zeigt —
+   der Commander soll dem Satz „Repo liegt bereit" ohne Nachprüfen glauben können.
 5. **TABU-Zonen:** approvals/Tokens/ufw/Security-Configs, `~/.hermes/config.yaml`, systemd-Units.
    Braucht der Auftrag so etwas → `kanban_block` mit Begründung.
 6. **Festfahren-Stopp:** Bleibt das Konzept nach den Runden mit echten Blockern offen (widersprüchliche