Modul 5
Agentic Software Development:
Der End-to-End-Phasen-Workflow
Tag 2 · ca. 150 Minuten · Kernmodul
Lernziel Modul 5
Der Teilnehmer kann den kompletten Phasen-Workflow von Analyse bis
Deploy mit Gates und Artefakten
aufsetzen und durchführen.
Drei Wörter tragen das Modul: Phase — wo bin ich?
Artefakt — was liegt vor? Gate —
wer lässt mich weiter?
Inhalt
Warum Phasen?
Die Begründung aus Modul 1 — sonst wirkt alles wie Bürokratie
Der Kern-Workflow
Analyse → Review → Planung → Umsetzung → Test → Deploy
Das 2D-Modell
Phasen kreuzen Truth-Baselines
Projektwahl & Plan Mode
Der billigste Ort zum Eingreifen
Spec-driven Development
Die Spec ist die Wahrheit, der Task ist das Delta
Brainstorming & Alignment
Missverständnis vor dem Code fangen
Auto Research
Verstehen, bevor man löst
Vertical Slicing
Dünne Scheibe statt ganzer Schicht
Refactoring & Atomic PRs
Warum Halb-Architektur verboten ist
Parallel Agent Development
Mehrere Agenten, ein Repo
Agentic SDLC vs. Programs
Zwei Dinge, ein Wort
Große Übung
Ein Feature durch alle Phasen
Warum überhaupt Phasen und Gates?
Rückgriff auf Modul 1
1Nicht-deterministisch — zweimal dieselbe Aufgabe heißt zweimal ein anderer Weg. Der Weg ist nicht wiederholbar, also nicht prüfbar.
2Stateless — zwischen zwei Sessions bleibt nichts. Was nur im Chat stand, existiert morgen nicht mehr.
3Agent-Schleife — der Agent handelt selbstständig weiter. Ein Irrtum in Runde 2 wird in Runde 7 zur ausgebauten Fehlarchitektur.
Man kann dem Weg nicht trauen und sich auf das
Gedächtnis nicht verlassen. Also braucht man etwas anderes,
das trägt.
Die Antwort: Zwischenstände verankern
Wenn der Weg nicht reproduzierbar ist, muss man die
Zwischenstände festhalten — und zwar so, dass ein
Mensch sie in Minuten beurteilen kann.
Ein langer Lauf
Prompt rein, 40 Minuten Agent, 60 geänderte Dateien raus.
Prüfbar erst am Ende — und dann nur noch als Ganzes.
Fehler aus Minute 3 sind in Minute 40 einbetoniert.
Eine Kette von Phasen
Jede Phase endet mit einem lesbaren Artefakt.
Jedes Artefakt hat ein Gate: freigegeben oder nicht.
Der Fehler aus Minute 3 wird in Minute 4 gefunden.
Der Phasen-Workflow ist kein Prozess-Fetisch. Er ist die einzige bekannte
Antwort auf „der Weg ist nicht überprüfbar".
Was ein Artefakt ist — und was nicht
Artefakt
Liegt im Repo, hat einen Dateinamen, landet im Diff.
Ist in wenigen Minuten lesbar — Markdown, Testlauf, PR.
Hat ein Abnahmekriterium: ja oder nein, nicht "gefällt mir".
Überlebt /clear, den Feierabend und den Personenwechsel.
Kein Artefakt
"Der Agent hat mir das im Chat erklärt."
Eine 400-Zeilen-Zusammenfassung, die niemand liest.
Ein Plan, der nur im Kontextfenster existiert.
Ein grünes Häkchen ohne Testausgabe dahinter.
Faustregel: Wenn es nicht im Diff auftaucht, ist es
kein Artefakt — es ist eine Erinnerung.
Was ein Gate ist
Ein Gate ist eine Stelle, an der der Fortschritt
anhält, bis jemand das Artefakt der Phase abgenommen hat.
Agent-Gate
Ein Review-Subagent mit sauberem Kontext prüft das Artefakt gegen feste Kriterien. Skaliert, ermüdet nicht.
Mensch-Gate HUMAN
Ein Mensch entscheidet. Pflicht überall dort, wo die Entscheidung nicht rückholbar ist.
Mechanisches Gate
Test, Build, Lint, Hook. Kein Urteilsvermögen, dafür unbestechlich und gratis.
Regel: Je irreversibler der nächste Schritt, desto menschlicher
das Gate. Ein Deploy in Produktion ist immer ein Mensch-Gate.
Die Kette
1Analyse — das Problem verstehen, bevor eine Lösung existiert. Artefakt: Problem-Statement / Research-Notiz.
GATE Analyse-Review — ist das das richtige Problem? Ist die Done-Definition überhaupt prüfbar?
2Planung — Design und Zerlegung in Phasen. Artefakt: Spec / RFC mit Implementation-Checklist.
GATE Design-Freigabe — trägt das Design? Ab hier ist Code erlaubt, vorher nicht.
3Umsetzung — eine Phase, nicht das ganze RFC. Artefakt: Code + Tests im Diff.
GATE Self-Review / Code-Review — Diff gelesen, Konventionen geprüft, Doku nachgezogen.
4Test — lokal und in CI. Artefakt: grüner Lauf, nicht die Behauptung eines grünen Laufs.
GATE CI grün — mechanisch, unbestechlich, nicht verhandelbar.
HUMAN Deploy-Gate — der Mensch entscheidet. Immer. Ohne Ausnahme.
5Deploy & Closeout — ausrollen, verifizieren, Spec fortschreiben. Artefakt: laufende Version + aktualisierte Doku.
Phase × Artefakt × Gate
| Phase | Artefakt (reviewbar) | Gate | Wer |
|---|
| Analyse | Problem Statement, Research-Notiz | Analyse-Review | Agent + Mensch |
| Planung / Design | Spec / RFC, Detailed Design | Design-Freigabe | Mensch |
| Zerlegung | Implementation-Checklist (P1…Pn) | Plan-Review | Mensch |
| Umsetzung | Diff: Code + Tests + Doku | Self-Review | Agent |
| Test | Testlauf-Ausgabe, CI-Run | Grün / rot | Maschine |
| Deploy | Version in Produktion | Deploy-Freigabe | Mensch |
| Closeout | Fortgeschriebene Spec | Closeout-Review | Agent + Mensch |
Probe für jede Phase: Kann ich benennen, was am Ende auf der Platte
liegt? Wenn nicht, ist es keine Phase — es ist eine Hoffnung.
Das 2D-Modell — der eigentliche Bauplan
Zwei Dimensionen, nicht eine
Die Phasen-Kette allein ist zu wenig. Jeder Task lebt in
zwei Dimensionen:
Horizontal — der Task
Der zeitliche Lebenszyklus eines Features:
Analyse → Design → Implement → Test → Deploy → Run.
Beginnt, läuft durch, endet. Vergänglich.
Vertikal — die Baselines
Die stehenden Wahrheiten pro Domäne: Requirements,
Architektur, Code-Konventionen, Test-Framework, Betrieb.
Existieren über allen Tasks. Dauerhaft.
Ein Task respektiert die Baselines und schreibt sie
als Delta fort — er erfindet sie nicht neu.
Am Kreuz sitzt das Gate
| Horizontale Phase | Vertikale Baseline (Truth) | Delta-Artefakt | Gate / Review |
|---|
| Analyse | Requirements / Produktrahmen | Problem Statement / Research | Analyse-Review |
| Design | Architektur & Domain-Modelle | Proposed / Detailed Design | Design-Gate + Design-Review |
| Implement | Code-Konventionen (Rules) | Code | Self-Review |
| Test | Test-Strategie & Testdaten | Tests | Test-Layer-Check |
| Deploy | Release- & Prod-Safety | Deploy | Deploy-Gate HUMAN |
| Run | Betrieb / Operational Readiness | Prod-Zustand | Closeout + Op-Readiness |
Jede horizontale Phase kreuzt genau eine vertikale Baseline.
An diesem Kreuz sitzen das Delta-Artefakt und das
Gate. Das ist der ganze Bauplan.
Tabelle sinngemäß nach RFC-223 („Spec-Driven-Workflow-Hardening") aus dem
CGS-Projekt cgsit-finance — dort real im Einsatz.
— geprüft am 2026-07-21
Ehrlichkeit als Teil des Modells
„Der volle 4-Schicht-Stack ist unsere eigene Synthese —
von keinem der beiden Frameworks als Standard belegt
(bewusste Design-Wette, kein Industrie-Standard)."
— RFC-223, Abschnitt „Benchmark-Verdikt 2D", 2026-07-01
Extern belegt ist nur ein Teil: die Trennung Truth/Delta
(OpenSpec trennt specs/ von changes/) und die
horizontale Pipeline (QRSPI). Die geschichtete Vertikale
über alle fünf Ebenen ist eine eigene Wette.
Warum das auf die Folie gehört: Ein Prozess, der seine eigenen unbelegten
Stellen benennt, ist korrigierbar. Einer, der sich als
Standard ausgibt, ist es nicht.
Projektwahl — wo fängt man an?
Gut geeignet für den ersten Durchlauf
Ein Projekt mit lauffähigem Build und Tests — das
mechanische Gate muss existieren.
Überschaubarer Umfang, damit der Agent das System
erfassen kann.
Ein echtes, kleines Feature mit klarem Abnahmekriterium.
Ein Bereich, in dem ihr das Urteil habt — ihr sitzt an den Gates.
Schlecht für den ersten Durchlauf
Kein Test, kein Build — dann gibt es nichts, was objektiv grün wird.
Der kritischste Produktionsdienst — falscher Ort zum Üben.
Ein Feature, dessen Fachlichkeit noch verhandelt wird.
„Alles auf einmal migrieren" — kein Gate ist je erreichbar.
Der erste Durchlauf soll den Workflow beweisen, nicht das
Projekt retten. Kleines Feature, vollständige Kette.
Plan Mode
Claude Code kennt einen Modus, in dem der Agent
recherchiert und plant, aber nichts schreibt.
Am Ende steht ein Plan, den man annimmt oder ablehnt.
1Planen lassen — der Agent liest, sucht, versteht. Keine Datei wird verändert.
GATE Plan REVIEWEN — nicht überfliegen. Lesen, korrigieren, ablehnen.
2Dann erst Code — und zwar gegen den freigegebenen Plan, nicht gegen die ursprüngliche Idee.
Der Plan ist der billigste Ort zum Eingreifen. Ein falscher
Satz im Plan kostet 20 Sekunden. Derselbe Fehler in 30 Dateien kostet einen Tag.
Die konkrete Bedienung (Tastenkürzel zum Moduswechsel, Berechtigungs-Modi)
ändert sich mit den Versionen — vor dem Kurs live prüfen und in der
Session zeigen. — geprüft am 2026-07-21
Wie man einen Plan wirklich reviewt
1Löst er das richtige Problem? Nicht: ist er gut geschrieben. Plausible Prosa ist gratis.
2Nennt er konkrete Dateien? Ein Plan ohne Pfade ist ein Aufsatz, kein Plan.
3Passt er zur bestehenden Architektur? Oder baut er stillschweigend eine zweite daneben?
4Steht drin, wie man es prüft? Welcher Test, welcher Endpunkt, welche Ausgabe — vor dem Code, nicht danach.
5Ist er zerlegt? Phasen, die einzeln lauffähig sind — oder ein Block „dann bau ich das halt".
6Was fehlt? Die teuersten Planfehler sind Auslassungen, keine falschen Sätze.
Die Spec ist die Wahrheit
Spec-driven Development heißt: nicht der Code ist die
maßgebliche Beschreibung des Systems, sondern eine gepflegte
Spezifikation — und jede Änderung ist ein
Delta dagegen.
Truth (steht)
Requirements-Doku, Architektur-Doku, Domain-Modelle mit ihren
Invarianten.
Wird nur durch abgeschlossene Deltas fortgeschrieben.
Delta (vergeht)
Der einzelne RFC / die einzelne Spec für dieses eine Vorhaben.
Sagt explizit: was kommt neu, was ändert sich, was fällt weg.
Nach dem Deploy wird das Delta zurück in die Truth gemerged.
Passiert das nicht, driftet die Doku — und der Agent baut ab morgen
gegen eine Lüge.
Das Herzstück jeder Spec: die Done-Definition
Done ist nicht „Checkliste abgehakt". Done ist:
„die Eigenschaft, die die Spec versprochen hat, existiert in Produktion"
— plus etwas, das das beweist.
| Typ | Done-Definition | Beweis |
|---|
| Feature | „User kann X tun" | E2E-Test, der X verifiziert |
| Refactor | „Bug-Typ Y ist strukturell unmöglich" | Test, der Y aktiv ausschließt |
| Migration | „Alter Zustand weg, neuer zu 100 % abgedeckt" | Query, die es beweist |
| Cleanup | „Symbol existiert nicht mehr" | grep zeigt 0 Treffer |
Wer die Done-Definition nicht ausformulieren kann, hat kein Planungsproblem
— er hat ein Verständnisproblem. Der Code wird es
nicht lösen.
Typ-Tabelle sinngemäß aus CLAUDE.md / docs/rfcs/TEMPLATE.md
des CGS-Projekts cgsit-finance, Abschnitt „RFC Planning Discipline".
— geprüft am 2026-07-21
Das Design-Gate — „Brain Surgery Moment"
Ein Haken in der Spec: „Design freigegeben — ab hier ist Code
erlaubt." Vorher: null Zeilen Code.
An dem Punkt, an dem das Design fertig und noch kein Code
geschrieben ist, ist eine Korrektur fast gratis. Jede Minute später
wird sie teurer.
2026-05-26 — RFC-184 (cgsit-finance)
Ein Architektur-Refactor wurde geplant, dann in „MVP + Cleanup follow-up"
zerlegt und nur zur Hälfte umgesetzt. Vier Tage später erzeugte genau diese
Halb-Architektur den Privacy-Bug, den der RFC hätte verhindern sollen.
Das war kein Code-Bug — das war ein Planungs-Prozess-Bug.
Konsequenz: das Design-Gate ist seither Pflicht bei Refactor, Migration und
allem, was Privacy, Geld oder Mandantengrenzen berührt.
Brainstorming, Planning & Alignment
Drei Gespräche, nicht eins
Brainstorming
Divergent. Optionen sammeln, Annahmen aussprechen, Alternativen bewerten lassen — ohne dass schon eine Lösung feststeht.
Planning
Konvergent. Eine Option wird gewählt, zerlegt und mit Prüfkriterien versehen. Ergebnis ist ein Artefakt.
Alignment
Bestätigend. „Habe ich dich richtig verstanden?" — bevor gebaut wird, nicht nachdem deployed wurde.
Der häufigste Fehler: alle drei in einem Prompt. Der Agent
springt dann sofort zur Lösung — und die Optionen wurden nie erwogen.
Alignment als Pflicht-Schleife
Eine Spec hat eine formale Abnahme. Eine spontane Zuruf-Aufgabe
hat keine — also ersetzt eine kurze Bestätigungsschleife
die fehlende Abnahme.
1Verstanden: ein bis zwei Zeilen, was der Agent aus der Eingabe gelesen hat.
2Plan: was konkret geändert wird — Dateien, Verhalten, betroffene Ansichten.
HUMAN Auf OK warten — außer der Mensch sagt ausdrücklich „mach einfach".
2026-06-09 — cgsit-finance
Mehrere Änderungsrunden an einer Ansicht liefen ohne diese Schleife.
Ergebnis: eine doppelte Box und ein Zugriffs-Bug fielen erst
nach dem Deploy auf.
Seither ist der Understanding-Loop für alle Nicht-Spec-Eingaben
Pflicht, die zu Commit oder Deploy führen. Ausgenommen: Tippfehler und
Einzeiler — sonst wird jede Kleinigkeit zum Projekt.
Auto Research & Context-Isolation
Vor dem Design ein eigener Research-Schritt — in einem
Subagenten mit sauberem Kontext, dessen Auftrag bewusst
keine Lösungsrichtung enthält.
Research-Auftrag — ohne Lösungs-FramingUnderstand subsystem X. List facts, constraints, invariants and options.
Do NOT propose a solution. Cite file:line for every claim.
Gegen „completion bleed": Liegt das Ticket im Kontext, baut
der Agent die naheliegende Lösung, bevor er das System verstanden hat.
Der teure Denkfehler passiert dann vor dem Design — nicht als
halb gebaute Lösung.
Bei CGS als optionaler Schritt für als „komplex" markierte Vorhaben verdrahtet
(RFC-223 P2, cgsit-finance); Output ist eine Research-Notiz, die
ins Design einfließt. — geprüft am 2026-07-21
Bauen: Slicing, Atomic PRs, Parallelität
Vertical Slicing
Horizontal — Schicht für Schicht
„Erst alle Entitäten, dann alle Services, dann alle Endpunkte, dann das UI."
Nichts ist lauffähig, bis alles fertig ist.
Kein Gate ist erreichbar — es gibt monatelang nichts abzunehmen.
Der Integrationsfehler zeigt sich ganz am Schluss.
Vertikal — dünne Scheibe
„Ein Anwendungsfall durch alle Schichten:
Endpunkt, Service, Persistenz, Test."
Nach jeder Scheibe läuft etwas und ist vorführbar.
Jede Scheibe hat ihr eigenes Gate und ihren eigenen Test.
Der Integrationsfehler zeigt sich in der ersten Scheibe.
Prüffrage für jede Scheibe: „Ist dieses Paket für sich allein
deploybar und umkehrbar?" Wenn nein — mit dem nächsten
zusammenlegen, nicht einzeln ausliefern.
Refactoring & Atomic PRs
Bei Features ist Aufteilen gut — jede Scheibe liefert
Nutzen. Bei Refactorings ist Aufteilen gefährlich.
| Typ | Wert ist… | Aufteilen in mehrere Deploys? |
|---|
| Feature | neue sichtbare Funktion | ja — jede Phase liefert für sich Nutzen |
| Refactor | eine strukturelle Eigenschaft | nein — atomarer Deploy Pflicht |
| Migration | Daten-/API-Wandel | nur mit Rollback-Plan und dokumentierten Zwischenzuständen |
| Cleanup | toter Code, Doku, Tests | ja, trivial |
Regel aus RFC-184 — cgsit-finance, CLAUDE.md §3
„Bei Architektur-Refactors ist die Halb-Architektur strikt schlechter
als die alte komplette Architektur — sie hat alle Risiken beider
Welten gleichzeitig." Belegt: Backend-Schicht getrennt, Frontend nicht getrennt
→ der Bug-Typ bestand in der Vermittlungsschicht weiter.
Verboten sind seither: „Backend zuerst, Frontend später",
„MVP jetzt, Cleanup als Folge-Ticket", „Phase 1 deployt, Phase 2 anderes Ticket".
Wenn die Zeit nicht reicht: Umfang kürzen, nicht halb umsetzen.
Parallel Agent Development
Mehrere Agenten gleichzeitig — sinnvoll, wenn die Arbeitspakete
wirklich unabhängig sind.
Parallelisiert gut
Lesende Arbeit: Recherche, Code-Analyse, Review —
mehrere Subagenten, getrennte Kontexte, kein Konflikt.
Getrennte Arbeitsbäume: ein Branch/Worktree pro Agent
für wirklich disjunkte Features.
Unabhängige Testsuiten nebeneinander.
Parallelisiert schlecht
Zwei Agenten in einem Arbeitsbaum — sie
überschreiben sich gegenseitig.
Aufgaben mit gemeinsamer Schnittstelle — beide ändern denselben
Vertrag, keiner weiß es.
Ressourcenhungrige Läufe gleichzeitig (Builds, Container).
2026-07-01 — cgsit-finance
Parallele Container-Builds ließen die Entwicklungsmaschine regelmäßig in den
Speicher laufen. Statt einer Konvention wurde ein Hook
eingebaut, der einen zweiten gleichzeitigen Build hart blockiert.
Wo Parallelität nachweislich schadet, hilft keine Regel im
Dokument — nur eine Sperre, die der Agent nicht umgehen kann.
Agentic SDLC vs. Agentic Programs
Agentic SDLC
Der Entwicklungsprozess ist agentisch: Agenten
analysieren, planen, bauen, testen und reviewen — entlang von Phasen
und Gates.
Das Produkt ist ganz normale Software.
Gates schützen das Repository.
Darum geht es in diesem Kurs.
Agentic Programs
Das Produkt selbst enthält Agenten: es plant, ruft
Werkzeuge auf und handelt zur Laufzeit beim Anwender.
Der Entwicklungsprozess kann dabei klassisch sein.
Gates schützen den Anwender in Produktion.
Eigene Disziplin — nicht Gegenstand dieses Kurses.
Beides heißt „agentic" und wird ständig verwechselt. Wer die Begriffe
mischt, diskutiert im Team aneinander vorbei — besonders wenn es um
Sicherheit und Haftung geht.
Begriffsabgrenzung nach dem Kurs-Curriculum; die Branche benutzt „agentic"
uneinheitlich. Im Zweifel im eigenen Team einmal definieren und aufschreiben.
— geprüft am 2026-07-21
Der Beleg: ein real gelebter Workflow
Der CGS-Workflow — verdichtet
1Plan / Clarify — bei unklarem Umfang zuerst nachfragen. (Sub-Schritt 1b: Understanding-Loop bei Zuruf-Aufgaben)
2Spec oder Ticket? — Entscheidungstabelle: neues Feature/Architektur → RFC, kleiner Fix → Ticket.
2a · GATE Analyse-Review (Draft → Accepted): richtiges Problem? Done-Definition prüfbar? Test-Strategie vorgesehen?
3Spec / Konzept — Architektur- und Domain-Dokumente zuerst lesen, dann das Fach-Dokument fortschreiben.
3a · GATE Design-Freigabe + Design-Review — 0 Code davor. Haken nicht gesetzt → das Werkzeug warnt.
4–5Implementieren + lokal verifizieren — Code und Tests zusammen, Test-Ebene nach Entscheidungsmatrix.
6Checkliste nachziehen (6a: Doku-Pflichten gegen die geänderten Pfade prüfen — gleicher Commit; 6b: Migrations-Sicherheitscheck)
7b · GATE Self-Review (Pflicht) — feste Checkliste; in sensiblen Bereichen zusätzlich ein Review-Subagent vor dem Commit.
8–11Commit → Push → CI — Push autonom, CI ist das mechanische Gate. Wartezeit für den lokalen Rauchtest nutzen.
13 · HUMAN Vor dem Deploy immer fragen — Datenbank-Backup davor, wenn Migrationen dabei sind.
14Deploy + verifizieren (14a: Betriebsbereitschafts-Check — Alarme, Metriken, Fehlermuster, Betriebsdoku)
15a · GATE Closeout-Review — Done-Definition erfüllt? Bug-Typ strukturell unmöglich? Spec fortgeschrieben? Bei Nein: Status bleibt offen.
Verdichtung des Abschnitts „Development Workflow (the canonical lifecycle)" aus
CLAUDE.md des CGS-Projekts cgsit-finance —
dort 15 Haupt- plus 8 Unterschritte. Die Vollversion und der Vergleich
mit QRSPI/BMAD/OpenSpec kommen in Modul 6. — geprüft am 2026-07-21
Wann der volle Ablauf zu viel ist
Die ehrliche Kehrseite: nicht jede Änderung verdient die volle Kette.
Voller Ablauf
Mehrere Module betroffen, neue Architektur, Migration, Refactoring.
Sensible Bereiche: Geld, Rechte, personenbezogene Daten, Mandantengrenzen.
Etwas, das ihr in sechs Monaten noch verstehen müsst.
Abgekürzt
Ein bis zwei Dateien, klarer Umfang, keine Wirkung über das Modul hinaus:
Ticket, machen, ausliefern.
Tippfehler, Beschriftung, Formatierung.
Die Disziplin besteht darin, zu merken, wann man die Grenze
überschreitet — nicht darin, jeden Tippfehler zum Projekt
zu machen.
Ein Prozess, den alle umgehen, ist schlechter als ein kleinerer, den alle
einhalten. Die Zeremonie-Falle ist ein eigenes Thema in
Modul 6.
Modul 5 in fünf Sätzen
1Weil der Weg nicht prüfbar ist, verankert man Zwischenstände als reviewbare Artefakte.
2Jede Phase hat genau ein Artefakt und genau ein Gate — sonst ist sie keine Phase.
3Der Task läuft horizontal, die Wahrheiten stehen vertikal; am Kreuz liegt das Delta.
4Der Plan ist der billigste Ort zum Eingreifen — die halb gebaute Architektur der teuerste.
5Jede Regel braucht einen datierten Auslöser. Regeln ohne Vorfall werden nicht befolgt.
Wer nur eine Sache mitnimmt: Nenne für jede Phase das Artefakt, das
am Ende auf der Platte liegt. Alles andere folgt daraus.
Übung 5 — Ein Feature durch alle Phasen
Aufgabe
Baut am Beispielprojekt seminar-api (Quarkus — Seminare und
Buchungen) ein Feature im vollen Phasen-Workflow. Vorschlag:
„Eine Buchung kann storniert werden; ein storniertes Seminar gibt seinen
Platz wieder frei."
Pflicht — ein Artefakt pro Phase, jede Phase mit Gate:
- Analyse →
analysis.md — Problem, Fakten mit file:line, offene Fragen. Gate: richtiges Problem?
- Planung →
spec.md mit Done-Definition und Phasen P1…Pn. Gate: Design freigegeben — ab hier Code.
- Umsetzung → Diff einer vertikalen Scheibe (Endpunkt → Service → Persistenz). Gate: Self-Review, Diff gelesen.
- Test → Ausgabe von
mvn test. Gate: grün, nicht behauptet-grün.
- Deploy-Ersatz → Commit auf einem Branch. Gate: Mensch gibt frei.
- Closeout →
spec.md fortgeschrieben. Gate: Done-Definition wirklich erfüllt?
Verifizierbares Ergebnis: Sechs Artefakte liegen im Repo
— eins pro Phase — und mvn test ist
grün. Jedes Gate ist im jeweiligen Artefakt sichtbar
abgehakt, mit Datum.
Dauer ca. 45 Minuten · Zweierteams — einer prompted, einer sitzt an den Gates · nach der Hälfte tauschen
© 2026 CGS IT Solutions GmbH
Alle Rechte vorbehalten
Diese Schulungsunterlagen sind urheberrechtlich geschützt. Vervielfältigung,
Weitergabe oder kommerzielle Nutzung — auch in Auszügen — nur mit
ausdrücklicher schriftlicher Genehmigung der CGS IT Solutions GmbH.
cgsit-claude-training · Modul 5 · v0.1.0
