Planprüfung und Task-Queue

Überblick

In Ottili Coder ist die Planprüfung* der Moment, in dem aus deiner Mission ein strukturierter, überprüfbarer technischer Plan wird – und die Task-Queue* die geordnete Liste von Aufgaben, die Coder danach ausführt. Beides gehört zusammen: Erst prüfst du den Plan, dann lässt du ihn in eine Task-Queue zerlegen, die von rollenbasierten Agents in isolierten Workspaces abgearbeitet wird.

Dieser Artikel erklärt, was in Plan und Queue steckt, wie du den Plan liest und freigibst, welche Rolle Freigabe-Gates spielen und wie du denselben Ablauf über die CLI steuerst. Ergänzend: [Task oder Mission anlegen](/docs/coder-create-task-or-mission) beschreibt, wie die Mission überhaupt entsteht.

Vom Ziel zur Task-Queue

Der Ablauf ist fest verdrahtet:

1. Mission* – du formulierst das Ziel in Alltagssprache (New Build → Chat Intake oder CLI).

2. Repository-Analyse* – Coder analysiert Stack, Abhängigkeiten, Build-Pfade, Risiken und fehlende Informationen.

3. Plan* – die Mission wird zu einem strukturierten, überprüfbaren Plan.

4. Task-Queue* – der Plan wird in geordnete, verifizierbare Tasks zerlegt (Recon, Decomposition, Risk).

5. Agents* – die Tasks laufen über rollenbasierte Agents in isolierten Workspaces.

6. Freigaben* – riskante Schritte werden vor der Ausführung an ein Freigabegate geleitet.

7. Run-Record* – das Record schließt mit Logs, Freigaben, Status und Audit-Trail zusammen.

Die Planprüfung sitzt zwischen Schritt 2 und 4: bevor Coder auch nur eine Zeile ändert, siehst du den Plan und entscheidest.

Den technischen Plan prüfen

Wenn nichts Build-relevantes fehlt, wechselt die Mission-Karte zu „Mission ist klar und abgegrenzt. Ready to build."* mit zwei Wahlmöglichkeiten:

• Review technical plan* – öffnet einen strukturierten Plan, den du vor dem Build akzeptieren kannst.
• Start build* – startet den Run direkt aus dem erfassten Ziel.

Wähle Review technical plan*, um den Plan zu lesen, bevor Code entsteht. Der Plan enthält:

• Scope* – was genau verändert wird und was nicht.
• Architektur* – betroffene Module, Dateien und Abhängigkeiten.
• APIs* – neue oder geänderte Endpunkte, Verträge und Datenmodelle.
• UI* – betroffene Oberflächen, Routen und Komponenten.
• Auth* – Berechtigungen, Tenant-Grenzen und Freigaben.
• Tests* – welche Tests abgedeckt werden und wie sie verifizieren.
• Risiken* – bekannte Risiken und wie sie abgefangen werden.
• Akzeptanzkriterien* – woran du misst, dass die Aufgabe erfüllt ist.

Der Plan ist schreibgeschützt (Plan-Modus): Coder verändert deinen Code noch nicht. Du kannst Annahmen und Rahmenbedingungen hinterfragen, bevor du akzeptierst. Den freigegebenen Plan beförderst du auf derselben Mission in einen Build-Run – Queue, Logs und Audit-Trail bleiben über den Wechsel hinweg konsistent.

Die Task-Queue verstehen

Sobald der Plan akzeptiert ist, zerlegt Coder ihn in eine geordnete, verifizierbare Task-Queue*:

• Recon* – Erkundung des Repositories und Sammeln fehlender Fakten.
• Decomposition* – Zerlegung in einzelne, klar abgegrenzte Tasks.
• Risk* – Markierung riskanter Schritte für Freigabe-Gates.

Jede Task hat einen eigenen Zustand und ein prüfbares Ergebnis. Die Queue ist echt und editierbar: Agents führen sie in isolierten Workspaces aus, du siehst Fortschritt, Logs und das Audit-Trail pro Task. So bleibt nachvollziehbar, warum Coder was getan hat – auch wenn einzelne Tasks scheitern und wiederholt werden.

Die Queue läuft lokal, in der Ottili Cloud* (Beta) oder hybrid. Unabhängig vom Ort gelten Validierungsschleifen und – sofern konfiguriert – Sicherheitsprüfungen; riskante Schritte werden als Freigabe-Gates sichtbar, statt still zu laufen.

Freigaben für riskante Schritte

Risikoreiche Schritte werden vor der Ausführung an ein Freigabegate* geleitet. Ein Mensch entscheidet, bevor Coder Änderungen anwendet – beim Build über die Oberfläche ebenso wie bei CLI- und Cloud-Runs. Das verhindert, dass weitreichende Änderungen ohne Kontrolle laufen, und hält den Audit-Trail vollständig.

Über die CLI

Installiere zuerst die CLI (siehe [CLI installieren](/docs/cli-installation)). Nachdem eine Mission erfasst ist, steuerst du Plan und Queue direkt:

# Prüfbaren technischen Plan aus einer Mission erzeugen
ottili coder mission-generate-plan <mission-id>

# Plan-Schritt ausführen (schreibgeschützt, ohne Code zu ändern)
ottili coder mission-action <mission-id> --action plan

# Tasks in die Queue freigeben und starten
ottili coder mission-action <mission-id> --action dispatch

Nützliche Nachbarbefehle für den gesamten Lebenszyklus: mission-intake (Mission anlegen), mission-refine "<anfrage>" --answer feld=antwort (nach Rückfragen erneut normalisieren) und mission-action <mission-id> --action <clarify|plan|dispatch|cancel|retry|reset>. Details dazu in [Task oder Mission anlegen](/docs/coder-create-task-or-mission).

Status ehrlich unterscheiden

Ottili Coder verwendet das kanonische Status-Vokabular. Für diesen Artikel gilt aktuell:

Erfindete Verfügbarkeiten gibt es nicht: eine Fähigkeit wird nur dann als verfügbar ausgewiesen, wenn die Registry sie als verfügbar attestiert. Cloud-Runs sind Beta; das direkte Deployment wird erst als verfügbar ausgewiesen, wenn das öffentliche Ziel angebunden ist. Das kanonische Vokabular lautet: Concept, Planned, Early Access, Beta, Available* – plus Paused, Deprecated, Retired für den Lebenszyklus.

Verwandte Artikel

• [Task oder Mission anlegen](/docs/coder-create-task-or-mission)
• [Modi](/docs/coder-modes)
• [Repository verbinden](/docs/connect-a-repository)
• [Desktop installieren](/docs/desktop-installation)
• [CLI installieren](/docs/cli-installation)