Der Arbeitsalltag: von der Idee zum Release.

11.1 Der Loop im Überblick

Die vorherigen Kapitel haben jeden Baustein einzeln erklärt. Im Alltag greifen sie ineinander. Das Leitbild der Fabrik fasst es in drei Sätzen: Du beschreibst. Die Fabrik baut. Du genehmigst. Dazwischen liegt ein Kreislauf, den du für jedes Feature wieder durchläufst:

Idee
  → Spec (Ziel, Nicht-Ziele, Akzeptanzkriterien mit IDs)
  → Spec-Freigabe (Mensch, ab MAINTAINER)
  → Plan-Run (plans/*.md mit Spec:/AC:-Bezug)
  → Backlog-Item aktivieren
  → Build-Run auf eigenem Branch
  → Validierung (Build) → ggf. Korrekturschleife
  → Quality Gate (Reviewer, inkl. Akzeptanzkriterien)
  → Freigabe vor Merge / Pull Request
  → Warum-Trace prüfen, Memory pflegen
  → Meilenstein-Release
  → nächste Idee

Zwei Dinge sind an diesem Kreislauf wichtig. Erstens: Es gibt bewusste Haltestellen, an denen ein Mensch entscheidet — die Spec-Freigabe, die Freigabe vor der Ausführung (ohne Approval-Policy der Default) und die Freigabe vor dem Merge (per Approval-Policy oder Compliance-Profil einzurichten). Zweitens: Zwischen den Haltestellen arbeitet die Fabrik selbstständig, einschließlich Korrekturen. Du musst einem Agenten nicht beim Tippen zusehen; du musst die Haltestellen ernst nehmen.

Grafik in voller Größe öffnenGrafik in voller Größe öffnen

11.2 Schritt 1: Die Idee schärfen

Unser Beispielprojekt ist MaintHub, das Wartungsauftrags-Portal aus dem Benutzerhandbuch: Spring-Boot-Backend mit REST-API unter /api/v1, React-Frontend, Rollen ADMIN und DISPONENT, hexagonale Architektur. Das Projekt existiert bereits, ein paar Build-Runs haben Auftrags-CRUD und Auftragsliste erzeugt.

Die Fachabteilung meldet sich: „Disponenten sollen Aufträge stornieren können.“ Das ist eine typische Idee — kurz, plausibel und voller ungeklärter Fragen:

• Darf jeder Auftrag storniert werden, auch ein bereits abgeschlossener?
• Wird ein stornierter Auftrag gelöscht oder bleibt er mit Status sichtbar?
• Braucht es einen Grund? Wer sieht ihn?
• Was passiert, wenn zwei Disponenten gleichzeitig stornieren?
• Darf ein Techniker stornieren?

Gibst du diese Idee unverändert als Run-Ziel an einen Agenten, beantwortet er jede dieser Fragen — still, nach eigenem Ermessen, an irgendeiner Stelle im Code. Die Engineering-Guardrails der Fabrik verlangen zwar, dass der Agent seine Annahmen offenlegt und die konservativste Interpretation wählt, aber das ersetzt keine fachliche Entscheidung. Deshalb ist der erste Schritt nicht der Run, sondern das Gespräch: Du klärst die Fragen mit der Fachabteilung oder notierst sie als offene Fragen.

Was du tust

• Fachliche Fragen sammeln und beantworten lassen.
• Festhalten, was ausdrücklich nicht dazugehört (z. B. „kein Wiederherstellen stornierter Aufträge in diesem Schritt“).
• Prüfen, ob die Idee in einen Lauf passt oder in mehrere Backlog-Items zerfällt.

11.3 Schritt 2: Die Spec schreiben

Aus den Antworten entsteht die Spec. Kapitel 4 hat Aufbau, EARS-Schablonen und typische Fehler ausführlich behandelt; hier nur das Ergebnis, kompakt:

---
id: SPEC-007
titel: Auftrag stornieren
version: 1
status: DRAFT
owner: Fachbereich Disposition
contracts: []
ersetzt: null
---

# SPEC-007 — Auftrag stornieren

## Ziel
Disponenten können offene Wartungsaufträge mit Begründung stornieren,
damit Fehlerfassungen und abgesagte Termine sauber aus der Planung
verschwinden, ohne die Historie zu verlieren.

## Nicht-Ziele
- Kein Wiederherstellen stornierter Aufträge.
- Keine Benachrichtigung von Technikern (eigene Spec).

## Akzeptanzkriterien
- **AC-007-01** — Wenn ein Nutzer mit Rolle DISPONENT einen Auftrag im
  Status OFFEN mit einem Grund von 10 bis 500 Zeichen storniert, dann soll
  das System den Status auf STORNIERT setzen und Grund, Nutzer und
  Zeitpunkt speichern.
- **AC-007-02** — Falls der Auftrag nicht im Status OFFEN ist, dann soll das
  System die Stornierung mit HTTP 409 ablehnen und den Status unverändert
  lassen.
- **AC-007-03** — Falls der Grund fehlt, kürzer als 10 oder länger als 500
  Zeichen ist, dann soll das System die Stornierung mit HTTP 400 und einer
  verständlichen Meldung ablehnen.
- **AC-007-04** — Falls ein Nutzer ohne Rolle DISPONENT oder ADMIN
  storniert, dann soll das System mit HTTP 403 ablehnen.
- **AC-007-05** — Das System soll stornierte Aufträge in der Auftragsliste
  standardmäßig ausblenden und über einen Filter anzeigen.

## Randfälle
- Zwei gleichzeitige Stornierungen desselben Auftrags: genau eine gewinnt,
  die zweite erhält 409.

## Offene Fragen
- (keine)

Beachte, was diese Spec leistet: Jedes Kriterium beschreibt Verhalten, nicht Implementierung. Grenzen sind konkret (10 bis 500 Zeichen, HTTP-Codes). Die Nicht-Ziele verhindern, dass der Agent „hilfsweise“ eine Wiederherstellung oder E-Mail-Benachrichtigung baut. Der Randfall mit der Gleichzeitigkeit ist notiert; du könntest ihn auch zu einem eigenen AC machen, wenn er abgenommen werden soll.

11.4 Schritt 3: Planen und das Backlog füllen

Fünf Akzeptanzkriterien klingen überschaubar, betreffen aber Domäne, Persistenz (neue Spalten oder eine Migration), REST-Schnittstelle, Berechtigungen und Frontend. Statt alles in einen Lauf zu packen, lässt du die Fabrik planen. Ein Plan-Run ändert keinen Produktivcode; er schreibt Vorschläge als Markdown unter plans/.

Ein guter Plan für dieses Feature könnte so aussehen:

Jede Plan-Datei nennt ihren Spec-Bezug in zwei Zeilen — genau so, wie Kapitel 5 es beschrieben hat:

Spec: SPEC-007
AC: AC-007-01, AC-007-02, AC-007-03, AC-007-04

11.5 Schritt 4: Bauen

Jetzt arbeitet der Agent. Für dich ist das die Phase, in der du am wenigsten tun musst — und in der es am meisten Versuchung gibt, einzugreifen. Widerstehe ihr. Was du stattdessen tust:

• Live-Logs überfliegen, nicht jede Zeile lesen. Auffällig sind Schleifen (der Agent liest immer wieder dieselbe Datei), Werkzeugfehler und Hinweise auf fehlenden Kontext.
• Nicht parallel im selben Workspace arbeiten. Pro Workspace schreibt immer nur ein Agent; deine eigenen Änderungen gehören in einen eigenen Branch oder warten.
• Bei echten Fehlentwicklungen abbrechen statt zuzusehen — und dann den Auftrag verbessern, nicht denselben Lauf neu starten.

Wenn der Build rot wird, ist das kein Grund zur Sorge. Genau dafür gibt es die Korrekturschleife: Die Fabrik gibt dem Agenten die Build-Ausgabe als neue Information und lässt ihn nachbessern. Erst wenn das wiederholt nicht gelingt, bist du gefragt.

11.6 Schritt 5: Das Quality Gate lesen

Ein grüner Build sagt: Der Code kompiliert, die vorhandenen Tests laufen. Er sagt nicht, ob der Code sicher ist, die Architektur einhält oder das Richtige tut. Dafür gibt es das Quality Gate. Im Alltag liest du sein Ergebnis wie einen Review-Kommentar einer erfahrenen Kollegin — mit derselben Mischung aus Vertrauen und Prüfung.

Was du prüfst

• Das Verdict: PASSED, WARNING, FAILED, SKIPPED oder ERROR. ERROR heißt: Ein Reviewer ist abgestürzt. Das ist nie ein stiller Pass, sondern ein Grund nachzusehen.
• Die Befunde nach Kategorie: Sicherheitsbefunde (z. B. SQL-Konkatenation, hartcodierte Schlüssel) und Architekturbefunde (z. B. eine geänderte bestehende Flyway-Migration) wiegen schwer.
• Die AC-Abdeckung (seit v0.38.0 automatisch geprüft vom Reviewer spec-conformance): Für jedes gebundene Kriterium muss mindestens ein Test existieren, der die AC-ID referenziert (Testname, Annotation wie @Spec("AC-007-02") oder Kommentar). Fehlt einer, ist das Kriterium nicht belegt.
• Ungedecktes Verhalten: Geänderte Produktivdateien, die keinem Kriterium zugeordnet sind, verdienen einen Blick — vielleicht hat der Agent „hilfsweise“ etwas mitgebaut, das in den Nicht-Zielen steht.

11.7 Schritt 6: Abnahme und Freigabe vor dem Merge

Das Gate ist grün. Jetzt kommt die Haltestelle, die am häufigsten unterschätzt wird: die menschliche Freigabe vor dem Merge. Sie entsteht nicht von selbst: Richte sie über eine Approval-Policy (/policies) oder ein Compliance-Profil mit Pflichtfreigabe VALIDATION ein; ohne sie wird nach grünem Gate direkt gemerged bzw. der PR eröffnet, und dein Review findet im PR statt. Sie ist kein Formalakt. Mit deiner Freigabe übernimmst du die Verantwortung für den Code — so, wie du sie bei einem Pull Request einer Kollegin übernehmen würdest.

Wie du einen Agenten-Diff liest

1. Erst die Spec, dann den Diff. Lies die Akzeptanzkriterien noch einmal, bevor du Code ansiehst. So prüfst du gegen den Auftrag, nicht gegen dein Gefühl.
2. Tests zuerst. Prüfe, ob die Tests das Verhalten der Kriterien wirklich festhalten. Ein Test, der nur „kein Fehler“ prüft, belegt nichts. Achte auf Negativ- und Grenzfälle (9 und 501 Zeichen beim Grund).
3. Dann die Produktivänderungen. Jede geänderte Zeile sollte sich auf ein Kriterium zurückführen lassen. Großflächige Umformatierungen, „Aufräumarbeiten“ in fremden Klassen oder neue Abhängigkeiten sind Warnzeichen.
4. Die Entscheidungsnotizen des Agenten lesen. Die Guardrails verlangen, dass er Annahmen und Abweichungen offenlegt. Steht dort etwas, das die Fachlichkeit berührt, gehört es zurück in die Spec.
5. Migrationen und Sicherheit besonders genau. Datenbankänderungen sind schwer rückgängig zu machen; Berechtigungsfehler sind die teuersten Fehler.

11.8 Schritt 7: Release und der nächste Durchlauf

Beide Items sind DONE. Für die Fachabteilung zählt erst die ausgelieferte Version. Ein Release bündelt abgeschlossene Arbeit, dokumentiert sie und markiert den Stand im Repository. Danach beginnt der Kreislauf von vorn — entweder mit der nächsten Idee oder mit einer Änderung an der Spec, weil die Fachabteilung nach den ersten Wochen doch einen Grundkatalog statt Freitext möchte.

Gerade dieser zweite Fall zeigt den Wert der Spec: Du änderst SPEC-007, eine neue Fassung entsteht, und der Vergleich auf der Spec-Detailseite zeigt schon heute, welche Kriterien neu, entfernt oder geändert sind. Seit v0.38.0 markiert die Fabrik nach der Freigabe zusätzlich offene Backlog-Items, die an ein geändertes oder entferntes Kriterium gebunden sind, als veraltet, setzt daran gebundene Workflow-Tasks auf WAITING_FOR_REPLAN und schreibt den Vergleich als SPEC_DRIFT in die Audit-Kette. Statt „irgendwas hat sich geändert“ hast du eine präzise Liste.

11.9 Anti-Patterns: so bitte nicht

Die folgenden Muster begegnen einem in fast jedem Team, das mit Agenten anfängt. Jedes hat eine einfache Gegenmaßnahme.

11.10 Checklisten für den Alltag

Vor dem ersten Run in einem Projekt

• Projektdefinition vollständig: Vision, Zielgruppe, Stack, Architektur, Sicherheit, NFRs, Git-Konventionen gefüllt; keine leeren Platzhalter in den generierten Artefakten.
• Artefakte gelesen: PROJECT.md, INSTRUCTIONS.md, AGENTS.md einmal durchgesehen.
• Team gewählt: passende Agentenrollen, bevorzugte Modelle bewusst gesetzt.
• Adapter und Auth-Modus geklärt: Abo nur für persönliche Nutzung, im Team API-Key oder Gateway.
• Sandbox entschieden: Container-Modus für Build-Runs, wenn Docker vorhanden.
• Gate-Modus gesetzt: mindestens advisory.
• Budget gesetzt (mindestens beobachtend) und Spec-Modus gewählt.
• Erst mit mock üben, wenn du den Ablauf noch nicht kennst.

Vor der Spec-Freigabe

• Ziel aus Nutzersicht formuliert, nicht als technische Aufgabe.
• Nicht-Ziele benannt.
• Jedes Kriterium hat eine ID, beschreibt ein Verhalten und ist prüfbar (keine vagen Wörter wie „schnell“, „benutzerfreundlich“).
• Negativ- und Grenzfälle abgedeckt.
• Keine offenen Fragen mehr im Abschnitt „Offene Fragen“.
• Fachlich bestätigt von jemandem, der nicht umsetzt.

Vor der Merge-Freigabe

• Gate-Verdict verstanden, kein ERROR ignoriert.
• Jedes gebundene AC durch einen Test belegt, Negativfälle inklusive.
• Keine Änderungen außerhalb des Auftrags (ungedecktes Verhalten geprüft, Nicht-Ziele respektiert).
• Migrationen und Berechtigungen gesondert geprüft.
• Entscheidungsnotizen des Agenten gelesen; fachliche Annahmen in die Spec zurückgespielt.
• Nicht der eigene Run, wenn Segregation of Duties gilt.

Nach dem Release

• Warum-Trace stichprobenartig geprüft: gebundene Spec-Fassung, Modell, Freigaben.
• Memory um Learnings ergänzt, veraltete Einträge entfernt.
• Backlog aufgeräumt: abgelehnte Pläne entfernt, veraltete Items neu bewertet.
• Kosten des Meilensteins in /analytics angesehen.
• Spec-Änderungen für die nächste Version als neue Entwurfsfassung begonnen.

11.11 Rollen im Teamalltag

Agenten verändern, wer was tut, nicht dass Verantwortung getragen werden muss. In der Praxis haben sich folgende Zuständigkeiten bewährt; sie lassen sich auf das Rollenmodell der Fabrik abbilden.

Daneben stehen die Agentenrollen in den Teams der Fabrik (Architect, Developer, Reviewer, QA, Security Reviewer, Documentation, Merge/Release). Sie beschreiben, mit welcher Mission und welchen Regeln ein Agent arbeitet — sie ersetzen keine der menschlichen Rollen oben, insbesondere nicht die Freigabe.

11.12 Wie es weitergeht

Du hast jetzt das theoretische und praktische Rüstzeug, um sinnvoll mit der Fabrik zu arbeiten. Wissen wird zu Können durch Wiederholung. Ein bewährter Weg:

1. Erster Durchlauf mit mock: Projekt per Assistent anlegen, Spec schreiben und freigeben, Plan-Run, Aktivierung, Build — ohne Kosten, um die Oberfläche kennenzulernen. Anleitung: Schnellstart und Tutorial.
2. Echter Adapter, kleines Feature: eine Spec mit drei bis fünf Kriterien, Spec-Modus LEICHT, Gate advisory. Ziel: Gate-Befunde lesen lernen.
3. Strenger werden: Spec-Modus STRENG, Gate blocking, Freigabe vor Merge mit Segregation of Duties.
4. Bestehendes Repo: ein eigenes Repository importieren und mit einer Spec für ein vorhandenes Verhalten beginnen.
5. Team und Betrieb: Rollen, Mandanten, Budgets und Policies einrichten (Administrationshandbuch).
6. Parallel und reguliert: die Workflow-Ebene (Kapitel 7) und Compliance-Profile mit Audit-Export und Offline-Verifier (Kapitel 9) ausprobieren.

Zum Nachschlagen: Benutzerhandbuch, Administrationshandbuch, FAQ und die bekannten Grenzen. Und wenn du ein Konzept auffrischen willst: Die Übersicht führt zu allen Kapiteln; besonders oft lohnt sich der Blick zurück in Kapitel 4 (Specs und EARS).

Kapitelfragen

Diese Fragen greifen auf den gesamten Kurs zurück. Wenn du sie sicher beantworten kannst, hast du das Wesentliche verstanden.

1. Nenne die Haltestellen im Loop, an denen ein Mensch entscheidet, und erkläre für jede, was ohne sie schiefgehen könnte.

   Musterantwort

   Spec-Freigabe: Ohne sie baut der Agent gegen nicht bestätigte Anforderungen, das Gate prüft gegen falsche Kriterien. Freigabe vor der Ausführung (Default ohne Approval-Policy): Ohne sie startet ein Agent ohne Zustimmung, z. B. mit falschem Ziel oder Adapter. Freigabe vor dem Merge: Ohne sie wäre Code im Base-Branch, bevor jemand zugestimmt hat — eine signierte Zusage wäre Fassade. In Workflows kommt die Planfreigabe hinzu.

2. Warum wird ein Backlog-Item erst DONE, wenn sein Build-Run gemerged ist, und nicht schon, wenn der Code geschrieben ist?

   Musterantwort

   Weil Nachfolger auf dem Base-Branch aufbauen. Ein Item, dessen Arbeit noch auf dem Run-Branch liegt (z. B. bei NEEDS_CORRECTION oder offenem PR), ist für abhängige Items nicht verfügbar. Ein vorzeitiges DONE würde Abhängigkeiten freigeben, die in Wahrheit noch nicht erfüllt sind.

3. Im Beispiel fehlte ein Test für AC-007-04. Beschreibe den Weg vom Befund bis zum korrigierten Stand und erkläre, warum das kein blinder Retry ist.

   Musterantwort

   spec-conformance meldet AC-007-04 als nicht durch einen Test referenziert. Im Spec-Modus STRENG ist das ein CRITICAL-Befund im blockierenden Gate und löst die Korrekturschleife aus; der erneute Lauf auf demselben Branch erhält den Befund als Feedback und liefert den Negativtest nach. Es ist kein blinder Retry, weil eine neue Information (der konkrete Befund) eingeht, die den zweiten Versuch gezielt anders macht.

4. Ein Agent ändert während eines Build-Runs specs/SPEC-007-…/spec.md und ergänzt ein Kriterium. Was passiert damit, und was ist deine Aufgabe?

   Musterantwort

   Die Fabrik übernimmt die Änderung nach dem Build als neue DRAFT-Fassung; sie wird nie automatisch freigegeben, und der laufende Run bleibt an die beim Start gebundene Fassung gebunden. Deine Aufgabe: den Entwurf prüfen, fachlich klären lassen und ihn — durch eine Person ab MAINTAINER — freigeben oder verwerfen.

5. Du sollst einen Pull Request eines Agenten freigeben. In welcher Reihenfolge liest du, und warum gerade so?

   Musterantwort

   Erst die Akzeptanzkriterien der Spec (Maßstab festlegen), dann die Tests (belegen sie das Verhalten inklusive Negativ- und Grenzfällen?), dann die Produktivänderungen (lässt sich jede Zeile auf ein Kriterium zurückführen?), dann die Entscheidungsnotizen des Agenten, mit Sonderblick auf Migrationen und Berechtigungen. So prüfst du gegen den Auftrag statt gegen dein Bauchgefühl und erkennst ungedecktes Verhalten.

6. Ein Kollege schlägt vor, das Quality Gate auf off zu stellen, weil der hallucination-reviewer zu viele Hinweise liefert. Was antwortest du?

   Musterantwort

   Mit off verschwinden auch Sicherheits-, Architektur-, Abhängigkeits- und Spec-Befunde. Besser: die Befunde verstehen (oft weisen sie auf echte Lücken wie fehlende Tests hin), den Auftrag oder die Spec präzisieren und notfalls advisory statt blocking verwenden. Ein Gate abzuschalten, weil es meldet, ist wie einen Rauchmelder abzuhängen, weil er piept.

7. Nach drei Wochen ändert die Fachabteilung SPEC-007: AC-007-03 bekommt einen Grundkatalog statt Freitext. Was zeigt dir die Fabrik nach der Freigabe der neuen Fassung, und was tust du?

   Musterantwort

   Der Vergleich auf AC-Ebene weist AC-007-03 als geändert aus; die Fabrik schreibt SPEC_DRIFT mit der betroffenen AC-ID in die Audit-Kette, markiert offene Backlog-Items, die an AC-007-03 gebunden sind, als veraltet und setzt daran gebundene Workflow-Tasks auf WAITING_FOR_REPLAN. Du planst daraufhin (Plan-Run oder neues Item) die Anpassung mit Bezug auf die neue Fassung; die Tests zu AC-007-03 werden angepasst.

8. Ein Prüfer fragt ein halbes Jahr später, warum die Stornierung ohne Benachrichtigung der Techniker gebaut wurde. Welche Spuren in der Fabrik helfen dir bei der Antwort?

   Musterantwort

   Die freigegebene Spec-Fassung mit dem Nicht-Ziel „Keine Benachrichtigung von Technikern“, ihre Freigabe (SPEC_APPROVED mit Version und Hash, wer und wann), der Warum-Trace der Build-Runs mit RUN_SPEC_GEBUNDEN (welche Fassung), die Commit-Trailer Spec:/Implements: und die Run-Freigaben. Bei Bedarf erzeugt ein Admin unter /export ein prüffähiges Bundle, das der Prüfer mit dem Offline-Verifier selbst prüfen kann.

9. Transfer: Dein Team will Routinen nutzen, damit jede Nacht ein Plan-Run und morgens Build-Runs laufen. Welche drei Voraussetzungen schaffst du vorher?

   Musterantwort

   Beispiel: (1) Budgets und Token-Limits, weil Automatik laufend Kosten erzeugt (Hard-Cap je Mandant). (2) Quality Gate auf blocking und Freigabe vor dem Merge, damit nichts ungeprüft in den Base-Branch gelangt. (3) Spec-Modus STRENG mit freigegebenen Specs, damit automatisch geplante Arbeit an bestätigte Anforderungen gebunden ist. Zusätzlich sinnvoll: Segregation of Duties und ein fester Zeitpunkt, an dem jemand die Freigaben abarbeitet.

10. Fasse das Leitbild „Du beschreibst. Die Fabrik baut. Du genehmigst.“ in eigenen Worten zusammen und ordne jedem Satz mindestens zwei Fabrik-Funktionen zu.

    Musterantwort

    Beschreiben: Projektdefinition und Assistent, Specs mit Akzeptanzkriterien, Memory, Guardrails. Bauen: Plan- und Build-Runs mit Adaptern, Branch je Run, Korrekturschleife, Quality Gate, Workflow-Ebene. Genehmigen: Spec-Freigabe ab MAINTAINER, Freigabe vor Ausführung und vor Merge mit Inline-Diff, Segregation of Duties, Warum-Trace und signierte Audit-Kette als Nachweis. Kern: Der Mensch verantwortet Was und Ob, die Fabrik das Wie — überprüfbar.