Cancel

Cancel-Fähigkeit

Intelligente Abbrecherkennung, die den aktiven OMC-Modus erkennt und abbricht.

Die Cancel-Fähigkeit ist die Standardmethode, um jeden OMC-Modus zu beenden und zu verlassen. Wenn der Stop-Hook feststellt, dass die Arbeit abgeschlossen ist, weist er das LLM an, diese Fähigkeit zur ordnungsgemäßen Zustandsbereinigung aufzurufen. Falls Cancel fehlschlägt oder unterbrochen wird, wiederholen Sie es mit dem --force-Flag oder warten Sie als letzten Ausweg auf den 2-stündigen Staleness-Timeout.

Was sie tut

Erkennt automatisch, welcher Modus aktiv ist, und bricht ihn ab:

• Autopilot: Stoppt den Workflow, behält den Fortschritt für eine Wiederaufnahme
• Ralph: Stoppt die Persistenzschleife
• Legacy Ultrawork-Zustand: Nur Bereinigungsentfernung für aktualisierte Installationen; es ist kein aktiver Workflow
• UltraQA (eingestellt): Es verbleibt kein Live-Workflow; löscht veraltete ultraqa-state.json vor Version 5.0.0, falls vorhanden
• Ultragoal: Löscht den sitzungsbezogenen Ultragoal-Laufzeit-Guard (.omc/state/.../ultragoal-state.json), sodass die PreToolUse /goal-Durchsetzung und die Stop-Verstärkung freigegeben werden. Dauerhafte .omc/ultragoal/-Plan-/Ledger-Artefakte bleiben erhalten.
• Swarm: Stoppt den koordinierten Agentenschwarm, gibt beanspruchte Aufgaben frei
• Ultrapilot: Stoppt parallele Autopilot-Worker
• Pipeline: Stoppt die sequentielle Agenten-Pipeline
• Team: Fordert die Abschaltung von allen Teammitgliedern über die aktive Team-/Konversationsoberfläche an, wartet auf Antworten/Timeouts, löscht den OMC-Teamzustand, löscht den verknüpften Ralph, falls vorhanden. Claude Code 2.1.178+ hat kein TeamDelete.
• Team+Ralph (verknüpft): Bricht zuerst das Team ab (sanfte Abschaltung), löscht dann den Ralph-Zustand. Das Abbrechen von Ralph bei Verknüpfung bricht ebenfalls zuerst das Team ab.

Verwendung

/oh-my-claudecode:cancel

Oder sagen Sie: "cancelomc", "stopomc"

Wichtig: Verzögerte Tool-Handhabung

Die Zustandsverwaltungstools (state_clear, state_read, state_write, state_list_active, state_get_status) können von Claude Code als verzögerte Tools registriert werden. Bevor Sie irgendein Zustandstool aufrufen, MÜSSEN Sie zuerst alle über ToolSearch laden:

ToolSearch(query="select:mcp__plugin_oh-my-claudecode_t__state_clear,mcp__plugin_oh-my-claudecode_t__state_read,mcp__plugin_oh-my-claudecode_t__state_write,mcp__plugin_oh-my-claudecode_t__state_list_active,mcp__plugin_oh-my-claudecode_t__state_get_status")

Wenn state_clear nicht verfügbar ist oder fehlschlägt, verwenden Sie diesen Bash-Fallback als Notfall- Ausweg aus der Stop-Hook-Schleife. Dies ist KEIN vollständiger Ersatz für den Cancel-Ablauf — es entfernt nur Zustandsdateien, um die Sitzung zu entsperren. Verknüpfte aktive Modi (z. B. Autopilot→Ralph) müssen separat bereinigt werden, indem der Fallback einmal pro Modus ausgeführt wird.

Ersetzen Sie MODE durch den spezifischen Modus (z. B. ralplan, ralph, ultrawork, ultragoal).

WARNUNG: Verwenden Sie diesen Fallback NICHT für autopilot oder omc-teams. Autopilot erfordert state_write(active=false), um Wiederaufnahmedaten zu erhalten. omc-teams erfordert eine tmux-Sitzungsbereinigung, die nicht allein durch Dateilöschung erfolgen kann.

# Fallback: Direkte Dateientfernung, wenn das state_clear MCP-Tool nicht verfügbar ist
SESSION_ID="${CLAUDE_SESSION_ID:-${CLAUDECODE_SESSION_ID:-}}"
REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || { d="$PWD"; while [ "$d" != "/" ] && [ ! -d "$d/.omc" ]; do d="$(dirname "$d")"; done; echo "$d"; })"

# Plattformübergreifendes SHA-256 (macOS: shasum, Linux: sha256sum)
sha256portable() { printf '%s' "$1" | (sha256sum 2>/dev/null || shasum -a 256) | cut -c1-16; }

# Zustandsverzeichnis auflösen (unterstützt OMC_STATE_DIR zentrale Speicherung)
if [ -n "${OMC_STATE_DIR:-}" ]; then
  # Spiegelt getProjectIdentifier() aus worktree-paths.ts
  SOURCE="$(git remote get-url origin 2>/dev/null || echo "$REPO_ROOT")"
  HASH="$(sha256portable "$SOURCE")"
  DIR_NAME="$(basename "$REPO_ROOT" | sed 's/[^a-zA-Z0-9_-]/_/g')"
  OMC_STATE="$OMC_STATE_DIR/${DIR_NAME}-${HASH}/state"
  [ ! -d "$OMC_STATE" ] && { echo "ERROR: State dir not found at $OMC_STATE" >&2; exit 1; }
elif [ "$REPO_ROOT" != "/" ] && [ -d "$REPO_ROOT/.omc" ]; then
  OMC_STATE="$REPO_ROOT/.omc/state"
else
  echo "ERROR: Could not locate .omc state directory" >&2
  exit 1
fi
MODE="ralplan"  # <-- durch den Zielmodus ersetzen

# Sitzungsbezogenen Zustand für den spezifischen Modus löschen
if [ -n "$SESSION_ID" ] && [ -d "$OMC_STATE/sessions/$SESSION_ID" ]; then
  rm -f "$OMC_STATE/sessions/$SESSION_ID/${MODE}-state.json"
  rm -f "$OMC_STATE/sessions/$SESSION_ID/${MODE}-stop-breaker.json"
  rm -f "$OMC_STATE/sessions/$SESSION_ID/skill-active-state.json"
  # Abbruchsignal schreiben, damit der Stop-Hook den laufenden Abbruch erkennt
  NOW_ISO="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"
  EXPIRES_ISO="$(date -u -d "+30 seconds" +"%Y-%m-%dT%H:%M:%SZ" 2>/dev/null || python3 - <<'PY'\nfrom datetime import datetime, timedelta, timezone\nprint((datetime.now(timezone.utc) + timedelta(seconds=30)).strftime('%Y-%m-%dT%H:%M:%SZ'))\nPY\n)"
  printf '{"active":true,"requested_at":"%s","expires_at":"%s","mode":"%s","source":"bash_fallback"}' \
    "$NOW_ISO" "$EXPIRES_ISO" "$MODE" > "$OMC_STATE/sessions/$SESSION_ID/cancel-signal-state.json"
fi

# Legacy-Zustand nur löschen, wenn keine Sitzungs-ID vorhanden ist (vermeidet das Löschen des Zustands einer anderen Sitzung)
if [ -z "$SESSION_ID" ]; then
  rm -f "$OMC_STATE/${MODE}-state.json"
fi

Automatische Erkennung

/oh-my-claudecode:cancel folgt dem sitzungsbewussten Zustandsvertrag:

• Standardmäßig untersucht der Befehl die aktuelle Sitzung über state_list_active und state_get_status, navigiert durch .omc/state/sessions/{sessionId}/…, um herauszufinden, welcher Modus aktiv ist.
• Wenn eine Sitzungs-ID bereitgestellt oder bereits bekannt ist, ist dieser sitzungsbezogene Pfad maßgeblich. Legacy-Dateien in .omc/state/*.json werden nur als Kompatibilitätsfallback konsultiert, wenn die Sitzungs-ID fehlt oder leer ist.
• Swarm ist ein gemeinsam genutzter SQLite/Marker-Modus (.omc/state/swarm.db / .omc/state/swarm-active.marker) und nicht sitzungsbezogen.
• Der standardmäßige Bereinigungsablauf ruft state_clear mit der Sitzungs-ID auf, um nur die passenden Sitzungsdateien zu entfernen; Modi bleiben an ihre ursprüngliche Sitzung gebunden.

Aktive Modi werden weiterhin in der Abhängigkeitsreihenfolge abgebrochen:

1. Autopilot (beinhaltet verknüpften Ralph und die Bereinigung des eingestellten Zustands)
2. Ralph
3. Legacy Ultrawork/UltraQA-Zustandsbereinigung
4. Ultragoal (eigenständiger Laufzeit-Guard — state_clear(mode="ultragoal"); bewahrt dauerhafte .omc/ultragoal/-Artefakte)
5. Swarm (eigenständig)
6. Ultrapilot (eigenständig)
7. Pipeline (eigenständig)
8. Team (Claude Code nativ)
9. OMC Teams (tmux CLI-Worker)
10. Plan Consensus (eigenständig)
11. Self-Improve (eigenständig — Zustand löschen, verwaiste Worktrees bereinigen, iteration_state für Wiederaufnahme bewahren, Status auf "user_stopped" im aufgelösten <self-improve-root>/state/agent-settings.json setzen; neue Läufe verwenden .omc/self-improve/topics/<topic-slug>/, wobei flaches .omc/self-improve/ nur für Legacy-Einzelspur-Wiederaufnahmen beibehalten wird)

Alles mit Gewalt löschen

Verwenden Sie --force oder --all, wenn Sie jede Sitzung plus Legacy-Artefakte löschen müssen, z. B. um das Arbeitsverzeichnis vollständig zurückzusetzen.

/oh-my-claudecode:cancel --force

/oh-my-claudecode:cancel --all

Schritte im Hintergrund:

1. state_list_active zählt .omc/state/sessions/{sessionId}/… auf, um jede bekannte Sitzung zu finden.
2. state_clear wird einmal pro Sitzung ausgeführt, um die Dateien dieser Sitzung zu löschen.
3. Ein globales state_clear ohne session_id entfernt Legacy-Dateien unter .omc/state/*.json, .omc/state/swarm*.db und Kompatibilitätsartefakte (siehe Liste).
4. Team-Artefakte (~/.claude/teams/*/, ~/.claude/tasks/*/, .omc/state/team-state.json) werden nach bestem Wissen als Teil des Legacy-Fallbacks gelöscht.
   • Das Abbrechen für native Teams beeinträchtigt NICHT den omc-teams-Zustand und umgekehrt.

Jeder state_clear-Befehl beachtet das session_id-Argument, sodass selbst der Force-Modus zuerst die sitzungsbewussten Pfade verwendet, bevor Legacy-Dateien gelöscht werden.

Legacy-Kompatibilitätsliste (wird nur unter --force/--all entfernt):

• .omc/state/autopilot-state.json
• .omc/state/ralph-state.json
• .omc/state/ralph-plan-state.json
• .omc/state/ralph-verification.json
• .omc/state/ultrawork-state.json
• .omc/state/ultraqa-state.json
• .omc/state/swarm.db
• .omc/state/swarm.db-wal
• .omc/state/swarm.db-shm
• .omc/state/swarm-active.marker
• .omc/state/swarm-tasks.db
• .omc/state/ultrapilot-state.json
• .omc/state/ultrapilot-ownership.json
• .omc/state/pipeline-state.json
• .omc/state/omc-teams-state.json
• .omc/state/plan-consensus.json
• .omc/state/ralplan-state.json
• .omc/state/boulder.json
• .omc/state/hud-state.json
• .omc/state/subagent-tracking.json
• .omc/state/subagent-tracker.lock
• .omc/state/rate-limit-daemon.pid
• .omc/state/rate-limit-daemon.log
• .omc/state/checkpoints/ (Verzeichnis)
• .omc/state/sessions/ (Bereinigung leerer Verzeichnisse nach dem Löschen von Sitzungen)

Implementierungsschritte

Wenn Sie diese Fähigkeit aufrufen:

1. Argumente parsen

# Prüfen auf --force oder --all Flags
FORCE_MODE=false
if [[ "$*" == *"--force"* ]] || [[ "$*" == *"--all"* ]]; then
  FORCE_MODE=true
fi

2. Aktive Modi erkennen

Die Fähigkeit verlässt sich nun auf den sitzungsbewussten Zustandsvertrag anstelle von fest codierten Dateipfaden:

1. Rufen Sie state_list_active auf, um .omc/state/sessions/{sessionId}/… aufzulisten und jede aktive Sitzung zu entdecken.
2. Rufen Sie für jede Sitzungs-ID state_get_status auf, um zu erfahren, welcher aktive Modus läuft und ob abhängige Modi vorhanden sind; behandeln Sie jeden Ultrawork-Datensatz nur als Bereinigungseingabe für eingestellte Funktionen.
3. Wenn eine session_id an /oh-my-claudecode:cancel übergeben wurde, überspringen Sie den Legacy-Fallback vollständig und arbeiten Sie ausschließlich innerhalb dieses Sitzungspfads; konsultieren Sie andernfalls Legacy-Dateien in .omc/state/*.json nur, wenn die Zustandstools keine aktive Sitzung melden. Swarm bleibt ein gemeinsam genutzter SQLite/Marker-Modus außerhalb des Sitzungsbereichs.
4. Jede Abbruchlogik in diesem Dokument spiegelt die Abhängigkeitsreihenfolge wider, die über die Zustandstools entdeckt wurde (Autopilot → Ralph → …).

3A. Force-Modus (wenn --force oder --all)

Verwenden Sie den Force-Modus, um jede Sitzung plus Legacy-Artefakte über state_clear zu löschen. Die direkte Dateientfernung ist für die Legacy-Bereinigung reserviert, wenn die Zustandstools keine aktiven Sitzungen melden.

3B. Intelligente Abbrecherkennung (Standard)

Wenn Team aktiv ist (implizites Claude Code Team)

Teams werden über den OMC-Teamzustand erkannt, nicht über entfernte Claude Code ~/.claude/teams-Konfigurationsverzeichnisse:

# Prüfen auf aktiven OMC-Teamzustand
state_read(mode="team")

Zwei-Phasen-Abbruchprotokoll:

Phase 1: Sanfte Abschaltung

Für den aktiven OMC-Teamzustand:
  1. Lesen Sie team_name und Worker-Labels aus dem OMC-Zustand/Übergaben/Aufgaben-Buchhaltung
  2. Für jedes aktive Teammitglied:
     a. Fragen Sie das genannte Teammitglied über die aktive Konversations-/Team-Messaging-Oberfläche oder benachrichtigen Sie es
     b. Warten Sie bis zu 15 Sekunden auf eine shutdown_response
     c. Wenn Antwort empfangen: Markieren Sie das Mitglied als bestätigt
     d. Wenn Zeitüberschreitung: Markieren Sie das Mitglied als nicht reagierend, fahren Sie mit dem nächsten fort
  3. Protokollieren: "Graceful pass: X/Y members responded"

Phase 2: Abgleich

Nach der sanften Phase:
  1. Warten Sie 5 weitere Sekunden auf nicht reagierende Teammitglieder, die möglicherweise noch verarbeiten
  2. Zeichnen Sie alle verbleibenden nicht reagierenden Teammitglieder im Abbruchbericht auf
  3. Rufen Sie nicht TeamDelete auf; Claude Code 2.1.178+ hat die teamweise native Bereinigung entfernt

OMC-Zustandsbereinigung:

  1. Teamzustand löschen: state_clear(mode="team")
  2. Auf verknüpften Ralph prüfen: state_read(mode="ralph") — wenn linked_team wahr ist:
     a. Ralph-Zustand löschen: state_clear(mode="ralph")
  3. Führen Sie nur für Legacy-`omc team` / `/omc-teams`-Worker eine OMC tmux/CLI-Waisen-Suche durch (siehe unten)
  4. Strukturierten Abbruchbericht ausgeben

Waisenerkennung (Nach der Bereinigung):

Für Legacy-OMC tmux/CLI-Worker-Läufe überprüfen Sie, ob noch Worker-Prozesse vorhanden sind:

node "${CLAUDE_PLUGIN_ROOT}/scripts/cleanup-orphans.mjs" --team-name "{team_name}"

Der Waisenscanner:

1. Prüft ps aux (Unix) oder tasklist (Windows) auf OMC-Worker-Prozesse mit --team-name, das mit dem bereinigten Team übereinstimmt
2. Sendet SIGTERM, wartet 5s, sendet SIGKILL, falls noch aktiv
3. Meldet Bereinigungsergebnisse als JSON

Verwenden Sie --dry-run, um zu inspizieren, ohne zu beenden. Der Scanner kann mehrmals sicher ausgeführt werden.

Strukturierter Abbruchbericht:

Team "{team_name}" wurde abgebrochen:
  - Signalisierte Mitglieder: N
  - Empfangene Antworten: M
  - Nicht reagierend: K (Namen auflisten, falls vorhanden)
  - OMC-Zustand gelöscht: ja/nein
  - Manuelle Bereinigung erforderlich: ja/nein
    Pfad: OMC-Teamzustand / tmux-Worker-Prozesse, falls vorhanden

Implementierungshinweis: Die Cancel-Fähigkeit wird vom LLM ausgeführt, nicht als Bash-Skript. Wenn Sie ein aktives Team erkennen:

1. Lesen Sie state_read(mode="team"), um das aktive OMC-Team zu finden
2. Identifizieren Sie aktive benannte Teammitglieder aus Zustand, Übergaben oder Aufgaben-Buchhaltung
3. Fragen Sie für jedes Teammitglied das genannte Teammitglied über die aktive Konversations-/Team-Messaging-Oberfläche oder benachrichtigen Sie es
4. Warten Sie kurz auf Abschaltantworten (15s Zeitüberschreitung pro Mitglied)
5. Zeichnen Sie nicht reagierende Teammitglieder nach einer Wartezeit für den Abgleich auf
6. Löschen Sie den Teamzustand: state_clear(mode="team", session_id)
7. Melden Sie dem Benutzer eine strukturierte Zusammenfassung

Wenn Autopilot aktiv ist

Autopilot handhabt seine eigene primäre Bereinigung zuerst: benannte Workflows entfernen zusätzlich nur ihren sitzungseigenen verschachtelten ralplan-Erzwingungszustand vor dem verknüpften Ralph und der Bereinigung des eingestellten UltraQA.

1. Lesen Sie den Autopilot-Zustand über state_read(mode="autopilot", session_id), um den genauen aktuellen Lauf zu erfassen, einschließlich workflowRunId, falls vorhanden.
2. Halten Sie diesen genauen Lauf mit der engen Mutation state_write(mode="autopilot", session_id, active=false, state={workflowRunId: "<exact run id>"}) an. Spielen Sie das gelesene Zustand nicht zurück oder kopieren Sie es nicht. Auf Linux mit flock validiert das Tool den gehaltenen Lauf und die Workflow-Integrität unter seiner Mutationssperre neu, bevor nur active auf false gesetzt wird; es bewahrt Workflow, Pipeline-Verfolgung und Aufgabenidentität. target_state_sha256 darf nur enthalten sein, wenn es sich um das genaue SHA-256 des aktuellen serialisierten Zustands handelt.
   • Wenn dieses Schreiben fehlschlägt, stoppen Sie sofort. Löschen Sie keine verschachtelten ralplan-, verknüpften Zustand, Abbruchsignale oder Laufzeitartefakte.
3. Löschen Sie für einen benannten Workflow nur den ralplan-Zustand, der derselben session_id gehört; löschen Sie niemals den eigenständigen ralplan-Zustand einer anderen Sitzung. Zeichnen Sie einen Fehler auf, halten Sie den angehaltenen Primären jedoch wiederherstellbar.
4. Erst nachdem die primäre Pause festgeschrieben wurde, prüfen Sie auf verknüpften Ralph über state_read(mode="ralph", session_id). Wenn Ralph aktiv und mit diesem Autopilot verknüpft ist, löschen Sie ralph- und optionalen ultragoal-Zustand.
5. Schreiben Sie als letzten Schritt ein Abbruchsignal state_write(mode="cancel-signal", session_id, state={...}) und geben Sie eine strukturierte Zusammenfassung mit dem Ergebnis des aktuellen Laufs (angehalten/fortgesetzt) aus.

Fehlerbehandlung beim primären Anhalten: Wenn state_write(active=false) fehlschlägt:

• Löschen Sie KEINE Zustandsdateien
• Löschen Sie KEINE verschachtelten Modi
• Kehren Sie zur normalen Ausführung zurück; der Autopilot läuft weiter
• Melden Sie den Fehler dem Benutzer

Wenn Ralph aktiv ist

1. Lesen Sie den Ralph-Zustand über state_read(mode="ralph", session_id), um den aktuellen Lauf, die Häufigkeit und die Statusdetails zu erfassen.
2. Prüfen Sie, ob Ralph verknüpft ist: Wenn state.linked_team existiert und true ist: a. Brechen Sie zuerst das Team mit dem Zweiphasenprotokoll aus Abschnitt "Wenn Team aktiv ist" ab. b. Löschen Sie den Teamzustand mit state_clear(mode="team", session_id).
3. Ralph ohne Verknüpfung anhalten:
   • Verwenden Sie state_clear(mode="ralph", session_id), um Ralph-spezifische Dateien zu entfernen.
   • KEIN state_write(active=false) aufrufen; Ralph wird vollständig gelöscht.
4. Sammeln Sie den Verlauf der zuletzt generierten Artefakte aus dem Ralph-Zustand zur Protokollierung.
5. Geben Sie einen strukturierten Ralph-Abbruchbericht aus:

   Ralph-Lauf beendet (Frequenz: <freq>, Iterationen: <n>)
   - Team-Verknüpfung: falls vorhanden, "Verknüpftes Team <name> zuerst abgebrochen"
   - Letzte generierte Artefakte: <Liste>
   - Nächste Schritte: Benutzer kann mit ralph neue Sitzung starten
   

Wenn ultragoal/legacy ultrawork/ultraqa aktiv ist

1. Lesen Sie den ultragoal-Zustand: state_read(mode="ultragoal", session_id).
2. Löschen Sie den ultragoal-Zustand: state_clear(mode="ultragoal", session_id).
3. Löschen Sie den ultrawork-Zustand: state_clear(mode="ultrawork", session_id) (dies löscht .omc/state/sessions/<sessionId>/ultrawork-state.json, falls vorhanden).
4. Löschen Sie den ultraqa-Zustand: state_clear(mode="ultraqa", session_id) (dies löscht .omc/state/sessions/<sessionId>/ultraqa-state.json, falls vorhanden).
5. Für Ultragoal: Bewahren Sie vorhandene .omc/ultragoal/-Pläne oder Ledger-Dateien (nicht sitzungsspezifisch; sie sind dauerhaft, bis sie manuell gelöscht werden).
6. Geben Sie eine Bestätigung aus.

Wenn Ultrapilot aktiv ist

// Ultrapilot-Zustand lesen
state_read(mode="ultrapilot", session_id)
// -> wenn active === true, fahren Sie mit state_clear fort
state_clear(mode="ultrapilot", session_id)

Wenn Swarm aktiv ist

Swarm ist eigenständig und nicht sitzungsbezogen:

1. Prüfen Sie, ob eine Swarm-Markierungsdatei vorhanden ist: state_read(mode="swarm") (wenn der Modus unbekannt ist, verwenden Sie state_list_active, um nach "swarm" zu suchen).
2. Theoretisch sollte Swarm den gesamten Schwarm über ein Signal stoppen; falls nicht, entfernen Sie die SQLite-Datenbank- und Markierungsdateien:
   • state_clear(mode="swarm") löscht .omc/state/swarm.db, .omc/state/swarm-active.marker und zugehörige Dateien.
3. Alle Tasks in der Warteschlange werden aufgegeben.
4. Bestätigen Sie, dass der Schwarm angehalten wurde.

Wenn Pipeline aktiv ist

1. Lesen Sie Pipeline-spezifischen Zustand über state_read(mode="pipeline", session_id), um Pipeline-Schritte und -Status zu erfassen.
2. Brechen Sie die Pipeline ab, indem Sie jeden noch nicht abgeschlossenen Schritt auf Task-Absage setzen.
3. Löschen Sie den Pipeline-Zustand: state_clear(mode="pipeline", session_id).
4. Geben Sie eine Zusammenfassung der abgebrochenen Schritte und des Pipeline-Namens aus.

Wenn Self-Improve aktiv ist

// Self-Improve-Zustand lesen
state_read(mode="self-improve", session_id)
// -> prüfen Sie auf iteration_state für Wiederaufnahme

// Zustandsmodus-Hauptdatei für Sitzung löschen
state_clear(mode="self-improve", session_id)

// Worktrees oder generierte Dateien aus dem Self-Improve-Prozess bereinigen:
SELF_IMPROVE_ROOT=".omc/self-improve"
if [ -d "$SELF_IMPROVE_ROOT" ]; then
  rf -f "$SELF_IMPROVE_ROOT"/state/session-state-*.json
  # iteration_state-Dateien für mögliche Wiederaufnahme bewahren
  # Orphaned worktrees identifizieren und löschen (Bash-Fallback)
fi

// Status in agent-settings.json setzen
// (Dies ist eine vereinfachte Bash-Darstellung; führen Sie dies nach der Zustandsbereinigung aus):
SETTINGS_FILE="${SELF_IMPROVE_ROOT}/state/agent-settings.json"
[ -f "$SETTINGS_FILE" ] && \
  node -e "
    const f = require('fs');
    const p = '$SETTINGS_FILE';
    const j = JSON.parse(f.readFileSync(p, 'utf8'));
    j.status = 'user_stopped';
    f.writeFileSync(p, JSON.stringify(j, null, 2));
  "

Mit mehreren aktiven Modi umgehen

Die Fähigkeit führt derzeit KEINE rekursive Abhängigkeitsanalyse durch. Sie verlässt sich auf die Entdeckung über state_list_active und state_get_status:

1. Rufen Sie state_list_active auf, um jede aktive Sitzung aufzulisten.
2. Rufen Sie für jede Sitzungs-ID state_get_status auf, um den primären und alle sekundären/abhängigen Modi zu lernen.
3. Brechen Sie Modi in der aufgeführten Reihenfolge ab: Autopilot → Ralph → Ultragoal → ... (siehe Abhängigkeitsliste oben).

Der Cancel-Bericht listet auf, welcher Modus erfolgreich abgebrochen wurde, welcher übersprungen wurde (nicht gefunden) und ob manuelle Schritte erforderlich sind.

4. Fehlerberichtsstruktur

{
  "cancelled": ["autopilot", "ralph"],
  "skipped": ["ultragoal", "swarm", "pipeline"],
  "errors": [],
  "dependencies_cleared": true,
  "legacy_cleanup_run": false,
  "manual_steps_required": false,
  "summary": "Autopilot angehalten (wiederherstellbar). Verknüpfter Ralph gelöscht."
}

Bereinigungsreihenfolge des Legacy-Fallbacks

Wenn die Zustandstools nicht verfügbar sind und der Bash-Fallback erforderlich ist:

Phase 1: Verknüpfte Modi trennen

• Ralph nur löschen, wenn verknüpft UND:
  • Autopilot wurde bereits erfolgreich angehalten, ODER
  • Ralph ist selbst der primäre Modus und nicht mit Autopilot verknüpft

Phase 2: Verwaisten Zustand bereinigen

• Wird automatisch von state_clear ohne session_id behandelt