Das Backlog ausführen

Im autonomen Backlog scannt, klassifiziert und priorisiert SupaCloud die offenen Issues eines Projekts und startet dann Agenten-Runs, um sie abzuarbeiten – begrenzt durch Budgets, eine Parallelitäts-Obergrenze, Ruhezeiten und die Autonomiestufe des Workspaces. Diese Seite behandelt die Operator-Aufgaben: den Backlog-Modus aktivieren, das Workspace-Board lesen, die Sicherheitsgrenzen setzen und einen kontrollierten Dispatch starten.

Hinweis

Backlog ist einer der drei Autodev-Modi des Projekts (Aus · Einfach · Backlog). Einfach und Backlog durchlaufen beide die Dispatch-Pipeline; PR-Review ist davon eine getrennte, orthogonale Spur. Das Modus-Modell und das Zusammenspiel von Freigabe-Modus, Klassifizierer, Agentenprofil und Blast-Radius beschreiben Automatisierungen und Den Autodev-Modus wählen.

Ein Projekt in den Backlog-Modus setzen

1. Öffne das Projekt und dann seinen Bearbeiten-Dialog.
2. Setze im Abschnitt Automatisierung den Autodev-Modus auf Backlog. (Wähle stattdessen Einfach, um jedes Issue direkt und in Eingangsreihenfolge in einen Pull-Request umzusetzen; Aus importiert Issues, dispatcht aber nichts.)
3. Wähle den Freigabe-Modus (die Backlog-Merge-Richtlinie): Nur PR (einen PR öffnen und anhalten), Auto-Merge bei grün (mergen, sobald alle Gates bestehen) oder Voll automatisch.
4. Optional legst du den Klassifizierer, den Agenten, das Schweregrad-Gate und den Blast-Radius (Umgebungs-Scope + Denied-Tools-Denylist) fest.
5. Speichere. SupaCloud materialisiert den Backlog-Workflow des Projekts, damit dispatchte Items etwas haben, das sie ausführt.

Unabhängig vom eingestellten Modus importiert SupaCloud die offenen Issues des Projekts – aus dem Git-Forge, Linear und Notion –, und der Scan- und Klassifizierungslauf nimmt neue als queued-Items auf. Der Backlog-Modus dispatcht sie anschließend in Prioritätsreihenfolge.

Das Workspace-Backlog-Board ansehen

Öffne Backlog in der Seitenleiste.

Die Seite hat einen Projekt ⇄ Workspace-Bereichsumschalter:

• Workspace-Bereich (die Voreinstellung) ist eine projektübergreifende, schreibgeschützte Zusammenfassung jedes backlog-aktivierten Projekts im Workspace, ergänzt um das manuelle Dispatch-Panel. Diese Option erscheint erst, wenn der Workspace zwei oder mehr backlog-aktivierte Projekte hat – darunter gibt es kein projektübergreifendes Bild, das ein Workspace-Board rechtfertigen würde.
• Projekt-Bereich listet die Projekte des Workspaces auf; öffnest du ein Projekt, zeigt es sein interaktives Board, auf dem du Karten zwischen Spalten verschieben, die Priorität neu ordnen und eine fertige Karte auf Done ziehen kannst.

Jedes Board hat sieben Spalten in fester Reihenfolge: classified → queued → in_progress → in_review → done, dazu die Spuren needs_info und blocked. Die aktive Pipeline läuft von links nach rechts; done, needs_info und blocked bilden die abschließenden Spuren.

Das Dispatch-Panel lesen

Das Dispatch-Panel über dem Workspace-Board zeigt live, wie der Dispatcher arbeitet:

• die Dispatch-Rate – wie viele Backlog-Runs im jüngsten Fenster dispatcht wurden;
• den letzten Tick – wie lange der Lauf des Hintergrund-Schedulers zurückliegt (ein wachsender Wert deutet darauf hin, dass der Ticker stehen geblieben ist);
• die In-Flight-Zahl – die Backlog-Runs, die gerade im Workspace laufen;
• das Tick-Intervall – den Takt des Schedulers;
• eine Zeile je Projekt für jedes Backlog-Projekt mit seiner effektiven Grenze, seinen Items in Warteschlange und einem etwaigen Blockier-Grund (warum dieses Projekt nicht dispatcht).

Brauchst du die Details nicht, klappt das Panel auf eine einzige Statuszeile zusammen – ein Klick darauf blendet die volle Aufschlüsselung wieder ein.

Hinweis

Der Dispatch lässt sich auf zwei Wegen pausieren. Als Owner pausierst du deinen gesamten Workspace in dessen Einstellungen; ein Instanz-Operator kann zusätzlich den instanzweiten Global-Dispatch-Notausschalter umlegen. Der Dispatch läuft nur, wenn beide ihn erlauben – ein pausierter Workspace oder ein deaktivierter globaler Schalter erscheint im Panel als Blockier-Grund.

Die Parallelitäts-Obergrenze setzen

Die Workspace-Parallelitäts-Obergrenze (max_backlog_concurrent) begrenzt die Summe der laufenden Backlog-Runs über alle Projekte des Workspaces. SupaCloud prüft sie bei jedem Dispatch-Tick zuerst, zusätzlich zur eigenen Parallelitäts-Grenze jedes Projekts – die effektive Grenze ist der niedrigste der drei Werte: Projekt-Grenze, Workspace-Obergrenze und Parallelitätsfaktor der Autonomiestufe.

Eine nicht gesetzte Obergrenze bedeutet unbegrenzt; dann begrenzt jedes Projekt nur durch seine eigene Projekt-Grenze. Die aufgelöste Obergrenze und die noch freien Slots zeigt die Workspace-Backlog-Statuszeile über dem Board an, sodass du erkennst, warum der Dispatch startet oder eben nicht.

Ruhezeiten setzen

Ruhezeiten pausieren den Dispatch während eines täglichen Fensters – Scan und Klassifizierung laufen weiter, sodass sich weiterhin Items als queued ansammeln; unterdrückt wird allein der Start.

1. Öffne Einstellungen → Arbeitsbereich und finde die Karte Ruhezeiten.
2. Setze eine Start- und eine Ende-Zeit. Zeiten werden in UTC gespeichert und ausgewertet.
3. Speichere.

Das Fenster ist ein halboffenes Intervall [Start, Ende). Ein Fenster über Mitternacht hinweg (zum Beispiel 22:00 → 06:00) ist möglich. Lässt du beide Felder leer, wird das Fenster gelöscht und der Dispatch nie unterdrückt; ein nur halb ausgefülltes Paar wird abgelehnt – setze entweder beide Werte oder keinen.

Hinweis

Ruhezeiten sind nur eines von mehreren Dispatch-Gates. Der Dispatch wird außerdem unterdrückt, solange der Workspace im Onboarding-Modus ist, wenn der Global-Dispatch-Notausschalter aus ist, wenn die Workspace-Parallelitäts- Obergrenze ausgeschöpft ist, wenn die Autonomiestufe zu 0 aufgelöst wird oder wenn das Provider-Kontingent fast erschöpft ist.

Einen Dispatch-Probelauf durchführen, dann dispatchen

Das manuelle Dispatch-Panel auf dem Workspace-Board führt einen Probelauf (Dry-Run) durch, bevor du etwas startest. Eine Dispatch-Anfrage ohne Body ist immer ein gefahrloser Probelauf – sie schreibt nichts und startet nichts.

1. Auf dem Workspace-Board lädt das Dispatch-Panel beim Einblenden einen Probelauf. Klicke auf Aktualisieren, um ihn erneut auszuführen.
2. Lies die Vorschau:
   • Items in Warteschlange – eine Obergrenze dafür, wie viele Runs starten könnten (Projekt-Grenzen und Budgets fließen hier nicht in die Simulation ein, die tatsächliche Zahl kann also niedriger ausfallen).
   • Autonomiestufe – die aufgelöste Autonomie-Obergrenze des Workspaces.
   • einen Unterdrückt-Hinweis samt verständlicher Begründung, falls ein Gate den Dispatch blockiert (Onboarding, Obergrenze erreicht, Autonomie 0, Global-Dispatch aus, Ruhezeiten oder Provider-Kontingent fast erschöpft).
3. Blockiert nichts und ist die Warteschlange nicht leer, ist Jetzt dispatchen aktiv. Ein Klick darauf stößt den Launch an, meldet, wie viele Runs gestartet sind, und führt erneut einen Probelauf durch, damit das Panel den Stand des Boards nach dem Start widerspiegelt.

Ein echter Dispatch erfordert die CreateRun-Berechtigung und schreibt ein Audit-Ereignis. Beim echten Launch greifen dieselben Gates, die schon die Vorschau meldet, sodass die Vorschau nie vom tatsächlichen Geschehen abweicht.

Hinweis

Der Dispatch läuft auch automatisch beim Hintergrund-Scheduler-Tick, sofern die Autonomiestufe bei Assistiert oder höher liegt. Im Band Manuell ist der Auto-Dispatcher vollständig aus; dann kann nur ein manuelles Jetzt dispatchen etwas starten. Die Bänder beschreibt Automatisierungen.

Die Dev-Pipeline justieren

Jede Backlog-Automatisierung durchläuft eine Dev-Pipeline mit den Stufen Draft, Implement und Review. Die Pipeline trägt zwei Justier-Ebenen:

• Experten-Overrides pro Stufe — ein Harness, ein Modell und eine Effort je Stufe für draft, implement und review, gestempelt auf die materialisierten Workflow-Nodes. Diese werden in diesem Release über die API / die rohe pipeline_config konfiguriert — für die Stufen-Map gibt es in der Web-Oberfläche noch keinen eigenen Formular-Editor.
• Return-to-Sender-Loop — der Review-Schalter und die Loop-Knöpfe (Konvergenzstufe, max. Runden, max. Kosten) sind im Abschnitt Automatisierung des Projekts verfügbar. Ist Review an, läuft nach Implement ein unabhängiger forensischer Audit; ein fehlgeschlagener Audit hebt die Effort des Items um eine Stufe an und stellt es neu in die Warteschlange – oder durchläuft, wenn der Return-to-Sender-Loop aktiviert ist, einen begrenzten Mehrrunden-Loop.

Wie sich Review-Gate und Konvergenz-Loop verhalten, beschreibt Automatisierungen.

Siehe auch

• Automatisierungen
• Runs und Tasks
• Entitlements und MCP-Stufen