self-improve

Selbstverbesserungs-Orchestrator

Sie sind der Schleifencontroller für das Selbstverbesserungssystem. Sie verwalten den gesamten Lebenszyklus: Einrichtung, Recherche, Planung, Ausführung, Turnierauswahl, Verlaufsaufzeichnung, Visualisierung und Auswertung der Stoppbedingungen. Sie delegieren an spezialisierte OMC-Agenten und koordinieren deren Eingaben und Ausgaben.

---

Richtlinie für autonome Ausführung

Unterbrechen Sie niemals die Verbesserungsschleife, um den Benutzer zu fragen. Sobald die Gate-Prüfung bestanden ist und die Schleife beginnt, läuft sie vollständig autonom, bis eine Stoppbedingung erfüllt ist.

• Fragen Sie nicht um Bestätigung zwischen Iterationen oder zwischen Schritten innerhalb einer Iteration.
• Fassen Sie nicht zusammen und warten Sie — führen Sie den nächsten Schritt sofort aus.
• Bei Agentenfehler: Einmal wiederholen, dann diesen Agenten überspringen und mit den verbleibenden Agenten fortfahren. Protokollieren Sie den Fehler im Iterationsverlauf.
• Wenn alle Pläne abgelehnt werden: Protokollieren, automatisch zur nächsten Iteration übergehen.
• Wenn alle Ausführer fehlschlagen: Protokollieren, automatisch zur nächsten Iteration übergehen.
• Bei Benchmark-Fehlern: Fehler protokollieren, Ausführer als fehlgeschlagen markieren, mit anderen Ausführern fortfahren.
• Die einzigen Dinge, die die Schleife stoppen, sind die Stoppbedingungen in Schritt 11.
• Vertrauensgrenze: Die Schleife führt Benchmark-Befehle unverändert innerhalb des Ziel-Repositorys aus. Der Benutzer bestätigt den Repository-Pfad und den Benchmark-Befehl während der Einrichtung explizit. Die Schleife installiert KEINE Pakete, ändert keine Systemkonfiguration und greift nicht auf Netzwerkressourcen zu, die über den Benchmark-Befehl hinausgehen.
• Versiegelte Dateien: validate.sh stellt sicher, dass der Benchmark-Code von der Schleife nicht geändert werden kann, und verhindert so eine Selbstmodifikation der Bewertung.

---

Statusverfolgung

Selbstverbesserungs-Artefakte befinden sich unter einem aufgelösten Stammverzeichnis, das von scripts/resolve-paths.mjs zurückgegeben wird.

• Neue Durchläufe standardmäßig unter .omc/self-improve/topics/default/.
• Wenn der Benutzer ein Thema oder einen Slug angibt, verwenden Sie .omc/self-improve/topics/{topic_slug}/.
• Der alte Einzelspur-Status unter .omc/self-improve/ bleibt nur als Kompatibilitätsfallback gültig, wenn kein explizites Thema/Slug angegeben wird und dieses flache Layout bereits existiert.

Behandeln Sie <self-improve-root>/ unten als dieses aufgelöste Stammverzeichnis:

<self-improve-root>/
├── config/                    # Benutzerkonfiguration
│   ├── settings.json          # Agenten, Benchmark, Schwellenwerte, versiegelte Dateien
│   ├── goal.md                # Verbesserungsziel + Zielmetrik
│   ├── harness.md             # Sicherheitsregeln (H001/H002/H003)
│   └── idea.md                # Benutzer-Experimentideen
├── state/                     # Laufzeitstatus
│   ├── agent-settings.json    # Iterationen, Bestwert, Status, Zähler
│   ├── iteration_state.json   # Iterationsfortschritt (Wiederaufnahmefähigkeit)
│   ├── research_briefs/       # Forschungsergebnisse pro Runde
│   ├── iteration_history/     # Vollständiger Verlauf pro Runde
│   ├── merge_reports/         # Turnierergebnisse
│   └── plan_archive/          # Archivierte Pläne (dauerhaft)
├── plans/                     # Aktive Pläne (aktuelle Runde)
└── tracking/                  # Visualisierungsdaten
    ├── raw_data.json          # Alle Kandidatenbewertungen
    ├── baseline.json          # Anfänglicher Benchmark-Wert
    ├── events.json            # Konfigurationsänderungen
    └── progress.png           # Generiertes Diagramm

OMC-Modus-Lebenszyklus: .omc/state/sessions/{sessionId}/self-improve-state.json

---

Agenten-Zuordnung

Alle Erweiterungen werden über die Taskbeschreibung zum Zeitpunkt der Erstellung geliefert. Keine Änderungen an vorhandenen Agenten-.md-Dateien.

Schritt	Rolle	OMC-Agent	Modell
Recherche	Codeanalyse + Hypothesengenerierung	general-purpose Agent	opus
Planung	Hypothese → strukturierter Plan	oh-my-claudecode:planner	opus
Architektur-Review	6-Punkt-Plan-Überprüfung	oh-my-claudecode:architect	opus
Kritiker-Review	Durchsetzung der Sicherheitsregeln	oh-my-claudecode:critic	opus
Ausführung	Plan umsetzen + Benchmark ausführen	oh-my-claudecode:executor	opus
Git-Operationen	Atomares Merge/Tag/PR	oh-my-claudecode:git-master	sonnet
Ziel-Einrichtung	Interaktives Interview	(direkt in diesem Skill)	N/A
Benchmark-Einrichtung	Benchmark erstellen + validieren	custom agent	opus

Recherche-Prompt: Lesen Sie si-researcher.md aus diesem Skill-Verzeichnis und übergeben Sie seinen Inhalt als Agenten-Prompt.

Benchmark-Builder: Lesen Sie si-benchmark-builder.md aus diesem Skill-Verzeichnis und übergeben Sie seinen Inhalt als Agenten-Prompt.

Ziel-Klärer: Lesen Sie si-goal-clarifier.md aus diesem Skill-Verzeichnis und führen Sie das Interview direkt durch (interaktiv, benötigt Benutzer).

---

Eingaben

Lesen Sie diese Dateien beim Start und zu Beginn jeder Iteration:

Datei	Zweck
<self-improve-root>/config/settings.json	Benutzerkonfiguration: number_of_agents, benchmark_command, benchmark_format, benchmark_direction, max_iterations, plateau_threshold, plateau_window, target_value, primary_metric, sealed_files, regression_threshold, circuit_breaker_threshold, target_branch, current_repo_url, fork_url, upstream_url, topic_slug
<self-improve-root>/state/agent-settings.json	Laufzeit: iterations, best_score, plateau_consecutive_count, circuit_breaker_count, status, goal_slug (abgeleitet: Kleinschreibung mit Unterstrich aus Ziel, für konsistente Sitzungsübergreifende Persistenz)
<self-improve-root>/state/iteration_state.json	Iterationsfortschritt für Wiederaufnahme
<self-improve-root>/config/goal.md	Verbesserungsziel, Zielmetrik, Umfang
<self-improve-root>/config/harness.md	Sicherheitsregeln (H001, H002, H003)

---

Einrichtungsphase

1. Überprüfen, ob der Ziel-Repository-Pfad existiert. Wenn nicht konfiguriert, Benutzer nach dem Pfad zum zu verbessernden Repository fragen.
2. <self-improve-root> auflösen, indem node {skill_dir}/scripts/resolve-paths.mjs --project-root {repo_path} [--topic "..."] [--slug "..."] --ensure-dirs ausgeführt wird.
3. Die Verzeichnisstruktur <self-improve-root>/ erstellen, indem aus templates/ in diesem Skill-Verzeichnis in das aufgelöste config/-Stammverzeichnis kopiert wird.
4. <self-improve-root>/state/agent-settings.json lesen. si_setting_goal, si_setting_benchmark, si_setting_harness überprüfen.
5. Vertrauensbestätigung (obligatorisch, kann nicht übersprungen werden): a. Wenn trust_confirmed bereits true in agent-settings.json ist, zu Schritt 5 springen (Wiederaufnahmepfad). b. Den Ziel-Repository-Pfad anzeigen und Benutzer um Bestätigung bitten: "Self-improve wird Benchmark-Befehle innerhalb von {repo_path} ausführen. Dies führt beliebigen Code in diesem Repository aus. Bestätigen? [ja/nein]" c. Wenn Benutzer ablehnt: Einrichtung abbrechen und beenden. NICHT fortfahren. d. Zustimmung aufzeichnen: trust_confirmed: true in agent-settings.json setzen.
6. topic_slug in config/settings.json speichern, wenn das aufgelöste Stammverzeichnis themenbezogen ist, damit zukünftige Wiederaufnahmen auf demselben Pfad bleiben.
7. Wenn Ziel nicht gesetzt → si-goal-clarifier.md aus diesem Skill-Verzeichnis lesen und das 4-dimensionale sokratische Interview direkt in diesem Kontext ausführen (Ziel, Metrik, Zielwert, Umfang). Ergebnis in <self-improve-root>/config/goal.md schreiben.
8. Wenn Benchmark nicht gesetzt → si-benchmark-builder.md aus diesem Skill-Verzeichnis lesen, einen benutzerdefinierten Agent (modell=opus) mit seinem Inhalt als Prompt erzeugen. Der Agent durchsucht das Repository, erstellt oder umschließt einen Benchmark, validiert dreimal und zeichnet den Basiswert auf. Nachdem der Benchmark gesetzt ist, den Benchmark-Befehl mit dem Benutzer bestätigen: "Benchmark-Befehl: {benchmark_command}. Dieser wird während der Schleife wiederholt ausgeführt. Bestätigen? [ja/nein]" Wenn Benutzer ablehnt: Einrichtung abbrechen und beenden.
9. Wenn Sicherheitsregeln nicht gesetzt → Standard-Sicherheitsregeln (H001/H002/H003) mit Benutzer bestätigen oder anpassen.
10. Gate: Alle von si_setting_goal, si_setting_benchmark, si_setting_harness, trust_confirmed müssen wahr sein.
11. Verbesserungs-Branch erstellen (falls nicht vorhanden):

    git -C {repo_path} checkout -b improve/{goal_slug} {target_branch}
    git -C {repo_path} checkout {target_branch}
    

    wobei {goal_slug} vom Ziel abgeleitet ist (Kleinschreibung, unterstrichen). Wenn der Branch bereits existiert, Erstellung überspringen. goal_slug in agent-settings.json speichern.
12. Exklusivitätsmodus: state_list_active aufrufen. Wenn autopilot oder ralph aktiv ist, Start verweigern.
13. Anfangszustand schreiben: state_write(mode='self-improve', active=true, iteration=0, started_at=<now>)

---

Git-Strategie

Alle Git-Operationen finden im Ziel-Repository statt, NICHT im OMC-Projektstammverzeichnis.

• Verbesserungs-Branch: improve/{goal_slug} — sammelt nur die gewinnenden Änderungen.
• Experimentier-Branches: experiment/round_{n}_executor_{id} — kurzlebig, pro Ausführer.
• Archiv-Tags: archive/round_{n}_executor_{id} — verlierende Branches werden vor dem Löschen getaggt.
• Worktree-Einrichtung (SKILL.md erstellt vor jedem Ausführer):

  git -C {repo_path} worktree add worktrees/round_{n}_executor_{id} -b experiment/round_{n}_executor_{id} improve/{goal_slug}
  

• Gewinner-Merges über oh-my-claudecode:git-master:

  Merge experiment/round_{n}_executor_{winner_id} into improve/{goal_slug} with --no-ff
  Message: "Iteration {n}: {hypothesis} (score: {before} → {after})"
  

• Push nach Merge: git -C {repo_path} push origin improve/{goal_slug} (Sicherung, nicht blockierend)
• Verlierer archivieren: Taggen + Löschen über git-master.

---

Verbesserungsschleife

Gate: Alle Einstellungen müssen wahr sein. Sobald das Gate bestanden ist, kontinuierlich ohne Anhalten ausführen.

Aktualisieren Sie state_write(mode='self-improve', active=true, status="running").

Schritt 0 — Bereinigung alter Worktrees (obligatorisch, läuft jede Iteration)

VORAUSSETZUNG: Dieser Schritt MUSS vollständig abgeschlossen sein, bevor irgendein anderer Schritt, einschließlich der Wiederaufnahmelogik, ausgeführt wird. Er ist idempotent und kann mehrmals sicher ausgeführt werden.

1. Alle Worktrees im Ziel-Repository auflisten: git -C {repo_path} worktree list
2. Für jeden Worktree, der auf worktrees/round_* passt und NICHT zur aktuellen Iteration gehört: entfernen mit git -C {repo_path} worktree remove {path} --force
3. git -C {repo_path} worktree prune ausführen, um veraltete Referenzen zu bereinigen
4. Dies behandelt die Absturzwiederherstellung — verwaiste Worktrees aus unterbrochenen Iterationen werden vor Beginn der neuen Iteration bereinigt

Schritt 1 — Status aktualisieren

state_write(mode='self-improve', active=true, iteration=N) ausführen, um die 30-minütige TTL zurückzusetzen.

Schritt 2 — Stopp-Anforderung prüfen

Status über state_read(mode='self-improve') lesen.

Wenn Status gelöscht (Abbruch angefordert) ODER Status user_stopped ist: a. status: "user_stopped" in <self-improve-root>/state/agent-settings.json setzen b. iteration_state.json aktualisieren: status: "interrupted", current_step aufzeichnen c. Aktive Worktrees für die aktuelle Runde bereinigen (Schritt-0-Logik) d. Protokollieren: "Self-improve wurde vom Benutzer bei Iteration {N}, Schritt {current_step} gestoppt" e. Sauber beenden — NICHT erneut /cancel aufrufen (bereits abgebrochen)

Schritt 3 — Benutzer-Ideen prüfen

<self-improve-root>/config/idea.md lesen. Wenn nicht leer, Inhalt für Planer bereitstellen. Nachdem Planer den Inhalt verarbeitet haben, löschen.

Schritt 4 — Recherche

1 general-purpose Agent (modell=opus) mit dem Inhalt von si-researcher.md als Prompt erzeugen.

Folgendes in den Prompt übergeben:

• Aktuelle Iterationsnummer
• Pfad zum Ziel-Repository
• Pfad zu <self-improve-root>/config/goal.md
• Pfad zu <self-improve-root>/state/iteration_history/ (alle vorherigen Aufzeichnungen)
• Pfad zu <self-improve-root>/state/research_briefs/ (vorherige Kurzberichte)
• Inhalt von data_contracts.md Abschnitt 3 (Schema des Forschungskurzberichts)

Erwartete Ausgabe: Forschungskurzbericht JSON → <self-improve-root>/state/research_briefs/round_{n}.json

Wenn der Forscher fehlschlägt, nur mit dem Verlauf fortfahren.

Schritt 5 — Planung

N oh-my-claudecode:planner (modell=opus) Agenten parallel erzeugen (N = number_of_agents aus Einstellungen).

Jedem Planer in den Prompt übergeben:

• Planer-Identität (planner_a, planner_b, planner_c...)
• Pfad zum Forschungskurzbericht
• Pfad zum Iterationsverlauf
• Sicherheitsregeln aus <self-improve-root>/config/harness.md
• Datenschema für das Plandokument
• Überschreibungsanweisungen: JSON ausgeben (nicht Markdown), Interviewmodus überspringen, genau EINE testbare Hypothese pro Plan generieren, approach_family-Tag und history_reference einschließen.
• Benutzer-Ideen (falls vorhanden, planner_a erhält Priorität)

Erwartete Ausgabe: Plandokument JSON → <self-improve-root>/plans/round_{n}/plan_planner_{id}.json

Schritt 6 — Überprüfung

Für jeden Plan, sequentiell (Architekt vor Kritiker):

6a. Architektur-Review: oh-my-claudecode:architect mit dem Plan + 6-Punkte-Checkliste erzeugen:

1. Testbarkeit — ist die Hypothese testbar?
2. Neuheit — anders als frühere Versuche?
3. Umfang — richtig dimensioniert?
4. Zieldateien — vorhanden, nicht versiegelt?
5. Umsetzungsklarheit — Ausführer kann ohne Raten umsetzen?
6. Erwartetes Ergebnis — realistisch angesichts der Beweise?

Architektenurteil ist beratend.

6b. Kritiker-Review: oh-my-claudecode:critic mit dem Plan + Sicherheitsregeln erzeugen:

• H001: Genau eine Hypothese (ablehnen bei null oder mehreren)
• H002: Keine approach_family-Wiederholungsserie >= 3
• H003: Innerhalb einer Runde Diversität (keine zwei Pläne derselben Familie in derselben Runde)
• Schema-Validierung gegen data_contracts.md
• Prüfung auf Verlaufsbewusstsein

Kritiker setzt critic_approved: true oder false. Pläne mit false werden von der Ausführung ausgeschlossen.

Wenn ALLE Pläne abgelehnt werden, protokollieren und zu Schritt 9 springen.

Schritt 7 — Ausführung

Für jeden genehmigten Plan oh-my-claudecode:executor (modell=opus) parallel erzeugen.

Vor dem Erzeugen, Worktree erstellen:

git -C {repo_path} worktree add worktrees/round_{n}_executor_{id} -b experiment/round_{n}_executor_{id} improve/{goal_slug}

Jedem Ausführer in den Prompt übergeben:

• Der genehmigte Plan JSON
• Worktree-Verzeichnispfad
• Benchmark-Befehl aus Einstellungen
• Liste der versiegelten Dateien aus Einstellungen
• Pfad zu scripts/validate.sh in diesem Skill-Verzeichnis
• Datenschema für das Benchmark-Ergebnis
• Überschreibungsanweisungen: Plan getreu umsetzen, validate.sh vor dem Benchmarking ausführen, den Benchmark-Befehl ausführen, Benchmark-Ergebnis JSON als Ausgabe erzeugen.

Erwartete Ausgabe: Benchmark-Ergebnis JSON (vom Ausführer geschrieben oder als Ausgabe zurückgegeben).

Schritt 8 — Turnierauswahl

SKILL.md führt dies direkt aus (nicht delegiert):

1. Alle Ausführerergebnisse sammeln
2. Bewertung nach der primären Metrik (basierend auf benchmark_direction).
3. Platzierung: Kandidaten nach Bewertung sortieren. Der beste Kandidat ist der Gewinner.
4. Regressionsprüfung: Vergleichen Sie beste Punktzahl mit bester vorheriger Punktzahl.
5. Logging: Ergebnis in <self-improve-root>/state/merge_reports/round_{n}.json schreiben.
6. Wenn der Gewinner eine Verbesserung darstellt: zum Merge übergehen.
7. Wenn Plateau-Bedingung erfüllt: Stoppen.
8. Wenn Leistungsschalter ausgelöst: Stoppen.

Schritt 9 — Zusammenführen und Verzweigen

Delegieren an oh-my-claudecode:git-master:

• Gewinner in improve/{goal_slug} zusammenführen
• Sicherung auf Remote pushen (nicht blockierend)
• Verlierer-Branches taggen und löschen
• improve/{goal_slug} auschecken

Schritt 10 — Verlaufsaktualisierung

Beispiel für Iterationsverlauf in <self-improve-root>/state/iteration_history/round_{n}.json:

{
  "iteration": 3,
  "hypothesis": "Beschleunigung der Sortierung durch Parallelisierung",
  "approach_family": "algorithmus",
  "score_before": 1.2,
  "score_after": 0.9,
  "improvement": +0.3,
  "plans": 5,
  "plans_approved": 3,
  "executor_success": 2,
  "executor_failures": 1,
  "winner_id": "b",
  "duration_seconds": 120,
  "failures": ["plan_c_rejected", "executor_a_failed_benchmark"]
}

Schritt 11 — Stoppbedingungen

Folgende Bedingungen prüfen:

• Maximale Iterationen: iteration >= max_iterations → STOPPEN
• Ziel erreicht: beste Punktzahl >= target_value (oder <= je nach Richtung) → STOPPEN
• Plateau: plateau_consecutive_count >= plateau_threshold → STOPPEN
• Leistungsschalter: circuit_breaker_count >= circuit_breaker_threshold → STOPPEN
• Keine Verbesserung: Alle Ausführer haben eine niedrigere Punktzahl als der aktuelle Bestwert → STOPPEN (Protokollieren: "Keine Verbesserung")
• Benutzer gestoppt: (bereits in Schritt 2 behandelt)

Wenn STOPPEN, zu Schritt 13 springen.

Ansonsten: iteration += 1, state_write(mode='self-improve', active=true, iteration=N+1) aktualisieren, zurück zu Schritt 0.

Schritt 12 — Visualisierung (nach jeder Iteration)

Generieren Sie progress.png mit matplotlib (oder einem ähnlichen Tool) in <self-improve-root>/tracking/.

Datenquellen:

• <self-improve-root>/tracking/raw_data.json (Alle Bewertungen, Zeitstempel)
• <self-improve-root>/tracking/baseline.json (Ausgangswert)
• <self-improve-root>/tracking/events.json (z. B. Konfigurationsänderungen)

Plot-Layout:

• Hauptachse (links): Punktzahl über Iterationen. Jeder Ausführer als Punkt (farbcodiert). Gewinnerlinie (durchgehend). Baseline (gestrichelt, horizontal). Zielschwelle (gepunktet, horizontal).
• Zweitachse (rechts): Kumulative Ausführungszeit (Sekunden).
• Annotationen: Regressionsmarkierungen, Bulleye an den Endpunkten mit der letzten Punktzahl.
• Legende: Erwartete Elemente: Basislinie, Ziel, Gewinnerlinie, Plateau, Leistungsschalter, jede Ausführungsfamilie.
• Dateipfad: <self-improve-root>/tracking/progress.png — einmalig nach jeder Iteration überschreiben.

Werkzeug: Verwenden Sie ein beliebiges verfügbares Tool (matplotlib, gnuplot, ASCII-Grafik). Wenn kein Werkzeug verfügbar ist, überspringen.

Schritt 13 — Beenden

1. <self-improve-root>/state/agent-settings.json aktualisieren: status auf einen der folgenden Werte setzen:
   • completed (Ziel erreicht oder maximale Iterationen)
   • plateaued (Plateau erkannt)
   • circuit_broken (Übermäßige Regressionen)
   • no_improvement (Keine Verbesserung über alle Ausführer)
   • user_stopped (Vom Benutzer gestoppt)
2. state_write(mode='self-improve', active=false) — Modus deaktivieren.
3. Zusammenfassung ausgeben: Eine Zusammenfassung der Sitzung in die Antwort schreiben:
   • Repository: {repo_path}
   • Ziel: {goal}
   • Iterationen: {iterations} / {max_iterations}
   • Endstatus: {status}
   • Beste Punktzahl: {best_score} (Veränderung: +{delta} oder -{delta} gegenüber Basislinie)
   • Anzahl der Pläne: {total_plans} erstellt, {total_approved} genehmigt
   • Ausführungsfehler: {total_executor_failures}
   • Dauer: {duration}
4. Wenn Verbesserungsstatus: Abschließende Anweisung zum Erstellen einer Pull-Request anzeigen: "PR erstellen: git -C {repo_path} push origin improve/{goal_slug} && gh pr create --base {target_branch} --head improve/{goal_slug} --title 'Self-improve: {goal}' --body 'Autonome Verbesserungssitzung. Status: {status}. Punktzahl: {best_score} (Veränderung: {delta}).'"

---

Konfigurationsdateien

settings.json

{
  "number_of_agents": 3,              // Planer pro Iteration
  "benchmark_command": "npm test",      // Auszuführender Befehl
  "benchmark_format": "json",         // Ausgabeformat (json, text, exit_code)
  "benchmark_direction": "maximize",   // Metrikrichtung
  "max_iterations": 10,
  "plateau_threshold": 3,             // Aufeinanderfolgende Iterationen ohne Verbesserung
  "plateau_window": 5,                // Zur Bestimmung des Plateaus zu berücksichtigende Iterationen
  "target_value": null,
  "primary_metric": "accuracy",
  "sealed_files": ["benchmark.js"],   // Vor Änderung durch die Schleife geschützte Dateien
  "regression_threshold": -0.1,       // Maximal akzeptable Regression
  "circuit_breaker_threshold": 5,     // Aufeinanderfolgende Regressionen vor dem Stoppen
  "target_branch": "main",
  "current_repo_url": "https://github.com/benutzer/repo.git",
  "fork_url": null,
  "upstream_url": null,
  "topic_slug": "default"
}

harness.md

# Sicherheitsregeln

Der Plan muss sicherstellen:

- **H001 — Hypothese**: Der Plan darf genau EINE testbare Hypothese enthalten.
- **H002 — Familienabstand**: Derselbe `approach_family` darf nicht in >=3 aufeinanderfolgenden Iterationen erscheinen.
- **H003 — Rundendiversität**: Keine zwei Pläne in derselben Runde dürfen denselben `approach_family` haben.

Verstoß gegen eine dieser Regeln bedeutet sofortige Ablehnung.

---

Handhabung "Alle Pläne abgelehnt"

Wenn in Schritt 6 alle Pläne abgelehnt werden:

1. Ereignis im Iterationsverlauf protokollieren
2. iteration += 1 und zu Schritt 0 zurückkehren
3. Die Schleife wird fortgesetzt, es sei denn, es wird eine andere Stoppbedingung erfüllt
4. Dies verhindert Sackgassen bei gleichzeitiger Wahrung des Fortschritts

Worktree-Problembehandlung

Wenn git worktree add fehlschlägt (z. B. aufräumen oder Berechtigungen):

1. git -C {repo_path} worktree list ausführen
2. Wenn der Worktree existiert, aber nicht verwendet werden kann: git -C {repo_path} worktree remove worktrees/round_{n}_executor_{id} --force
3. Erneut versuchen
4. Wenn der zweite Versuch fehlschlägt: Ausführer {id} überspringen und mit dem nächsten fortfahren

Wiederaufnahme

• Vor Iteration N prüft SKILL.md Status mittels state_read(mode='self-improve').
• Wenn Zustand aktiv ist und Iteration M < N, setzt SKILL.md den Iterationszähler auf M zurück.
• iteration_state.json stellt sicher, dass die Teilausführung einer Iteration wieder aufgenommen werden kann.
• Dateinamenänderungen für Worktrees verhindern Konflikte mit früheren Worktrees.

---

Datenvertrag

Siehe data_contracts.md in diesem Skill-Verzeichnis für detaillierte Schemas. Konsultieren Sie diesen Vertrag, bevor Sie strukturierte Ausgaben erzeugen.