Die Build-Pipeline
Ist eine Story verfeinert, bringt /we:orchestrate sie vom Plan zum überprüften Pull Request — weitgehend allein.
Was es ist
Abschnitt betitelt „Was es ist“/we:orchestrate ist der Lead. Er liest aus git und dem Ticket, wo die Arbeit steht, entscheidet, was jede Story als Nächstes braucht, schickt Worker zum Bauen los, die nur entwickeln, führt zusammen, was zurückkommt, auf einen Branch, und lässt die CI einmal über einen Pull Request laufen. Ein Worker fährt /we:develop: Er implementiert sein Stück, fährt die Gates, die er lokal fahren kann, committet, pusht und hört auf — kein PR, keine CI, kein Ticket-Übergang. Das ist Sache des Leads, einmal, über die zusammengeführte Arbeit aller.
Es gibt eine Pipeline mit drei Dispatch-Formen: ein Worker je Story (eine Ad-hoc-Aufstellung oder ein kleines Epic), Phasen-Dispatch über mehrere Worker für eine Story mit unabhängigen Phasen, oder --solo — niemand wird losgeschickt, der Lead baut die eine Story selbst. Zwischen den dreien unterscheidet sich nur, wer implementiert. Alles nach der Implementierung läuft gleich.
Warum es für dich wichtig ist
Abschnitt betitelt „Warum es für dich wichtig ist“Review, statische Analyse, Tests und CI für jeden Worker einzeln zu fahren, kostet bei N Workern das N-Fache an Review und das N-Fache an CI. Genau dafür gibt es den Integrationsbranch: N Worker kosten N Entwicklungsbudgets und einen CI-Lauf, nicht N. Du entscheidest weiterhin, was geschieht — der Lead hält an einem Bestätigungs-Gate an, bevor er irgendjemanden losschickt, und noch einmal an einer Decision Queue für alles, was wirklich eine menschliche Entscheidung braucht.
Wie du es nutzt
Abschnitt betitelt „Wie du es nutzt“Sobald die Worker ihre Branches gepusht haben, fährt der Lead jedes Mal dieselbe Folge:
- Integrieren — jeden Worker-Branch auf einen Integrationsbranch mergen. Ein Schritt, der eine echte Datenbank braucht oder Geld, Auth oder Mandantentrennung berührt, läuft auf der Seite des Leads, nicht im Wegwerf-Worktree eines Workers.
- Vereinfachen — ein Aufräumdurchgang über den zusammengeführten Diff: Wiederverwendung, toter Code, Bereinigung der Abstraktionsebene. Das läuft mit Absicht vor dem Acceptance-Criteria-Gate — gegen Code zu verifizieren, der gleich neu geschrieben wird, hieße, zweimal zu verifizieren.
- AC- und DoD-Gate — jedes Acceptance Criterion gegen einen konkreten Beleg geprüft (eine Datei, ein Test, ein Commit), und die Definition-of-Done-Tabelle ausgefüllt. Eine gerissene DoD-Zeile blockiert genauso wie ein gerissenes AC.
- Verifikation — die Änderung läuft gegen etwas Echtes, sie wird nicht aus grünen Tests erschlossen. Der Beleg wird in den Plan der Story selbst geschrieben.
- Quality Gates — die statische Analyse des Repos und die betroffenen Test-Suiten, einmal über den ganzen zusammengeführten Diff.
- Docs — ein Dokumentationsdurchgang liest den Diff und schlägt Änderungen vor. Ohne deine Freigabe landet nichts.
- PR — ein Pull Request wird für die ganze Welle geöffnet. Das ist auch der erste Moment, in dem die CI läuft.
- CI-Review — Befunde aus der CI und von den PR-Review-Bots werden gesammelt, sortiert, behoben und einmal gepusht; das Ticket wandert auf In Review.
Grenzen & Sonderfälle
Abschnitt betitelt „Grenzen & Sonderfälle“Zwei Mechanismen halten einen autonomen Lauf ehrlich. Checkpoints — ein benannter, dauerhafter Vermerk, welche der Schritte oben eine Story bestanden hat, hinterlegt in einer Zustandsdatei, damit ein unterbrochener Lauf fortsetzt statt von vorn zu beginnen. Ein Schutzschalter — scheitert derselbe Schritt dreimal hintereinander, hält die Pipeline an und fragt, statt sich festzufahren.
Die Pipeline ist autonom bis zum Pull Request und nie darüber hinaus. Claude öffnet ihn; du prüfst ihn, du mergest ihn, du schließt das Ticket — die Auslieferung bleibt mit Absicht bei Menschen. Nach deinem Merge erledigt /we:merged den mechanischen Abschluss: Worktrees und Branches abgebaut, Tickets auf Done, der Epic-Vermerk aufgefrischt. Von sich aus mergt oder veröffentlicht es nichts.
Es gibt keine eigene lokale Fehlerjagd vor dem PR. Diese Frage wird genau einmal gestellt, von den CI-Review-Gates des Repos am einen Pull Request, nicht von einem zusätzlichen Durchgang davor.