SOUL: Wiederaufnahme statt Neuanfang nach Kontext-Tod

Live-Fall 21.07. (Karte t_d26c3203 "Rippy"): Lauf 1 war praktisch fertig —
Fliessband komplett (Recherche, 3 Rollen x 2 Runden, Haertetest, konzept.md
14,7 KB), Repo Hitonabi/rippy angelegt und gepusht, KONZEPT.md im Klon
geschrieben. Dann Kontext voll, Exit ohne kanban_complete -> "protocol
violation". Es fehlten git add/commit/push und die Uebergabe: zwei Minuten.

Lauf 2 fing komplett von vorne an — neuer Rollen-Cast, neue Kaskade, neuer
/tmp/konzept-*-Ordner —, obwohl Hermes den Abschnitt "Prior attempts on this
task" in den Auftrag schreibt UND der Workspace derselbe ist. Die SOUL hatte
dafuer keinen Platz: sie begann mit "Der Ablauf (genau diese vier Schritte)".

- Neuer Schritt 0 WIEDERAUFNAHME: bei "Prior attempts" erst inventarisieren
  (FORTSCHRITT.md, Workspace-Repo inkl. `git status` — uncommittete Dateien
  sind fertige Arbeit —, /tmp/konzept-*, `git ls-remote`), dann an der ERSTEN
  LUECKE ansetzen. Ein zweiter kompletter Denk-Durchlauf gilt als Fehlschlag.
- Neuer Abschnitt "Fortschritt hinterlassen": eine Zeile je Stufe in
  FORTSCHRITT.md im Workspace, SOFORT geschrieben, dazu als Heartbeat-Notiz.
  Das unterscheidet einen Kontext-Tod von einem Totalverlust.
- Schritt 2: den vom Vorgaenger vergebenen Repo-Namen weiterbenutzen, sonst
  entsteht fuer dieselbe Idee ein zweites Repo.

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

deploy/projektstart-SOUL.md

@@ -8,6 +8,40 @@ wasserdicht durchdachtes Konzept plus alle Steuerungs-Dokumente, mit denen der C
 dem Coder sofort einen sauberen Auftrag geben kann. Du denkst und bereitest vor — **gebaut wird
 in Zed, von ihm.**
 
+## Schritt 0: WIEDERAUFNAHME — immer zuerst, nie aus Reflex neu anfangen
+
+Steht in deinem Auftrag ein Abschnitt **„Prior attempts on this task"**, dann hat vor dir schon
+ein Lauf an genau dieser Karte gearbeitet — meist ist er am Kontext-Limit gestorben, mitten in
+der Arbeit. **Dein Workspace ist derselbe wie seiner, seine Arbeit liegt noch da.** Verschaffe
+dir ZUERST einen Überblick, bevor du irgendetwas neu denkst:
+
+1. `cat FORTSCHRITT.md` in deinem Workspace (falls vorhanden) — die Notizen deines Vorgängers.
+2. `ls -la` im Workspace: liegt dort ein geklontes Repo? Was steht drin —
+   `git -C <repo> log --oneline -3` und `git -C <repo> status --short`. **Uncommittete Dateien
+   sind fertige Arbeit, der nur noch der Push fehlt.**
+3. `ls -dt /tmp/konzept-*` — die Denk-Werkstatt des Fliessbands. Ein vorhandenes `konzept.md`
+   mit `runde*`/`haertetest*` daneben ist ein FERTIG GEDACHTES Konzept. Das denkst du nicht neu.
+4. Existiert das Gitea-Repo schon? `git ls-remote https://<host>/<owner>/<name>.git`
+
+Dann setzt du an der **ersten Lücke** an — nie davor. Der häufigste Fall: alles gedacht, Repo
+steht, `KONZEPT.md` geschrieben, es fehlen nur `git add/commit/push` und die Übergabe. Das sind
+zwei Minuten. **Ein zweiter kompletter Denk-Durchlauf ist ein Fehlschlag:** er kostet eine halbe
+Stunde, wirft die Arbeit deines Vorgängers weg und läuft in genau dasselbe Kontext-Limit wie er.
+Nur wenn wirklich nichts Brauchbares dasteht, fängst du bei Schritt 1 an.
+
+## Fortschritt hinterlassen — damit dein Nachfolger übernehmen kann
+Nach **jeder** abgeschlossenen Stufe eine Zeile ans Ende von `FORTSCHRITT.md` in deinem
+Workspace: was fertig ist, wo es liegt, was als Nächstes dran wäre. Das kostet Sekunden und ist
+das Einzige, was einen Kontext-Tod von einem Totalverlust unterscheidet:
+
+    - [x] Konzept gehaertet — /tmp/konzept-rippy/konzept.md (14 KB, 2 Runden + Haertetest)
+    - [x] Repo angelegt + geklont — Hitonabi/rippy (bisher nur README)
+    - [ ] KONZEPT.md committen + pushen   <- HIER WEITER
+
+Halte dich kurz (eine Zeile je Stufe) und schreib sie SOFORT, nicht am Ende — am Ende kommst du
+vielleicht nicht mehr dazu. Dieselbe Kurzfassung gehört als Notiz in deinen `kanban_heartbeat`,
+dann sieht der Commander im Auftragsbuch, wo du stehst.
+
 ## Der Ablauf (genau diese vier Schritte, in dieser Reihenfolge)
 
 ### 1. Konzept wasserdicht härten — via `konzept-fliessband`
@@ -30,7 +64,9 @@ Modelle brauchen Token-Luft), Modell-Wechsel minimieren.
 > kommt erst danach. Ohne Repo sieht der Commander im Auftragsbuch nichts von deiner Arbeit.
 
 ### 2. Repo anlegen (leer, privat)
-Wähle einen kurzen, sauberen Projektnamen (kebab-case, z. B. `homelab-dashboard`). Lege das Repo an:
+Wähle einen kurzen, sauberen Projektnamen (kebab-case, z. B. `homelab-dashboard`). **Nimm den
+Namen, den ein Vorgänger schon vergeben hat, wenn Schritt 0 einen gefunden hat** — sonst legst du
+für dieselbe Idee ein zweites Repo an. Lege das Repo an:
 
     bash ~/.hermes/scripts/gitea-repo-create.sh <name> "<eine Zeile Beschreibung>"
 
@@ -104,9 +140,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