Spec-getriebene Lieferung

Bei der spec-getriebenen Lieferung wird das Verhalten deines Produkts aufgeschrieben, bevor es jemand baut — nicht als Prosa, sondern als strukturierte, versionierte Specs, die ein Gate prüfen kann. Agenten bauen dann kleine Ausschnitte, von denen jeder benannte Teile einer Spec nachweist, und eine Änderung wird gemergt, wenn jeder Check grün ist. Du bleibst dort in der Schleife, wo nur ein Mensch entscheiden kann: vor der Arbeit, nicht danach.

Diese Seite erklärt die Idee aus Sicht des Owners und sagt klar, welche Teile SupaCloud heute bietet. Um ein Projekt einzurichten, folge Ein spec-getriebenes Projekt betreiben.

Warum vorher entscheiden statt nachher freigeben

Wenn die einzige Definition eines Features ein Satz in einem Issue ist, hat ein Agent, der allein arbeitet, zwei Möglichkeiten: eine korrekte Hülle ohne das Verhalten bauen oder das Verhalten erfinden. Dich jedes Ergebnis nachträglich freigeben zu lassen, behebt das nicht — Freigaben wachsen mit jedem Pull Request, und ein Check, der bei jeder zweiten Änderung anschlägt, wird durchgewunken statt gelesen.

Spec-getriebene Lieferung zieht dein Urteil nach vorn. Du beantwortest die Designfragen einmal, gebündelt, mit einer Empfehlung vor Augen. Ab dann legt die Spec, nicht der Agent, fest, was „korrekt” heißt, und die Gates halten jede Änderung daran fest.

Die Ebenen

Ebene	Was sie enthält	Wer sie ändert
Anforderungen	was das Produkt bieten muss	du, selten
Domänen-Spec	wie sich ein Bereich verhält: Regeln, Parameter mit freigegebenen Bereichen, Beispiele, Entscheidungen, offene Rückfragen	ein Pull Request; du gibst die Designentscheidungen frei
Work Item	der nächste zu bauende Ausschnitt, mit den Regeln, die er nachweist	aus einer freigegebenen Spec abgeleitet
Agentenlauf	die Umsetzung	SupaCloud
Evidence	der Nachweis, dass die Änderung tut, was ihre Regeln verlangen	der Lauf
Merge	die Änderung auf deinem Haupt-Branch	nur wenn jeder Check grün ist

Eine untere Ebene ändert nie still eine obere. Findet ein Agent eine Lücke in einer Spec, fragt er — die Lücke wird eine Rückfrage und deine Antwort eine festgehaltene Entscheidung —, statt eine Annahme im Code zu verstecken.

Das Spec-Format weiß nichts über ein einzelnes Produkt. Eine kleine Datei in deinem Repository — das Projektprofil — sagt ihm, wo deine Anforderungen liegen, wie deine Anforderungs-IDs aussehen und welche Einheiten deine Zahlen verwenden. Das Format selbst muss also nie geändert werden, damit es zu deinem Projekt passt. Es gibt keinen Rückfall: Ohne diese Datei schlagen die Prüfungen fehl und sagen es, statt still die Konventionen von jemand anderem anzunehmen.

Die Entscheidungen, die bei dir bleiben

Nur fünf Arten von Änderungen brauchen dich. Alles außerhalb der Gate-Klassen wird bei Grün gemergt, nach den automatisierten Reviews, die seine Risikoklasse verlangt — du prüfst nicht jeden Pull Request.

Klasse	Du entscheidest, wenn	Beispiele
G1 Produkt- und Domänendesign	eine Spec freigegeben wird oder sich ein freigegebener Parameterbereich ändert	eine Preisregel, eine Spielmechanik, ein Budgetkorridor
G2 Architektur und Verträge	eine neue Architekturentscheidung oder eine brechende Vertragsänderung	eine API-Version, ein Datenformat
G3 Erste Sicht	die Stilgrundlage und jeder neue Screen, Flow oder jedes neue Asset	eine neue Einstellungsseite, ein neues Logo — Änderungen an bereits freigegebenen Screens beurteilt die Maschine gegen die freigegebene Version
G4 Sensible Inhalte	kuratierte Inhalte zu sensiblen Themen	eine Erzählung über psychische Gesundheit
G5 Release und Recht	Signatur, Store-Einreichung, Lizenzen, personenbezogene Daten, Pflichten als KI-Anbieter	ein Release, eine Änderung der Datenverarbeitung

Du entscheidest außerdem jede Änderung an der Gate-Karte selbst — der Datei, die festlegt, welche Pfade in welche Klasse fallen —, damit nichts ohne dich eine Klasse verlassen kann.

Security-Review-Klassen sollen ohne dich freigegeben werden: Eine neue Abhängigkeit (eine Versionserhöhung geht durch), CI-Workflows, Security-Werkzeuge, Secrets sowie Authentifizierungs- und Vertrauensgrenzen-Code gehen an einen automatisierten Security-Reviewer eines anderen Modellanbieters als dem, der die Änderung geschrieben hat. Sein zustimmendes Review genau dieses Commits gibt die Klasse frei; verlangt er stattdessen Änderungen, eskaliert der ganze Pull Request an dich und nur du kannst ihn freigeben. Dieser Reviewer ist geplant; bis es ihn gibt, brauchen auch diese Änderungen dich.

Diese Gates müssen halten, egal wie autonom das Projekt läuft. Auf der höchsten Autonomiestufe ist die Merge-Obergrenze von SupaCloud Vollautomatisch mergen, deshalb leben die Gates in deinem Repository: ein Pflicht-Check, den nur der Freigebende der Klasse grün macht, und zwar für genau den Commit, den er gesehen hat — ein neuer Push wird erneut geprüft. SupaCloud darf einschränken, was dieser Check erlaubt, nie erweitern.

In der Referenzimplementierung existiert dieser Check und ist heute auf ihrem Haupt-Branch erforderlich. Drei Details sollte man kennen, bevor man sich darauf verlässt:

Du kannst deinen eigenen Pull Request nicht freigeben — Forgejo lehnt das ab. Deshalb akzeptiert der Check auch einen Kommentar von dir, der den Commit nennt (/approve-gates <sha>), als deine Freigabe. Das ist ein Ausweg um eine Forge-Regel herum, kein zusätzliches Privileg.
Ein bearbeiteter Kommentar zählt nicht. Jeder mit Schreibrecht kann jeden Kommentar bearbeiten, ein bearbeiteter Text lässt sich also nicht als deiner belegen. Schreibe stattdessen einen neuen Kommentar.
Ein Instanz-Admin kann weiterhin am Branch-Schutz vorbei force-mergen. Das ist deine Notausstiegsluke — und der Grund, Admin-Zugänge von Agenten fernzuhalten.

Wie Entscheidungen zu dir kommen

Decision Briefs (geplant). Designentscheidungen kommen als ein Brief pro Domäne: jedes Element mit seinen Optionen, einer empfohlenen Option, der Begründung und Entwürfen, die die Wahl konkret machen — Tabellen, Diagramme, Vorher-nachher-Screenshots, Prototypen. Du antwortest auf einer Seite, auf jedem Gerät, und kannst gehen und wiederkommen, wie du willst.

Die Empfehlung ist vorausgewählt, damit du nicht tippen musst, aber eine vorausgewählte Antwort ist keine Antwort, bis du sie bestätigst — pro Element oder mit Alle offenen Empfehlungen übernehmen. Ein Element, das du nie angesehen hast, bleibt offen, so vernünftig sein Standard auch ist. Ein Brief kann nicht übergeben werden, solange ein blockierendes Element offen ist, und deine Antworten gehen per Pull Request in die decisions.yaml der Spec, wo sie festgehalten bleiben — mit wer, wann und wo.

Rückfragen während der Arbeit (verfügbar). Stößt ein Agent auf eine echte Lücke, fragt er mit question.ask, und du antwortest im Eingang oder auf der Telegram- oder Discord-Karte — siehe Einen Agenten nachfragen lassen. Das Item beim Warten zu parken, es mit deiner Antwort wieder aufzunehmen und die Antwort als Entscheidung in die Spec zurückzuschreiben, ist geplant.

Was ohne dich passiert

Die Review-Tiefe folgt der Risikoklasse. Die Merge-Leiter eines Projekts legt sie pro Work Item fest: Die unterste Klasse wird gemergt, sobald jeder Check grün ist; die nächste fügt einen unabhängigen Review-Agenten hinzu; die nächste braucht zwei unabhängige Reviews von verschiedenen Modellanbietern oder einen Menschen; die oberste Klasse führt ein Mensch. „Unabhängig” heißt ein anderer Anbieter als der, der den Code geschrieben hat, weil ein Prüfer dazu neigt, Ergebnisse seiner eigenen Modellfamilie zu bevorzugen.
Die Spec ist das Test-Orakel. Die Beispiele einer Spec kommen mit konkreten Werten, und die Tests werden aus ihnen generiert. Der Agent, der eine Regel umsetzt, entscheidet nicht auch, was sie nachweist.
Modelle werden durch Messung gewählt. Specs und Work Items nennen eine Fähigkeitsstufe — Flagship, Balanced, Fast, unabhängiges Review —, nie ein Modell. Der Kalibrator von SupaCloud entscheidet anhand gemessener Ergebnisse, welches Modell hinter jeder Stufe steht.
Bereitschaft ist eine Tatsache, keine Vermutung. Ein Work Item ist bereit, wenn die Arbeit, von der es abhängt, erledigt ist, die Entscheidungen, die es braucht, freigegeben sind und seine Spec freigegeben ist. Diese Tatsache steht als Labels in deinem Issue-Tracker — ready, blocked, spec-ready —, und SupaCloud dispatcht die spec-ready-Items. Genau ein System schreibt diese Labels: SupaCloud, über die Forge-Verbindung, die dein Projekt schon hat. Du brauchst keinen Bot-Account und kein Secret in deiner CI.

Was SupaCloud heute kann

Geprüft gegen den Code auf main am 22.09.2026. Geplant verweist auf das Design im Build-Brief Issue #1448.

Teil der Schleife	Stand	Heute
Agenten stellen echte Rückfragen; du oder der Koordinator antworten	Verfügbar	`question.ask` mit bis zu acht Optionen, beantwortet im Eingang oder auf einer Chat-Karte; siehe Einen Agenten nachfragen lassen
Eine wartende Frage parkt das Item und gibt seinen Slot frei; die Antwort nimmt es wieder auf und wird als Entscheidung zurückgeschrieben	Geplant (SC-10)	eine wartende Frage behält ihren Slot und hat keine Frist; die Antwort wird nicht ins Repository geschrieben
Decision Briefs	Geplant (SC-29)	keine; beantworte Designentscheidungen außerhalb von SupaCloud und halte sie per Pull Request in `decisions.yaml` fest
Nur `spec-ready`-Issues dispatchen	Geplant (SC-2)	SupaCloud liest keine Labels; sein Klassifikator entscheidet, welches offene Issue bereit ist
Bereitschaft aus deinen Specs berechnet und als Labels geschrieben	Geplant (SC-2, SC-20)	die Referenz-Synchronisation aus einer Owner-Sitzung ausführen (siehe die Anleitung)
Merge nur, wenn die Pflicht-Checks deiner CI grün sind	Geplant (SC-1)	ein Merge folgt den eigenen Gates von SupaCloud — dem unabhängigen Audit und, bei Web-Änderungen, dem visuellen Check; die Checks deines Repositorys werden nicht gelesen
Zwei unabhängige Reviews von verschiedenen Anbietern	Geplant (SC-4)	ein Review-Slot; ein Council kann eine Empfehlung ergänzen, kein Gate
Ein automatisierter Security-Reviewer gibt die Security-Review-Klassen frei	Geplant (SC-4, SC-3)	keiner; Änderungen dieser Klassen brauchen einen Menschen
Arbeit nach Fähigkeitsstufe geroutet	Geplant (SC-3)	der Kalibrator pflegt Tier-Ketten; ein Agent-Profil legt ein Modell fest, lernt eines aus der Historie oder überlässt es dem Runner
Specs validiert, nachverfolgt und in der Web-Oberfläche angezeigt	Geplant (SC-20)	nichts; die Validierung läuft in der CI deines Repositorys
Visuelle Freigabe nur für neue Screens und auch außerhalb von Web-Code	Geplant (SC-9)	das visuelle Gate (off, machine, human, both) greift bei Web-Änderungen; siehe Visual-Verify-Gates konfigurieren