ralph

[RALPH - ITERATION {{ITERATION}}/{{MAX}}]

Ihr vorheriger Versuch hat das Fertigstellungsversprechen nicht ausgegeben. Arbeiten Sie weiter an der Aufgabe.

<Verwendung_Wenn>

• Aufgabe erfordert garantierte Fertigstellung mit Überprüfung (nicht nur "geben Sie Ihr Bestes")
• Benutzer sagt "ralph", "nicht aufhören", "muss abgeschlossen sein", "beende dies" oder "mach weiter, bis es fertig ist"
• Arbeit kann mehrere Iterationen umfassen und benötigt Persistenz über Wiederholungen hinweg
• Aufgabe profitiert von strukturierter PRD-gesteuerter Ausführung mit Reviewer-Abnahme </Verwendung_Wenn>

<Nicht_Verwenden_Wenn>

• Benutzer möchte eine vollständig autonome Pipeline von der Idee zum Code – verwenden Sie stattdessen autopilot
• Benutzer möchte vor der Umsetzung erkunden oder planen – verwenden Sie stattdessen das plan-Skill
• Benutzer möchte eine schnelle einmalige Lösung – delegieren Sie direkt an einen Ausführungs-Agenten
• Benutzer möchte manuelle Kontrolle über den Abschluss – delegieren Sie direkt an einen Ausführungs-Agenten
• Benutzer hat bereits ein aktives Claude Code /goal und möchte nur, dass dieser native Ziel-Loop überwacht wird – übernehmen Sie das bestehende /goal explizit oder verwenden Sie nur Artefakt-basierte Ultragoal-Notizen, anstatt Ralph als konkurrierenden Persistenz-Loop zu starten </Nicht_Verwenden_Wenn>

<Warum_Das_Existiert> Komplexe Aufgaben scheitern oft stillschweigend: Teilimplementierungen werden als "erledigt" deklariert, Tests werden übersprungen, Randfälle werden vergessen. Ralph verhindert dies durch:

1. Strukturierung der Arbeit in diskrete User Stories mit testbaren Abnahmekriterien (prd.json)
2. Iteration Story für Story, bis jede einzelne bestanden ist
3. Nachverfolgung von Fortschritt und Erkenntnissen über Iterationen hinweg (progress.txt)
4. Erfordert eine frische Reviewer-Verifizierung anhand spezifischer Abnahmekriterien vor dem Abschluss </Warum_Das_Existiert>

<PRD_Modus> Standardmäßig arbeitet ralph im PRD-Modus. Ein Grundgerüst prd.json wird automatisch generiert, wenn ralph startet, falls keines vorhanden ist. Der aktive transiente PRD-Zustand ist sitzungsbezogen unter .omc/state/sessions/{sessionId}/prd.json, wenn eine Sitzungs-ID verfügbar ist; ältere projektweite prd.json / .omc/prd.json-Dateien werden als Start-Migrationsinputs gelesen.

Start-Gate: Ralph initialisiert und validiert prd.json immer beim Start. Legacy --no-prd-Text wird aus dem Prompt zur Rückwärtskompatibilität bereinigt, umgeht aber nicht mehr die PRD-Erstellung oder -Validierung.

Deslop-Opt-out: Wenn {{PROMPT}} --no-deslop enthält, überspringen Sie den obligatorischen Post-Review-Deslop-Durchlauf vollständig. Verwenden Sie dies nur, wenn der Bereinigungsdurchlauf absichtlich nicht zum Anwendungsbereich des Laufs gehört.

Reviewer-Auswahl: Übergeben Sie --critic=architect, --critic=critic, oder --critic=codex im Ralph-Prompt, um den Abschluss-Reviewer für diesen Lauf auszuwählen. architect bleibt der Standard.

Erkennung & Behandlung veralteter Zustände (#3669): Wenn ein PRD durch einen abnormalen/nicht Schritt-8-Ausstieg (Absturz, erzwungener Abbruch, Abbruch vor /oh-my-claudecode:cancel, Sitzungsende) unvollendet hinterlassen wird, zeigt Ralph beim Start/Fortsetzen, im Fortsetzungskontext und beim Sitzungsende eine explizite [STALE PRD WARNING] an – mit unvollständigen Zählern, Alter der letzten Bearbeitung und Signalen für veraltete Zeiger (PRD branchName zusammengeführt/verschwunden). Die Fertigstellung wird NIE aus dem PR-/Branch-/Merge-Status allein abgeleitet; der Git-Status ist nur ein Warnsignal. Eine Story wird NUR DANN automatisch auf passes: true abgestimmt, wenn der PRD konfigurierte beobachtbare Nachweise trägt und alle Prüfungen bestanden sind:

{
  "reconciliation": {
    "staleAfterMs": 7200000,
    "observableChecks": {
      "US-001": [
        { "type": "fileContains", "path": "src/landed.ts", "pattern": "LANDED_SYMBOL" },
        { "type": "gitGrep", "ref": "origin/dev", "pattern": "LANDED_SYMBOL" }
      ]
    }
  }
}

Prüfungstypen: fileExists / fileContains (Arbeitsbaum) und gitGrep (Inhalt an einem Ref – dies ist "verifiziert durch Inhalt auf dem Hauptzweig", niemals PR-Status). Stories ohne konfigurierte Prüfungen werden niemals automatisch markiert. Abgestimmte Stories behalten architectVerified: false und erfordern weiterhin Schritt-7-Reviewer-Verifizierung vor Schritt 8; jede Entscheidung wird an das prd-reconciliation.jsonl-Audit-Protokoll angehängt und in den Story-Notizen zusammengefasst. </PRD_Modus>

<PRD_Kriterienänderungen> Abnahmekriterien sind die Autorität für den PRD-Abschluss: Schritt 4 überprüft JEDES aktive Kriterium und Schritt 7 prüft anhand dieser. Ein Kriterium kann NUR durch den nachweiserhaltenden Änderungspfad aufhören zu gelten – niemals durch stillschweigende Löschung oder durch "Erfüllung" eines Kriteriums, dessen Messung widerlegt wurde.

Wenn die Implementierung ein Kriterium empirisch als falsch erweist (z.B. eine Anzahl im Einsatzbefehl ist falsch), ändern Sie es:

1. Ersetzen Sie das widerlegte Kriterium durch die gemessene Korrektur, oder ersetzen Sie es, wenn kein Ersatz gilt.
2. Zeichnen Sie die Änderung im criterionAmendments-Ledger der Story auf. Der ursprüngliche Kriteriumstext wird wörtlich beibehalten (niemals umgeschrieben oder gelöscht) zusammen mit:
   • kind: "replaced" oder "superseded"
   • original: das wörtliche widerlegte Kriterium (muss noch aktiv sein, wenn die Änderung aufgezeichnet wird)
   • replacement: das korrigierte Kriterium (nur für replaced)
   • reason: warum das Original nicht mehr gilt
   • evidence: die begrenzte Messung, die es widerlegt hat (z.B. "12 Setter aufgezählt, nicht 16: ...")
   • authority: wer die Änderung vorgenommen hat (verwenden Sie die ralph-Sitzungs-ID)
   • timestamp: ISO-8601-Zeitstempel
3. Die Fertigstellungsprüfung überprüft dann nur die AKTIVEN Kriterien; das Ledger führt das Audit-Trail, damit Prüfer sehen, warum das Original nicht mehr gilt.

Regeln:

• Eine Änderung ohne begrenzte Beweise, Grund, Autorität oder Zeitstempel ist ungültig – das PRD schlägt beim Lesen fehl, anstatt stillschweigend geschwächt zu werden.
• Ein Original, das noch aktiv ist, kann nicht geändert werden; ein Original kann nur einmal geändert werden.
• Programmatischer Pfad: amendCriterion(dir, storyId, { original, replacement, reason, evidence, authority }) und supersedeCriterion(dir, storyId, { original, reason, evidence, authority }).
• Manuell bearbeitete PRDs müssen dieselben Invarianten einhalten; ein widersprüchliches Ledger (Original noch aktiv oder zweimal geändert) macht das PRD ungültig.
• Dies ist kein Zielabschwächungs-Tool: Es existiert, damit "die Messung widerspricht dem Plan" zur Messung hin auflöst, ohne dass die Schleife ihren Halt verliert. </PRD_Kriterienänderungen>

<Ausführungsrichtlinie>

• Führen Sie unabhängige Agentenaufrufe gleichzeitig aus – warten Sie niemals sequentiell auf unabhängige Arbeit
• Verwenden Sie run_in_background: true für lange Operationen (Installationen, Builds, Test-Suites)
• Übergeben Sie den Parameter model immer explizit, wenn Sie an Agenten delegieren
• Lesen Sie docs/shared/agent-tiers.md vor der ersten Delegation, um die richtigen Agent-Stufen auszuwählen
• Liefern Sie die vollständige Implementierung: keine Umfangsreduzierung, keine teilweise Fertigstellung, keine Löschung von Tests, um sie zu bestehen
• Wenn ein Claude Code /goal erwähnt wird, behandeln Sie es nur als natives Sitzungs-Loop-Übergabe-/Nachweisquelle und verwenden Sie die deterministischen Konfliktrichtlinien refuse, adopt_existing und artifact_only anstelle von nicht-deterministischer Warnungsbehandlung. Ralph bleibt die OMC-Loop-Autorität für diesen Lauf; behaupten Sie nicht, dass /goal unabhängig Tests ausgeführt oder Dateien gelesen hat, und behandeln Sie den Evaluator-Erfolg nicht als Ersatz für die Ralph-Reviewer-Verifizierung. </Ausführungsrichtlinie>

2. Nächste Story auswählen: Lesen Sie die aktive PRD-Datei und wählen Sie die Story mit der höchsten Priorität, die passes: false hat. Dies ist Ihr aktueller Fokus.

3. Aktuelle Story implementieren:

   • Delegieren Sie an spezialisierte Agenten auf geeigneten Stufen:
     • Einfache Nachfragen: NIEDRIGE Stufe (Haiku) – "Was gibt diese Funktion zurück?"
     • Standardarbeit: MITTLERE Stufe (Sonnet) – "Fügen Sie dieser Module Fehlerbehandlung hinzu"
     • Komplexe Analyse: HOHE Stufe (Opus) – "Debuggen Sie diese Race-Condition"
   • Wenn Sie während der Implementierung Unteraufgaben entdecken, fügen Sie diese als neue Stories zur aktiven PRD-Datei hinzu
   • Führen Sie lange Operationen im Hintergrund aus: Builds, Installationen, Test-Suites verwenden run_in_background: true

4. Abnahmekriterien der aktuellen Story überprüfen: a. Überprüfen Sie für JEDES aktive Abnahmekriterium in der Story, ob es mit frischen Nachweisen erfüllt ist b. Führen Sie relevante Prüfungen durch (Test, Build, Lint, Typcheck) und lesen Sie die Ausgabe c. Wenn die Implementierung ein Kriterium empirisch als FALSCH erweist (die Messung widerlegt es), markieren Sie die Story NICHT als abgeschlossen und löschen oder schwächen Sie das Kriterium NICHT stillschweigend. Ändern Sie es stattdessen über den nachweiserhaltenden Pfad, der in <PRD_Kriterienänderungen> beschrieben ist: Ersetzen oder ersetzen Sie es in den aktiven Kriterien und fügen Sie das Original (wörtlich) mit kind, reason, evidence, authority und timestamp zum criterionAmendments-Ledger der Story hinzu. Fahren Sie dann mit der Überprüfung der verbleibenden AKTIVEN Kriterien fort d. Wenn ein aktives Kriterium NICHT erfüllt und NICHT geändert ist, arbeiten Sie weiter – markieren Sie die Story NICHT als abgeschlossen

5. Story als abgeschlossen markieren: a. Wenn ALLE aktiven Abnahmekriterien verifiziert sind, erstellen Sie einen revisionsgebundenen Fertigstellungsanspruch: Setzen Sie passes: true und setzen Sie completionCriteriaRevision auf die aktuelle governingCriteriaRevision der Story. Setzen Sie nicht architectVerified; die Reviewer-Zustimmung bindet dies separat. b. Zeichnen Sie den Fortschritt in progress.txt auf: was implementiert wurde, geänderte Dateien, Erkenntnisse für zukünftige Iterationen c. Fügen Sie alle entdeckten Codebase-Muster zu progress.txt hinzu

6. PRD-Abschluss prüfen: a. Lesen Sie die aktive PRD-Datei – sind ALLE Stories mit passes: true markiert (ohne ungeprüfte aktive Kriterien)? b. Wenn NICHT alle abgeschlossen sind, kehren Sie zu Schritt 2 zurück (nächste Story auswählen) c. Wenn ALLE abgeschlossen sind, fahren Sie mit Schritt 7 fort (Architekt-Überprüfung)

7. Reviewer-Verifizierung (gestaffelt, gegen Abnahmekriterien):

   • <5 Dateien, <100 Zeilen mit vollständigen Tests: STANDARD-Stufe Minimum (architect-medium / Sonnet)
   • Standard-Änderungen: STANDARD-Stufe (architect-medium / Sonnet)

   • 20 Dateien oder Sicherheits-/Architekturänderungen: GRÜNDLICHE Stufe (architect / Opus)

   • Wenn --critic=critic, verwenden Sie den Claude critic-Agenten für den Genehmigungsdurchlauf
   • Wenn --critic=codex, führen Sie omc ask codex --agent-prompt critic "..." für den Genehmigungsdurchlauf aus. Der Codex-Critic-Prompt MUSS enthalten:
     1. Die vollständige Liste der Abnahmekriterien aus prd.json zur Überprüfung
     2. Eine Anweisung zu bewerten, ob die Implementierung OPTIMAL ist – nicht nur korrekt, sondern ob es einen sinnvoll besseren Ansatz (einfacher, schneller, wartbarer) gibt, den die Implementierung verpasst hat
     3. Eine Anweisung, den gesamten Code im Zusammenhang mit den Änderungen zu überprüfen (Aufrufer, Aufgerufene, gemeinsam genutzte Typen, benachbarte Module), nicht nur die direkt geänderten Dateien
     4. Die Liste der während der ralph-Sitzung geänderten Dateien für den Kontext
   • Ralph-Basis: immer mindestens STANDARD, selbst für kleine Änderungen
   • Der ausgewählte Reviewer überprüft anhand der SPEZIFISCHEN Abnahmekriterien aus prd.json, nicht vage "ist es fertig?"
   • Bei GENEHMIGUNG: Fahren Sie sofort im selben Zug mit Schritt 7.5 fort. Halten Sie NICHT an, um das Urteil dem Benutzer zu melden – die Meldung erfolgt nur in Schritt 8 (/oh-my-claudecode:cancel) oder bei Ablehnung (Schritt 9). Die Behandlung eines genehmigten Urteils als Meldepunkt ist ein Anti-Pattern des höflichen Anhaltens.

7.5 Obligatorischer Deslop-Durchlauf (wird nach Schritt-7-Genehmigung bedingungslos ausgeführt, es sei denn, {{PROMPT}} enthält --no-deslop):

• Rufen Sie das ai-slop-cleaner-Skill über das Skill-Tool auf: Skill("oh-my-claudecode:ai-slop-cleaner") – es ist ein Skill, kein Agent. Wenn Sie es fälschlicherweise über Task(subagent_type="oh-my-claudecode:ai-slop-cleaner") aufrufen, lehnt der PreToolUse-Hook von OMC den Aufruf mit dem korrekten Skill-Tool-Bezeichner ab; ersetzen Sie es nicht durch einen ähnlich benannten Agenten. Führen Sie es im Standardmodus (nicht --review) für die Dateien aus, die nur während der aktuellen Ralph-Sitzung geändert wurden.

• Halten Sie den Umfang auf den von Ralph geänderten Dateisatz beschränkt; erweitern Sie den Bereinigungsdurchlauf nicht auf nicht verwandte Dateien.

• Wenn der Reviewer die Implementierung genehmigt hat, der Deslop-Durchlauf jedoch Folgeänderungen einführt, behalten Sie diese Änderungen innerhalb desselben geänderten Dateiumfangs bei, bevor Sie fortfahren.

  7.6 Regression-Neuüberprüfung:

• Führen Sie nach dem Deslop-Durchlauf alle relevanten Tests, Build- und Lint-Prüfungen für die Ralph-Sitzung erneut aus.

• Lesen Sie die Ausgabe und bestätigen Sie, dass der Post-Deslop-Regressionslauf tatsächlich bestanden wird.

• Wenn die Regression fehlschlägt, machen Sie die Bereinigungsänderungen rückgängig oder ...

… [für die Übersetzung gekürzt]