Autopilot

<Verwende_Wenn>

• Der Benutzer eine durchgängig autonome Ausführung von der Idee bis zum lauffähigen Code wünscht
• Der Benutzer „autopilot“, „auto pilot“, „autonomous“, „build me“, „create me“, „make me“, „full auto“, „handle it all“ oder „I want a/an...“ sagt
• Die Aufgabe mehrere Phasen erfordert: Planung, Codierung, Tests und Validierung
• Der Benutzer eine „hands-off“-Ausführung wünscht und bereit ist, das System bis zum Abschluss laufen zu lassen </Verwende_Wenn>

<Verwende_Nicht_Wenn>

• Der Benutzer Optionen erkunden oder brainstormen möchte – stattdessen die plan-Fertigkeit verwenden
• Der Benutzer „just explain“, „draft only“ oder „what would you suggest“ sagt – konversationell antworten
• Der Benutzer eine einzelne, fokussierte Codeänderung wünscht – ralph oder einen Ausführungsagenten delegieren
• Der Benutzer einen vorhandenen Plan überprüfen oder kritisieren möchte – plan --review verwenden
• Die Aufgabe eine schnelle Korrektur oder ein kleiner Fehler ist – direkte Ausführungsdelegation verwenden </Verwende_Nicht_Wenn>

<Warum_Dies_Existiert> Die meisten nicht-trivialen Softwareaufgaben erfordern koordinierte Phasen: Verstehen der Anforderungen, Entwerfen einer Lösung, paralleles Implementieren, Testen und Validieren der Qualität. Autopilot orchestriert all diese Phasen automatisch, sodass der Benutzer beschreiben kann, was er möchte, und lauffähigen Code erhält, ohne jeden Schritt selbst verwalten zu müssen. </Warum_Dies_Existiert>

<Workflow_Profile>

Benannte Stufenprofile (v1)

Ein konfiguriertes Profil nur mit /autopilot --workflow <name> <task> auswählen. Ein Profil ist ein von Autopilot verwalteter Stufenplan, kein Befehl, Modus, Plugin, Dateiname oder separate Zustandsidentität. Ohne --workflow behält Autopilot seinen ursprünglichen Lebenszyklus und sein ursprüngliches Verhalten bei.

Benannte Workflow-Profile erfordern in v1 Linux mit dem flock-Dienstprogramm, da ihre Transkript-Beweisgrenze eine Linux-„no-follow“-Dateideskriptor-Durchquerung verwendet und ihre wiederherstellbare Mutationssperre Kernel-Advisory-Locking verwendet. Nicht unterstützte Umgebungen lehnen die explizite --workflow-Aktivierung vor der Zustandsmutation ab; stattdessen den Legacy-Autopilot verwenden.

Profile werden in Projekt- oder Benutzer-JSONC als autopilot.workflows.<slug> konfiguriert. Jedes v1-Profil hat genau version: 1 und stages; keine anderen Profilschlüssel werden akzeptiert. Die einzig zulässigen Stufensequenzen sind:

{
  "autopilot": {
    "workflows": {
      "plan-build-qa": {
        "version": 1,
        "stages": ["ralplan", "execution", "qa"]
      }
    }
  }
}

[ralplan, execution]
[ralplan, execution, ralph]
[ralplan, execution, qa]
[ralplan, execution, ralph, qa]

ralplan erstellt den Plan, der von execution verbraucht wird; execution erstellt den implementierten Arbeitsbereich, der von ralph und qa benötigt wird. Daher sind weggelassene oder neu angeordnete Voraussetzungen, doppelte Stufen und nicht eingebaute Stufen ungültig. Profilnamen verwenden ^[a-z][a-z0-9-]{0,62}$, werden nur als validierte Metadaten betrachtet und können nicht mit eingebauten Stufen, Autopilot-/Modusnamen oder veralteten Aliasen kollidieren.

Benutzer- und Projektkonfigurationsquellen werden jeweils vor der Zusammenstellung validiert. Unterschiedliche Namen koexistieren; ein Projektprofil mit demselben Namen ersetzt das vollständige Benutzerprofil, anstatt es tief zusammenzuführen. Die Umgebungskonfiguration kann keine Profile definieren oder ersetzen.

Bei erfolgreicher Auswahl erstellt Autopilot atomar seinen vorhandenen sitzungsspezifischen Zustand mit einem unveränderlichen normalisierten Deskriptor und einer auf das ausgewählte Profil beschränkten Pipeline-Verfolgung. Der Deskriptor enthält den Workflow-Namen, die Profilversion, die kanonischen Stufen und einen deterministischen SHA-256-Profil-Hash; er schließt Aufgabentext und veränderlichen Fortschritt aus. Fortsetzen und Anhalten überprüfen diesen Hash und lehnen eine Nichtübereinstimmung ab, ohne die Konfiguration neu zu laden oder eine Stufenaufforderung auszugeben. Abbrechen, Fortsetzen, Bereinigen, Zustandsinspektion, HUD und Fortsetzung des Anhaltens bleiben Eigentum von Autopilot.

Die installierten Plugin- und eigenständig installierten Stop-Hooks schreiten nur fort, nachdem ein autorisierter Assistenten-Abschlussdatensatz für die aktive Stufe nach der anhaltenden Aktivierungstranskriptionsgrenze dieser Stufe erscheint. Sie binden Beweise an die Besitzersitzung und das begrenzte, nicht-symlink-Transkript; lehnen Benutzer-/Tool-/Lokalbefehlsausgabe und veraltete oder falsche Stufenbeweise ab; und verwenden „compare-before-write“-Tracking-Updates, sodass doppelte oder gleichzeitige Stop-Ereignisse genau einmal fortschreiten. Öffentlicher Zustand, HUD und Stop-Ausgabe zeigen nur sichere Workflow-Metadaten und Fortschritt, niemals die Aufgabe, Deskriptor-Interna, Transkriptreferenzen, Offsets oder Datensatz-Hashes.

V1-Vertagungen

V1 unterstützt keine stageModels, Modell-Routing, Anbieter- oder Rollenauswahl; Inline-/No-Spawn-Ausführung; dynamische Befehle, Modi oder Zustandsdateien; beliebige Stufen, Aufforderungen, Plugins, Verzweigungen, Schleifen, DAGs oder Callbacks; oder umgebungsdefinierte Profildefinitionen. Der separate „Custom-Skill-Inline-Array-Frontmatter-Parser-Mismatch“ wird ebenfalls vertagt. </Workflow_Profile>

2. Phase 1 - Planung: Einen Implementierungsplan aus dem Pflichtenheft erstellen

   • Wenn ein Ralplan-Konsensplan existiert: Überspringen – bereits in der 3-Stufen-Pipeline erledigt
   • Architekt (Opus): Plan erstellen (direkter Modus, kein Interview)
   • Kritiker (Opus): Plan validieren
   • Ausgabe: .omc/plans/autopilot-impl.md

3. Phase 2 - Ausführung: Den Plan mit Ausführungsagenten und Ralph-Persistenz bei Bedarf implementieren

   • Ausführer (Haiku): Einfache Aufgaben
   • Ausführer (Sonnet): Standardaufgaben
   • Ausführer (Opus): Komplexe Aufgaben
   • Unabhängige Aufgaben parallel ausführen

4. Phase 3 - Qualitätssicherung: Zyklisch wiederholen, bis alle Tests bestanden sind

   • Bauen, Linten, Testen, Fehler beheben
   • Bis zu 5 Zyklen wiederholen
   • Frühzeitig anhalten, wenn derselbe Fehler 3 Mal auftritt (weist auf ein grundlegendes Problem hin)

5. Phase 4 - Validierung: Mehrperspektivische Überprüfung parallel

   • Architekt: Funktionale Vollständigkeit
   • Sicherheitsprüfer: Schwachstellenprüfung
   • Code-Prüfer: Qualitätsprüfung
   • Alle müssen zustimmen; bei Ablehnung korrigieren und erneut validieren

6. Phase 5 - Bereinigung: Alle Zustandsdateien bei erfolgreichem Abschluss löschen

   • .omc/state/autopilot-state.json, ralph-state.json (sowie veraltete, zurückgezogene ultraqa-state.json/ultrawork-state.json, falls Legacy-Kopien existieren) entfernen
   • /oh-my-claudecode:cancel für sauberen Ausstieg ausführen

<Eskalations_Und_Stoppbedingungen>

• Anhalten und melden, wenn derselbe QA-Fehler über 3 Zyklen hinweg bestehen bleibt (grundlegendes Problem, das menschlichen Eingriff erfordert)
• Anhalten und melden, wenn die Validierung nach 3 erneuten Validierungsrunden weiterhin fehlschlägt
• Anhalten, wenn der Benutzer „stop“, „cancel“ oder „abort“ sagt
• Wenn die Anforderungen zu vage waren und die Erweiterung ein unklares Pflichtenheft erzeugt, eine Umleitung zu /deep-interview für sokratische Klärung anbieten oder pausieren und den Benutzer vor dem Fortfahren um Klärung bitten </Eskalations_Und_Stoppbedingungen>

Einschränkungen bei parallelen Sitzungen

• Multi-Repo-Workspace-Anker: eine .omc-workspace-Markierung im übergeordneten Verzeichnis platzieren, damit mehrere Sitzungen über Unter-Repos hinweg ein gemeinsames .omc/ teilen. Auflösungsreihenfolge: OMC_STATE_DIR > .omc-workspace > git > cwd. Siehe docs/REFERENCE.md.
• Sitzungs-ID-Quelle: OMC_SESSION_ID-Umgebungsvariable gewinnt in CLI-Kontexten; Hook-Nutzdaten data.session_id gewinnt in Hook-Kontexten.
• Plan-ID (falls zutreffend): Der Autopilot-Zustand ist sitzungsspezifisch. Zwei Autopiloten im selben Arbeitsbereich benötigen unterschiedliche Sitzungs-IDs.
• Paralleles Ergebnis: unterstützt (sitzungsspezifischer Zustand)

Optionale Einstellungen in .claude/omc.jsonc (Projekt) oder ~/.config/claude-omc/config.jsonc (Benutzer):

{
  "autopilot": {
    "maxIterations": 10,
    "maxQaCycles": 5,
    "maxValidationRounds": 3,
    "pauseAfterExpansion": false,
    "pauseAfterPlanning": false,
    "skipQa": false,
    "skipValidation": false,
    "execution": "solo"
  }
}

Um die Autopilot-Implementierung über die Tmux-CLI-Team-Laufzeit auszuführen und Cursor-Ausführer-Worker zu bevorzugen:

{
  "autopilot": {
    "execution": "team",
    "team": { "agentTypes": ["cursor"] }
  }
}

Mit dieser Konfiguration muss die Ausführungsstufe ausführende Arbeit über:

omc team 1:cursor "<implementation task>"

oder die Claude Code-Schrägstrich-Kompatibilitätsoberfläche starten:

/omc-teams 1:cursor "<implementation task>"

Einschränkungen:

• Cursor-Worker unterstützen Implementierungs- und Prüfer-ähnliche Teamrollen. critic, code-reviewer, security-reviewer und test-engineer-Worker müssen die strukturierte Entscheidungsdatei ausgeben, die vom Teamleiter verbraucht wird; die endgültige Genehmigung bleibt eine Verantwortung der Leitsitzung.
• Cursor erfordert, dass die cursor-agent-CLI installiert und authentifiziert ist. Wenn cursor-agent nicht verfügbar ist, diese Einrichtungsanforderung melden, anstatt stillschweigend auf eine reine Claude-Ausführung zurückzufallen.

Fortsetzen

Wenn Autopilot abgebrochen wurde oder fehlgeschlagen ist, /oh-my-claudecode:autopilot erneut ausführen, um von der Stelle fortzusetzen, an der es angehalten hat.

Best Practices für die Eingabe

1. Seien Sie spezifisch in Bezug auf die Domäne – „Buchhandlung“ nicht „Geschäft“
2. Erwähnen Sie die wichtigsten Funktionen – „mit CRUD“, „mit Authentifizierung“
3. Geben Sie Einschränkungen an – „mit TypeScript“, „mit PostgreSQL“
4. Lassen Sie es laufen – vermeiden Sie Unterbrechungen, es sei denn, es ist wirklich notwendig

Fehlerbehebung

In einer Phase feststecken? TODO-Liste auf blockierte Aufgaben prüfen, .omc/autopilot-state.json überprüfen oder abbrechen und fortsetzen.

QA-Zyklen erschöpft? Derselbe Fehler 3 Mal weist auf ein grundlegendes Problem hin. Das Fehlermuster überprüfen; manuelles Eingreifen kann erforderlich sein.

Validierung schlägt weiterhin fehl? Die spezifischen Probleme überprüfen. Die Anforderungen waren möglicherweise zu vage – abbrechen und mehr Details angeben.

Deep-Interview-Integration

Wenn Autopilot mit einer vagen Eingabe aufgerufen wird, kann Phase 0 zu /deep-interview für sokratische Klärung umleiten:

Benutzer: "autopilot build me something cool"
Autopilot: „Ihre Anfrage ist offen. Möchten Sie zuerst ein Deep Interview durchführen?“
  [Ja, zuerst Interview (Empfohlen)] [Nein, direkt erweitern]

Wenn ein Deep-Interview-Pflichtenheft bereits unter .omc/specs/deep-interview-*.md existiert, verwendet Autopilot es direkt als Ausgabe von Phase 0 (das Pflichtenheft wurde bereits mathematisch auf Klarheit validiert).

3-Stufen-Pipeline: deep-interview → ralplan → autopilot

Die empfohlene vollständige Pipeline verknüpft drei Qualitätstore:

/deep-interview "vague idea"
  → Sokratisches F&A → Pflichtenheft (Mehrdeutigkeit ≤ 20%)