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>
This commit is contained in:
@@ -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>"
|
||||
|
||||
|
||||
Reference in New Issue
Block a user