ultragoal

<Verwende_Wenn>

• Der Benutzer eine dauerhafte, repositoreiigene Möglichkeit wünscht, ein Ultragoal über mehrere Claude-Sitzungen oder Worktrees hinweg zu verfolgen.
• Die Arbeit umfangreich genug ist, um mehrere geordnete „Stories" mit Versuchszahlen und Nachweisen pro Story zu rechtfertigen.
• Der Benutzer den endgültigen Abschluss hinter einer ai-slop-cleaner + Verifikation + $code-review Hürde haben möchte.
• Der Benutzer wünscht, dass die aktive Claude /goal-Direktive mit dem Ledger abgestimmt ist, sodass ein Sitzungsneustart keinen Fortschritt verliert. </Verwende_Wenn>

<Verwende_Nicht_Wenn>

• Die Aufgabe eine einzelne kleine Änderung ist – verwende stattdessen direkte Delegation oder ralph.
• Der Benutzer möchte, dass der Assistent /goal buchstäblich aus der Shell aufruft – das ist nicht möglich; omc ultragoal schreibt nur Artefakte und gibt Übergabetext aus.
• Der Benutzer ein reines Planungsartefakt ohne Ausführungsschleife wünscht – verwende stattdessen plan. </Verwende_Nicht_Wenn>

<Warum_Dies_Existiert> Claude Code /goal ist ein sitzungsspezifischer Stop-Hook: Er blockiert das Beenden der Sitzung, bis eine Bedingung erfüllt ist, und löscht sich bei Erfolg automatisch. Das ist ein großartiges primitives Element für die Ausführung in einer einzelnen Sitzung, verliert aber den Zustand sitzungsübergreifend und erzwingt an sich keine abschließende Review-Hürde. omc ultragoal fügt einen dauerhaften Plan, ein Ledger und eine Hürdenschicht hinzu, sodass eine lange, mehrschrittige Initiative Sitzungsneustarts, neue Worktrees und Review-Iterationen überstehen kann, während gleichzeitig Claude /goal genutzt wird, um den aktiven Agenten fokussiert zu halten. </Warum_Dies_Existiert>

<Wie_Man_Es_Verwendet>

1. Erstelle einen Plan aus einem Briefing:

   omc ultragoal create-goals --brief-file plan.md
   

   Oder mit expliziten Stories:

   omc ultragoal create-goals --brief "ship the migration" \
     --goal "Schema::Neue Spalten hinzufügen" \
     --goal "Backfill::Zeilen batchweise nachfüllen" \
     --goal "Cutover::Alte Spalten löschen und Lesezugriffe umstellen"
   

   Der Standardmodus ist aggregate (ein Claude /goal deckt den gesamten Durchlauf ab). Übergib --claude-goal-mode per-story, wenn jede Story ihr eigenes /goal haben soll.

   Multi-Repo-Workspaces / parallele Sitzungen: Wenn mehrere Claude-Sitzungen im selben Workspace /ultragoal gleichzeitig ausführen müssen, übergib entweder --plan-id <stabile-id> oder --auto-plan-id, damit der Plan in .omc/ultragoal/plans/{planId}/ statt im gemeinsamen Einzelplan-Pfad abgelegt wird. Ohne dieses Flag würden sich zwei Sitzungen, die Ziele erstellen, gegenseitig überschreiben. --auto-plan-id leitet {epochMs}-{slug} aus dem Briefingtitel ab. Verwende dann in allen nachfolgenden Unterbefehlen derselben Sitzung --plan-id <id>. Verwende omc ultragoal list-plans, um bei Bedarf verfügbare planIds aufzulisten.

2. Starte (oder setze fort) die nächste Story:

   omc ultragoal complete-goals [<goal-id>]
   

   Ohne Ziel-ID wird das Standardverhalten beibehalten: die aktive Story fortsetzen oder die erste ausstehende Story starten. Mit einer Ziel-ID zielt OMC genau auf diese benannte berechtigte Story ab (eine ausstehende Story kann außer der Reihe gestartet werden); sie fällt nie auf eine andere Story zurück. Eine aktive andere Story, unbekannte ID, abgeschlossene oder durch Review blockierte Story oder fehlgeschlagene Story ohne --retry-failed wird ohne Zustandsänderung abgelehnt. Eine laufende benannte Story wird ohne Änderung der Versuchszahl fortgesetzt. Dies gibt eine modellseitige Übergabe aus. Der aktive Claude-Agent muss sie lesen und:

   • Das native Claude /goal für diese Sitzung setzen – im eigenständigen Claude Code kann weder die Shell noch der Agent das tun, also bitte den Benutzer, /goal <Gesamtziel> einzugeben und zu warten. --claude-goal-json (unten) gleicht nur das Ledger ab und erfüllt nicht die PreToolUse /goal-Hürde, die Tool-Aufrufe blockiert, bis sie ein aktives /goal feststellt.
   • Die Story bearbeiten.
   • Wenn die Story abgeschlossen ist (und bei der letzten Story nach der vollständigen Qualitätshürde), einen Snapshot des aktiven /goal-Zustands zurückmelden und checkpoint aufrufen.

3. Setze einen Checkpoint für eine Story:

   omc ultragoal checkpoint --goal-id G001-... --status complete \
     --evidence "tests/files/PR evidence" \
     --claude-goal-json '{"goal":{"objective":"...","status":"active"}}'
   

   Für die letzte Story übergib zusätzlich --quality-gate-json mit aiSlopCleaner, verification und codeReview-Nachweisen (alle sauber).

4. Wenn die abschließende Überprüfung nicht sauber ist, markiere NICHT als abgeschlossen. Zeichne Blocker auf:

   omc ultragoal record-review-blockers --goal-id G00X-... \
     --title "Lösche finale Code-Review-Blocker" \
     --objective "Behebe die genannten Review-Feststellungen und führe die finalen Hürden erneut aus" \
     --evidence "<die Review-Feststellungen>" \
     --claude-goal-json '{"goal":{"objective":"...","status":"active"}}'
   

   Dies fügt eine neue Blocker-Story an und hält das Claude /goal aktiv.

5. Überprüfe den Zustand jederzeit:

   omc ultragoal status
   

</Wie_Man_Es_Verwendet>

<Wichtige_Einschränkungen>

• Die Shell kann den Claude Code /goal-Zustand weder aufrufen noch ändern. omc ultragoal persistiert nur dauerhafte Artefakte und gibt Anweisungen aus, die der aktive Claude-Agent liest und innerhalb der Sitzung umsetzt.
• Snapshots, die über --claude-goal-json übergeben werden, sind vom Modell gelieferte Nachweise des aktiven /goal-Zustands; OMC validiert sie auf textuelle Konsistenz mit dem erwarteten Ziel des Plans und dem Ledger-Ereignis, kann aber den Claude /goal-Zustand nicht unabhängig beobachten. Sie erfüllen nicht die PreToolUse /goal-Hürde, die ein tatsächlich aktives /goal erfordert – einen hostinjizierten Snapshot oder das native /goal, das der Benutzer in der Sitzung gesetzt hat.
• Wenn der Claude /goal-Slash-Befehl umbenannt oder umstrukturiert wird, muss nur der Übergabetext geändert werden; die Abgleichslogik ist namensunabhängig. </Wichtige_Einschränkungen>

Hinweise zu parallelen Sitzungen

• Multi-Repo-Workspace-Anker: platziere einen .omc-workspace-Marker im übergeordneten Verzeichnis, sodass mehrere Sitzungen in Unter-Repos ein gemeinsames .omc/ teilen. Auflösungsreihenfolge: OMC_STATE_DIR > .omc-workspace > git > cwd. Siehe docs/REFERENCE.md.
• Quelle der Sitzungs-ID: OMC_SESSION_ID-Umgebungsvariable gewinnt in CLI-Kontexten; hook payload data.session_id gewinnt in Hook-Kontexten.
• Plan-ID (falls zutreffend): Zwei Durchläufe im selben Workspace kollidieren bei gemeinsamen Plan-Artefakten. Verwende unterschiedliche Sitzungs-IDs (die Hook-Payload-Session-ID ist bereits pro Claude Code-Sitzung isoliert) oder übergib --plan-id, um parallele Ultragoal-Läufe auf getrennten Ledgern zu halten.
• Paralleles Urteil: unterstützt (jede Sitzung schreibt ihren eigenen sitzungsspezifischen Zustand).