Automatisierungen
Jedes Projekt hat einen Automatisierungs-Abschnitt. Er steuert, wie SupaCloud auf Ereignisse in diesem Projekt reagiert, ohne dass ein Mensch von Hand einen Task startet, und bündelt an einer Stelle die Fragen „Was darf dieses Projekt automatisch tun?“ und „Wie eng wird das überwacht?“: einen Autodev-Modus, eine orthogonale PR-Review-Spur und einen gemeinsamen Satz von Überwachungs-Steuerungen.
Der Autodev-Modus
Abschnitt betitelt „Der Autodev-Modus“Der Autodev-Modus hat drei mögliche Werte. Er entscheidet, was das Projekt mit seinen Issues anstellt.
| Modus | Was er tut |
|---|---|
| Aus | Das Projekt importiert seine Issues, dispatcht aber nichts. |
| Einfach | Jedes neue Issue wird direkt in einen Pull-Request umgesetzt, in Eingangsreihenfolge (First in, first out). |
| Backlog | Issues werden gesammelt, klassifiziert und priorisiert und dann in Prioritätsreihenfolge dispatcht – begrenzt durch die Autonomiestufe, die Parallelitäts-Obergrenzen und das Budget. |
Einfach und Backlog durchlaufen dieselbe Pipeline aus Scan, Klassifizieren und Dispatch; sie unterscheiden sich nur darin, in welcher Reihenfolge sie Arbeit aus der Warteschlange holen – Einfach nimmt zuerst das älteste Item, Backlog das mit der höchsten Priorität. Beide erzeugen ihre Änderungen gemäß der Merge-Richtlinie des Projekts. Aus lässt den Dispatch deaktiviert.
Die orthogonale PR-Review-Spur
Abschnitt betitelt „Die orthogonale PR-Review-Spur“Eine weitere Automatisierung reagiert auf Ereignisse, unabhängig vom Autodev-Modus – ein Projekt kann sie in beliebiger Kombination mit dem Modus aktiv haben.
| Spur | Was sie auslöst | Was sie tut |
|---|---|---|
| PR-Review | Ein Pull-Request-Webhook | Führt den Auto-Developer über einen eingehenden Pull-Request aus. |
PR-Review steht orthogonal zum Autodev-Modus: sie zu aktivieren ändert den Modus nicht, und ein Backlog-Projekt kann ebenso gut Pull-Requests prüfen. Sie bringt ihre eigenen Überwachungs-Steuerungen mit (siehe unten).
Die gemeinsamen Steuerungen
Abschnitt betitelt „Die gemeinsamen Steuerungen“Über den Autodev-Modus und die PR-Review-Spur hinweg bestimmt dieselbe Steuerungs-Zeile, wie eng überwacht und wie stark eingeschränkt eine Automatisierung ist. Diese Hebel solltest du kennen.
Schweregrad
Abschnitt betitelt „Schweregrad“Ein Schweregrad-Gate filtert, auf welche Ereignisse die Automatisierung
reagiert. Ein Ereignis unterhalb des konfigurierten Mindest-Schweregrads wird
ignoriert. Den Schweregrad leitet SupaCloud aus den Labels des Ereignisses ab (bei
Backlog und PR-Review zusätzlich aus seiner Priorität): Ein Label wie critical,
blocker oder outage ergibt critical; high, urgent oder security ergibt
high; low, minor oder docs ergibt low; alles andere ist standardmäßig
medium. Steht der Schweregrad auf Beliebig, greift kein Gate.
Freigabe-Modus
Abschnitt betitelt „Freigabe-Modus“Der Freigabe-Modus entscheidet, wie viel Mensch zwischengeschaltet ist, bevor Arbeit gemergt wird. Die genauen Optionen hängen von der Automatisierung ab, folgen aber stets derselben Idee:
- Direkt / keine – kein zusätzliches menschliches Gate; die Automatisierung geht eigenständig zu ihrer Merge-Richtlinie über.
- Zuerst Entwurf / nur PR – die Automatisierung öffnet einen Pull-Request und hält dort an; ein Mensch prüft und mergt.
- Review erforderlich / menschliches Gate – vor dem Abschluss der Änderung ist
eine menschliche Freigabe nötig. Beim Backlog entspricht das dem
human_gate-Modus: Das Gate-Node des Workflows hält den Run an, bis eine Person freigibt. - Konzept zuerst – bevor sie eine Zeile Code schreibt, erstellt die Automatisierung ein code-fundiertes Umsetzungs-Konzept und hält für eine menschliche Prüfung an. Sobald eine Person freigibt, läuft derselbe Run weiter und setzt das freigegebene Konzept um.
Konzept zuerst schaltet ein menschliches Freigabe-Node in die Mitte eines einzelnen Runs, nicht zwischen zwei Runs: Konzept und Umsetzung sind ein durchgehender Task, sodass der Freigebende den fundierten Plan des Agenten im Kontext sieht, bevor dieser den Code anfasst. Das Konzept steht orthogonal zur Merge-Richtlinie und zum Audit-/Review-Gate – die Konzept-Freigabe bestimmt, was gebaut wird, Merge-Richtlinie und Review-Gate bestimmen weiterhin, wie das Ergebnis gemergt wird. Verfügbar ist es für die Backlog-/Autodev-Spur.
Bei einem Backlog-Dispatch tritt der Freigabe-Modus als Merge-Richtlinie in Erscheinung: Nur PR (einen PR öffnen und anhalten), Auto-Merge bei grün (mergen, sobald jedes Gate besteht) oder Voll automatisch.
Abschlussaktion
Abschnitt betitelt „Abschlussaktion“Die Abschlussaktion entscheidet, was mit dem verknüpften Issue geschieht, wenn ein issue-verknüpfter Task fertig ist. Sie ist eine Einstellung pro Automatisierung mit drei Werten:
- Schließen (der Standard) – das verknüpfte Issue mit der Abschluss-Zusammenfassung kommentieren und es dann schließen oder transitionieren.
- Kommentieren – die Abschluss-Zusammenfassung posten, das Issue aber offen lassen.
- Nichts – das Issue weder kommentieren noch transitionieren (vollständiger Opt-out).
Die Abschlussaktion gilt für issue-verknüpfte Tasks: die PR-Review-Spur und
jeden Task, den du von Hand aus einem Issue startest (run --issue). Ein autonom
dispatchtes Backlog-Item ist auf Task-Ebene nicht issue-verknüpft – es trägt eine
Backlog-Referenz, keine Issue-Referenz – sein Quell-Issue wird daher durch das
Fixes #N des gemergten Pull-Requests geschlossen, und Kommentieren / Nichts
gelten somit nicht für den Backlog-Dispatch. Die Abschlussaktion wird aus der
aktivierten Automatisierungs-Spur mit der höchsten Priorität gelesen.
Agentenprofil
Abschnitt betitelt „Agentenprofil“Die Agent-Auswahl legt fest, mit welchem Agenten – und über ein Agentenprofil mit welchem Modell, welcher Effort-Stufe und welchem Fähigkeitssatz – die Automatisierung ihre Runs startet. Eine Backlog-Automatisierung kann ein Agentenprofil festlegen, das das Implement-Node des Workflows anstelle des Standard-Agenten des Projekts verwendet. Bleibt es ungesetzt, greift die Automatisierung auf den konfigurierten Agenten des Projekts zurück.
Klassifizierer
Abschnitt betitelt „Klassifizierer“Ist ein Projekt im Backlog-Modus, liest ein Klassifizierer jedes importierte Issue und kennzeichnet es, bevor es dispatcht wird. Den Klassifizierer konfigurierst du direkt in den Backlog-Einstellungen; er kommt in zwei Varianten:
- Regeln – ein schneller, deterministischer Klassifizierer, gesteuert durch Labels, Titel und Beschreibung des Issues. Er braucht weder ein Modell noch Zugangsdaten.
- LLM – ein Modell klassifiziert das Issue. Du wählst das Modell, den System-Prompt, mit dem es läuft, und die Kategorien (die Art-Taxonomie), die es vergeben darf.
Der Klassifizierer ordnet jedes Issue entlang dreier Achsen:
| Achse | Was sie erfasst |
|---|---|
| Art | Was das Issue ist – Bug, Feature, Chore, Frage (oder deine eigenen Kategorien bei der LLM-Variante). |
| Priorität → Schweregrad | Wie dringend es ist. Die Priorität ordnet die Backlog-Warteschlange und bildet zugleich einen Schweregrad ab, den das Schweregrad-Gate ausliest. |
| Umfang | Wie groß die Änderung ist – klein, mittel oder groß. Bei einer großen Änderung hebt der Umfang die Routing-Effort an, bei einer kleinen senkt er sie. |
Der Schweregrad setzt stets eine Untergrenze für den Effort, den der Router vergibt; der Umfang justiert innerhalb dieser Untergrenze nach, sodass ein Issue mit großem Umfang etwas mehr Effort erhält und eines mit kleinem etwas weniger. Sowohl Einfach als auch Backlog klassifizieren; Einfach übergeht nur die Prioritäts-Ordnung und arbeitet die Items nach dem First-in-first-out-Prinzip ab.
Schaltest du Review ein, läuft nach der Implement-Stufe eines Backlog-Items ein unabhängiges forensisches Audit. Schlägt dieses Audit fehl, hebt SupaCloud die geroutete Effort-Stufe des Items um eine Stufe an und stellt es für einen weiteren Versuch zurück in die Warteschlange – ein No-op, sobald das Item bereits auf der höchsten Effort-Stufe ist, wo der Fehlschlag dann einfach bestehen bleibt.
Review kann auch als ausdrücklich begrenzte Mehrrunden-Schleife laufen: Ein Konvergenz-Level steuert, ob ein Item überhaupt in Frage kommt (anhand seines klassifizierten Schweregrads), und die Schleife ist anschließend durch eine maximale Rundenzahl und ein Kostenmaximum begrenzt. So kann ein schwieriges Item in Richtung eines sauberen Audits iterieren, ohne je unbegrenzt zu laufen.
Autonomiestufe
Abschnitt betitelt „Autonomiestufe“Jedes Projekt trägt eine Autonomiestufe, die es vom Workspace erbt und die durch die Plan-Obergrenze und die Onboarding-Grenze begrenzt wird. Die Stufe bildet einen Policy-Vektor ab – ob der Auto-Dispatcher überhaupt laufen darf, wie bereitwillig ein Tool-Aufruf einen Menschen um Klärung bittet, einen Effort-Bias und die Merge-Obergrenze – und ist in fünf benannte Bänder gegliedert:
| Band | Dispatch | Merge-Obergrenze |
|---|---|---|
| Manuell (0–24) | Aus – nur manueller Trigger | Nur PR |
| Assistiert (25–49) | An (manueller Trigger) | Nur PR |
| Überwacht (50–74) | An | Auto-Merge bei grün |
| Autonom (75–99) | An | Auto-Merge bei grün |
| Entfesselt (100) | An | Voll automatisch |
Die Stufe ist monoton: Steigt der Regler, schaltet sich der Dispatch ein und bleibt an, die Rückfrage-Schwelle wird ausschließlich gelockert und auch die Merge-Obergrenze nur weiter geöffnet. Eine Automatisierung kann zusätzlich ein Autonomie-Override festlegen, das niedriger liegt als die Workspace-Berechtigung – über die Plan-Obergrenze hinaus anheben kann sie es nie. Ein Override, das zu 0 aufgelöst wird, wirkt als harte Pause.
Blast-Radius
Abschnitt betitelt „Blast-Radius“Der Blast-Radius ist die harte, fail-closed gesetzte Grenze dafür, was ein autonomer Run überhaupt berühren darf – unabhängig von der Autonomiestufe oder einem Bestätigungs-Token. Er besteht aus zwei Teilen, die du beide im Automatisierungs-Abschnitt festlegst.
Denied-Tools
Abschnitt betitelt „Denied-Tools“Eine Denied-Tools-Denylist benennt MCP-Tools (zum Beispiel app.deploy), die der
Run niemals aufrufen darf. Die effektive Denylist eines Runs ist die Vereinigung
der projektweiten Denylist und jeder aktivierten Automatisierungs-Denylist – ein von
einer zutreffenden Quelle verbotenes Tool ist für den Run gesperrt. Ein Verbot ist
hier absolut: Es übersteht eine gültige Deploy-Bestätigung und sogar den Regler auf
Stufe 100 (Entfesselt), denn die Prüfung greift, noch bevor der Tool-Handler je ein
Token zu sehen bekommt.
Umgebungs-Scope
Abschnitt betitelt „Umgebungs-Scope“Der Umgebungs-Scope beschränkt, auf welche Umgebungsklasse der Run wirken darf:
all (keine Einschränkung) oder eine von production, staging, development. Die
Deploy- und Migration-Tools gehören zur production-class – eine auf Staging oder
Development beschränkte Automatisierung kann sie nicht ausführen. Treffen mehrere
aktivierte Automatisierungen zu, setzt sich der engste konkrete Scope durch, sodass
ein Run nie außerhalb der strengsten konfigurierten Umgebung wirkt. Ein unbekannter
gespeicherter Scope fällt fail-closed auf den restriktivsten zurück (development).
Wie alles zusammenspielt
Abschnitt betitelt „Wie alles zusammenspielt“Für einen einzelnen dispatchten Backlog-Run greifen die Gates fail-closed in dieser
Reihenfolge: der Global-Dispatch-Notausschalter, der Onboarding-Modus, die
Ruhezeiten, die Workspace-Parallelitäts-Obergrenze, die Autonomiestufe bzw.
das Override des Projekts samt seinem dispatch_enabled-Band, der
Quota-Spielraum des Providers, die Budget-Notstopps und zuletzt – pro
Tool-Aufruf innerhalb des Runs – der Blast-Radius. Jedes Gate kann nur einengen,
was das vorige zugelassen hat; erweitern kann es keines.