Ein autonomer Loop vom PRD-Ziel bis zum Release-Gate. Master Plan = PRD + Gates, ein verifizierbarer Commit pro Iteration, DECISIONS-Warteschlange für menschliche Entscheide und die Disziplin gegen 24/7-Drift.

Teil 10 — PRD sagte, was zu bauen ist. Teil 11 — Release gates sagte, wann es gebaut ist.

Dieser Beitrag handelt davon, was die Lücke zwischen den beiden füllt — ohne dass der Betreiber an der Tastatur sitzt.

Ralph. Der autonome Loop, der eine PRD mit Gates nimmt und den Weg selbstständig geht, jeweils ein verifizierter Commit nach dem anderen. Er arbeitet im Hintergrund. Er pusht, wenn er kann. Er stellt Entscheidungen in eine Warteschlange, wenn er nicht kann. Der Betreiber wacht auf, führt einen Slash-Befehl aus, trifft ein paar Entscheidungen und geht zurück zu allem anderen, das er gerade tat. Das System hat die Arbeit gemacht.

Dies ist der dritte Beitrag in der Workflow-Erweiterung der Serie und derjenige, in dem alles davor zusammenwirkt. Persona engt den Entscheidungsraum ein. Gedächtnis behält das Warum. Skills verdichten die Verben. Hooks feuern, was vergessen würde. Multi-Agent teilt die Last. Verifikation sperrt „fertig". Token-Ökonomie schützt das Signal. PRDs halten Absicht. Release gates setzen Ankunft durch. Ralph führt das ganze Arrangement im Takt aus.

0. Die Prämisse — Autonomie ist nicht „dem Agenten mehr vertrauen"

Eine schlechte Version von Autonomie ist „lass den Agenten machen, was er will, und hoffe". Das kollabiert aus demselben Grund, aus dem der PRD-lose Workflow in Teil 10 kollabiert — die Absicht des Betreibers hat keinen dauerhaften Ort zum Leben, und der Agent endet damit, zu improvisieren.

Eine funktionierende Version von Autonomie ist das Gegenteil. Der Betreiber schreibt die PRD. Der Betreiber schreibt die Gates. Der Ermessensspielraum des Agenten ist scharf begrenzt — er kann alles tun, was nicht ändert, was das System ist, und er kann nichts tun, was das ändert. Innerhalb dieser Grenze läuft der Agent ohne Aufsicht. Außerhalb stoppt der Agent und wartet.

Autonomie funktioniert, wenn die Absicht in Code fixiert ist und die Arbeit das ist, was delegiert wird.

Ralph ist die Harness, die diese Unterscheidung operativ real macht.

1. Was Ralph tatsächlich ist

Ralph ist zwei Skripte und ein Ordner.

ralph-code.sh — führt eine Phase nach der anderen aus. Liest eine PRD-N. Wählt den nächsten [ ]-Punkt. Implementiert ihn. Führt verify aus. Committet, wenn verify besteht. Wiederholt.
ralph-orchestrator.sh — führt viele Phasen hintereinander aus. Liest einen Master Plan. Ruft für jede Phase ralph-code.sh auf. Zwischen Phasen prüft das Gate. Entweder das Gate passieren (Auto), oder stoppen und eine Entscheidung in die Warteschlange stellen (Manual).
ralph-loop/ — ein Ordner pro Projekt, der die PRDs, den Master Plan, das Fortschrittsprotokoll, die Blocker-Liste und — am wichtigsten — die DECISIONS-Warteschlange hält.

Der Kindprozess ist kein langlebiger Agent. Es ist eine frische Sitzung pro Iteration. Jede Iteration ist ein Punkt: implementieren, verifizieren, committen. Die nächste Iteration startet von einer sauberen Tafel und liest die PRD erneut, um den nächsten [ ] zu finden. Drift kann nicht über Iterationen hinweg akkumulieren, weil es keinen geteilten Kontext gibt, in dem gedriftet werden könnte.

Das Eltern — der Orchestrator — implementiert nichts. Seine einzige Aufgabe ist Gate-Durchsetzung. Nach jeder Phase fragt er „hat das Gate bestanden?" Wenn ja, voranschreiten. Wenn nein, stoppen und in die Warteschlange schreiben.

2. Der Master Plan — PRD und Gates verschmolzen

Ein Master Plan ist das Dokument, das Ralph liest. Es ist geformt wie eine PRD mit den Gates pro Phase inline:

Approved-By: lead, 2026-05-18

Phase P1 — Privacy and compliance scrub
  PRD: ralph-loop/PRD-P1.md
  Auto-Gate: pnpm verify:privacy && pnpm build && pnpm lint
  Manual-Gate: lead approves privacy policy text
  Items: 12

Phase P2 — Asset SHA-256 enforcement
  PRD: ralph-loop/PRD-P2.md
  Auto-Gate: pnpm verify:assets && pnpm build
  Manual-Gate: —
  Items: 7

Phase P3 — i18n locale expansion (4 new locales)
  PRD: ralph-loop/PRD-P3.md
  Auto-Gate: pnpm build && pnpm verify:i18n
  Manual-Gate: lead approves machine-translated content for each locale
  Items: 24

...

Drei Eigenschaften zählen.

Approved-By: ist eine Pflichtzeile. Der Orchestrator weigert sich zu starten ohne sie. Wenn der Lead den Master Plan nicht unterzeichnet hat, läuft Ralph nicht.

Jede Phase hat ihre PRD vorgeneriert. Nicht „der Orchestrator generiert PRD-P3, wenn er dort ankommt" — PRD-P3.md existiert zur Startzeit, geschrieben von Alice aus dem Master Plan. Vorgenerierung ist ein Drift-Sicherheitsnetz: eine in-flight PRD-P3 hat keinen Betreiber-Review.

Auto-Gate und Manual-Gate sind pro Phase benannt. Auto ist ein Shell-Befehl. Manual ist ein benannter Genehmiger und was er genehmigt. Keine Phase schreitet voran ohne dass ihr Gate besteht.

3. Wie der Loop tatsächlich läuft

Eine vereinfachte Spur einer Iteration von ralph-code.sh:

1. cd to worktree
2. read PRD-N.md
3. find the first item marked [ ]
4. if no [ ] items remain → exit (ALL DONE)
5. start a fresh Claude Code session
6. system prompt: "implement exactly this one item, then stop"
7. child writes code
8. child runs verify (the script named in the PRD)
9. if verify passes:
     - child commits with message including item ID
     - parent re-runs verify (defense in depth)
     - if parent verify also passes → mark [ ] as [x], continue
     - if parent verify fails → revert, write to BLOCKERS, continue with next item
10. if verify fails:
     - log to BLOCKERS
     - retry once
     - if still failing → mark as blocked, continue with next item
11. if BLOCKERS reaches threshold (default 3 per phase) → abort
12. loop back to step 2

Schlüssel-Eigenschaften dieses Loops und warum jede so geformt ist, wie sie ist.

Ein Punkt pro Iteration. Das Kind kann nicht „während ich schon dabei bin, lass mich auch noch ... reparieren". Der system prompt begrenzt es explizit auf eine PRD-Zeile. Das stoppt Scope-Drift auf der Stelle.

Frische Sitzung pro Iteration. Kein mitgeschleppter Kontext zwischen Punkten. Der nächste Punkt liest die PRD frisch. Wenn der vorherige Punkt subtile schlechte Annahmen hinterließ, propagieren sie sich nicht.

Eltern verifiziert erneut. Das verify des Kindes ist eine Prüfung. Das verify der Eltern ist dasselbe Skript, erneut ausgeführt außerhalb der Sitzung des Kindes, auf dem committeten Zustand. Wenn sie nicht übereinstimmen, ist die Behauptung des Kindes falsch und der Commit wird zurückgenommen. So überlebt das System eine halluzinierte „verify passed"-Zeile.

Blocker-Obergrenze. Nach N Blockern in einer Phase bricht die Phase ab. Der Betreiber inspiziert, was immer wieder blockierte, und behebt entweder die Wurzelursache oder schreibt die PRD um. Ralph läuft nicht für immer in dieselbe Wand.

4. Der Orchestrator — Phasengrenzen sind, wo Menschen leben

ralph-code.sh handhabt Punkte innerhalb einer Phase. ralph-orchestrator.sh handhabt den Übergang zwischen Phasen.

Nachdem das ralph-code.sh einer Phase mit ALL DONE beendet hat:

1. parent runs the phase's Auto-Gate command
2. if Auto-Gate fails:
     - log to DECISIONS as "Auto-Gate failed, see verify output"
     - stop the orchestrator
3. if Auto-Gate passes and there's no Manual-Gate:
     - mark phase [x] in ORCHESTRATOR-STATE.md
     - advance to next phase
4. if Auto-Gate passes and there IS a Manual-Gate:
     - log to DECISIONS as "Manual-Gate awaits: <approver> approves <thing>"
     - stop the orchestrator
5. every 5 phases (regardless of state):
     - force a DECISIONS checkpoint
     - stop the orchestrator
     - operator runs /btw to confirm direction

Drei beabsichtigte Stopps, jeder entspricht einer anderen rein menschlichen Verantwortung.

Auto-Gate fehlgeschlagen. Das ist ein technisches Ereignis, aber die Interpretation ist menschlich. War das verify-Skript falsch? War die Spec falsch? Hat sich die Welt verändert? Der Betreiber entscheidet. Der Orchestrator versucht es nicht für immer erneut.

Manual-Gate erreicht. Das ist die explizite Übergabe. Der Lead genehmigt die Privacy Policy, oder den Seed-Content, oder die Wahl des OAuth-Scopes. Diese Zeile lässt sich nicht automatisieren, also stoppt der Orchestrator an der Tür.

Erzwungener Checkpoint. Alle fünf Phasen, auch wenn nichts schiefgegangen ist, stoppt der Orchestrator und fragt nach Richtung. Das ist ein Drift-Sicherheitsnetz. Der mit Abstand härteste Fehlermodus langlaufender Autonomie ist „alles hat funktioniert, ging aber in die falsche Richtung", und die einzige bekannte Gegenmaßnahme ist periodischer menschlicher Review im festen Rhythmus.

5. Die DECISIONS-Warteschlange — Quarantäne für „ich brauche einen Menschen"

Drei Dateien sammeln sich in ralph-loop/ an:

Datei	Was sie hält	Trigger	Wie sie verarbeitet wird
`PROGRESS.md`	Eine Zeile pro Iteration, Erfolg oder Fehlschlag	jede Iter	nur anhängen, nur Audit
`BLOCKERS.md`	Technische Fehler, die der Agent nicht lösen konnte	verify fällt zweimal etc.	zählt zur Abbruchsschwelle
`DECISIONS.md`	Dinge, die nur ein Mensch entscheiden kann	Optionswahlen, Security/DB, Dep-Adds	der Betreiber verarbeitet mit `/btw`

Die Disziplin, die das funktionieren lässt, liegt darin, wie ein Kind eine Situation klassifiziert, die es nicht lösen kann.

child encounters a situation it does not know how to handle:
  ├── "I think I know what to do, but the spec is silent" → BLOCKER
  ├── "There are two reasonable choices and only the lead can pick" → DECISION
  └── "This requires a new dependency / security review / public API change" → DECISION

Im Zweifel: als DECISION klassifizieren, nicht als BLOCKER. Eine Entscheidung als Blocker fehl-klassifizieren verschwendet nur Iterationen. Einen Blocker als Entscheidung fehl-klassifizieren weckt den Betreiber unnötig, korrumpiert aber den Codebase nicht. Die Asymmetrie ist der Punkt.

Ein PRD-Punkt mit Status [?] (Entscheidung ausstehend) wird von Ralph übersprungen. Der Loop läuft auf [ ]-Punkten weiter. Wenn alles, was getan werden kann, getan ist, bleiben nur [?]-Punkte — und der Loop beendet sich natürlich und signalisiert „der Betreiber ist dran."

6. `/btw` — die Betreiber-Seite des Loops

Auf der Betreiber-Seite ist die gesamte Interaktion ein Slash-Befehl.

/btw

Was er tut:

Liest ralph-loop/DECISIONS.md in jedem bekannten Projekt
Sortiert ausstehende Entscheidungen nach Priorität (Security/DB +10 Gewicht, Wartezeit-Gewicht)
Präsentiert sie dem Betreiber als gebündelte Frage mit Optionen
Für jede Antwort:
- Verschiebt die Entscheidung von „ausstehend" zu „gelöst" mit der Antwort und einem Zeitstempel
- In der PRD wird [?] zurück auf [ ] umgelegt und der Inhalt der Zeile gemäß der Entscheidung aktualisiert
- Committet mit der Nachricht [Decision] D-NNN R0N: <summary>
Fragt den Betreiber, ob Ralph auf den betroffenen Phasen neu gestartet werden soll

Das mentale Modell des Betreibers ist — ich beantworte Fragen, ich führe keine Arbeit aus. Der Orchestrator handhabte die eigentliche Arbeit. Der Orchestrator traf auf eine Sache, die nur ich entscheiden kann. Ich entscheide. Der Orchestrator macht weiter.

Eine realitätsnahe Interaktion:

operator (morning): /btw

Alice: 3 decisions pending across 2 projects.

  Project A (waiting 14 h):
    D-007  Phase P5 — Use Resend or Postmark for transactional email?
           Spec is silent. Pricing favors Resend, deliverability favors Postmark.
  Project A (waiting 14 h):
    D-008  Phase P6 — Add `zod` dependency for runtime validation?
           Spec did not anticipate a runtime validator. Two alternatives:
           (a) zod (~14 kB)
           (b) hand-rolled validators

  Project B (waiting 2 h):
    D-002  Phase P2 — Manual-Gate: lead approves machine-translated content?
           24 files, 4 locales × 6 categories. Sample diff attached.

operator: D-007: Resend. D-008: zod. D-002: approved.

Alice: Recorded all three. Project A Phase P5 resumed.
       Project B Phase P2 advanced to P3. Project B continuing.

Dieses Gespräch ist die gesamte Interaktion. Der Betreiber hat keinen Code geschrieben. Der Betreiber hat keinen Build ausgeführt. Der Betreiber traf drei Entscheidungen in unter einer Minute. Ralph erledigte den Rest vor dem Gespräch und macht den Rest danach weiter.

7. Wenn Ralph das falsche Werkzeug ist

Ralph ist kein universeller Hammer. Er ist gut in einer Art Arbeit und schlecht in einer anderen.

Gute Passungen.

Viele ähnliche Punkte, jeder verifizierbar. (Polish-Pass auf 36 MDX-Dateien anwenden. Boilerplate für 48 Lens-Varianten generieren. 24 Aufrufstellen einer umbenannten Funktion refaktorieren.)
Generierte Tests oder Docs, die das verify-Skript prüfen kann.
Lint- oder Format- oder Type-Strict-Batches, die eine große Oberfläche in eine Richtung bewegen.

Schlechte Passungen.

Architektur-Entscheidungen. (Der ganze Punkt ist, dass Entscheidungen in DECISIONS gehen, aber wenn jeder Punkt eine Entscheidung ist, leistet Ralph keine Arbeit und produziert nur Warteschlangen-Rauschen.)
Security- oder DB-Schema-Änderungen. Beide berühren Invarianten, die Ralph nicht voll verifizieren kann, und beide haben Fehlermodi, in denen „passed" gefährlich falsch ist.
Public-API-Änderungen. Das verify-Skript kann bestätigen, dass die lokale Änderung funktioniert, kann aber nicht bestätigen, dass nachgelagerte Verbraucher es noch tun.
Alles mit einer neuen Abhängigkeit. Immer eine Entscheidung.

Im Zweifel die Heuristik: wäre ich damit einverstanden, dass dieser Commit landet, während ich schlafe? Wenn ja, Ralph. Wenn nein, in einer normalen Sitzung mit anwesendem Betreiber machen.

8. Sicherheitsgeländer — was Autonomie davon abhält, zum Brand zu werden

Mehrere Geländer wirken zusammen, um Ralph sicher laufen zu lassen.

Worktree-Isolation. Ralph läuft in einem git worktree, niemals auf main. Der Worktree ist auf einem dedizierten Branch (ralph/master-plan oder ralph/{phase}). Der Betreiber kann den gesamten Branch jederzeit inspizieren und verwerfen.

Approved-By-Zeile. Der Orchestrator weigert sich, einen Master Plan ohne Approved-By: lead, <date> zu starten. Die Unterschrift des Betreibers wird mechanisch durchgesetzt — nicht „der Lead sagte im Chat okay", sondern ein String in der Datei, den der Orchestrator parst.

Verify ist der einzige Pfad zum Commit. Das Kind kann nicht committen, ohne dass das verify-Skript mit 0 beendet. Das Eltern führt verify auf dem committeten Zustand erneut aus. Zwei unabhängige Durchläufe desselben Gates.

Begrenzter Scope pro Iteration. Der system prompt des Kindes sagt „implementiere genau diese eine PRD-Zeile und stoppe dann." Scope-Creep auf Iterations-Ebene ist mechanisch blockiert.

Phasenabbruch-Schwellen. Nach N Blockern in einer Phase bricht die Phase ab. Nach M Blockern über den gesamten Plan hinweg bricht der Orchestrator ab. Das System steigt aus, wenn der Weg unerkennbar wird, statt durchzubrechen.

Erzwungene menschliche Checkpoints. Alle 5 Phasen stoppt der Orchestrator und fragt. Auch wenn nichts sichtbar schiefgegangen ist, bestätigt der Betreiber die Richtung. Lange unbeaufsichtigte Läufe ohne menschlichen Review sind der gefährlichste Modus; dieses Geländer schließt ihn aus.

Entscheidungs-Quarantäne. Dinge, die nur der Betreiber entscheiden kann, werden zu DECISIONS geleitet und von Ralph übersprungen. Der Agent rät nie bei einer Frage, die einem Menschen gehört.

Kosten-Deckel. Kosten-Monitoring ist die Verantwortung des Betreibers (ein externes Werkzeug wie ccusage). Eine Phase, die unerwartet teuer wird, ist auch ein Signal, dass etwas gedriftet ist und einen Check wert ist.

9. Ein Prinzip

Die ganze Form von Ralph kollabiert auf eine Zeile.

„Alles, was die Absicht des Betreibers als Routine behandeln würde, lass das System selbstständig gehen. Alles, was die Absicht des Betreibers als Entscheidung behandeln würde, in die Warteschlange stellen und warten."

Und diese Zeile ist auch dort, wo diese Drei-Beitrag-Erweiterung endet — und wo die Serie selbst zur Ruhe kommt.

Teil 1 — Why Alice fragte: wie akkumuliere ich meine Absicht, damit die KI sie nicht verliert?

Die ersten neun Beiträge antworteten: eine Persona aufbauen, die die Grenze der Absicht zieht, ein Gedächtnis, das sie über Sitzungen hinweg hält, Skills, die ihre Verben verdichten, Hooks, die feuern, was vergessen würde, Multi-Agent, damit kein einzelner Kontext alles tragen muss, Verifikation, um „fertig" zu sperren, Token-Ökonomie, um die Signal-Slots zu schützen, und Sitzungsprotokolle, damit jeder Tag am selben Ort aufleuchtet und am selben Ort herunterfährt.

Die letzten drei Beiträge antworteten: eine PRD schreiben, damit die Absicht die Sitzung überlebt. Release gates schreiben, damit „fertig" zur Tatsache wird. Einen Loop laufen lassen, damit der Weg zwischen Absicht und Ankunft sich selbst geht, während der Betreiber nur die Entscheidungen handhabt, die seine zu treffen sind.

Wenn alle zwölf Teile an ihrem Platz sind, hört der Betreiber auf, die Person zu sein, die die Arbeit tut, und wird zur Person, die entscheidet, welche Arbeit es wert ist, getan zu werden. Die Absicht — das ursprüngliche, nicht reduzierbare Ding aus Teil 1 — ist endlich dort, wo sie sein sollte: oben im Stack, entscheidend, während alles darunter die Arbeit trägt.

Das ist die Version des Arbeitens mit KI, auf die ich in den letzten Monaten hingearbeitet habe. Das Werkzeug kann Claude sein, kann Codex sein, kann sein, was als nächstes kommt. Die zwölf Entscheidungen oben hängen nicht vom Werkzeug ab. Sie warten auf jeden, der beschließt, seinen eigenen Kollaborateur aufzubauen, statt einen zu benutzen.

Wenn diese Serie die Zeit bis zu diesen Entscheidungen auch nur ein wenig verkürzt hat — ist die Absicht des Betreibers dort gelandet, wo sie hinsollte.

12. Ralph loop — der Weg von der PRD zum Release, ohne den Betreiber gegangen