Orchestrator/bahn/O2C-Harness/requirements-review.md

Requirements-Review (vor Implementierung)

Ablauf bei Issue-basierter Aufgabe

Wenn die Aufgabe als GitLab Issue übergeben wird (statt Freitext):

1. Issue lesen und analysieren

glab issue view {issue-id} --repo {repo}

2. Anforderung kritisch reviewen

Prüfe ob folgende Fragen beantwortet sind:

Fachlichkeit:

• Ist die Domäne/der Fachkontext verstanden?
• Gibt es Fachbegriffe die unklar sind?
• Welche Business-Regeln gelten?
• Gibt es Abhängigkeiten zu anderen fachlichen Prozessen?

Funktional:

• Was genau soll das System tun?
• Wer sind die Nutzer?
• Welche Ein-/Ausgaben gibt es?
• Welche Edge Cases gibt es?

Nicht-funktional:

• Performance-Anforderungen (Response-Zeit, Concurrent Users)?
• Verfügbarkeit?
• Security-Anforderungen?

Technisch:

• Stack/Framework vorgegeben?
• Schnittstellen zu anderen Systemen?
• Deployment-Ziel?

Akzeptanzkriterien:

• Sind Gherkin-Szenarien vorhanden?
• Wann ist die Aufgabe "fertig"?

3. Offene Fragen als Kommentar am Issue

Wenn Informationen fehlen → Kommentar am Issue mit konkreten Fragen:

glab issue comment {issue-id} --repo {repo} --body "## Offene Fragen zur Anforderung

Bevor ich mit der Implementierung beginne, bitte folgende Punkte klären:

1. **Performance:** Wie viele gleichzeitige Nutzer werden erwartet? Gibt es Response-Zeit-Anforderungen?
2. **Validierung:** Welche Felder sind Pflicht? Gibt es Format-Vorgaben (z.B. PLZ nur 5-stellig)?
3. **Auth:** Soll die API authentifiziert sein oder öffentlich?

Sobald geklärt, starte ich die Implementierung."

4. Warten oder selbst entscheiden

• Wenn Fragen kritisch sind (Architektur-Entscheidung, unklarer Scope): Warten auf Antwort
• Wenn Fragen nice-to-have sind (Details die man mit Best Practices lösen kann): Selbst entscheiden und dokumentieren

5. Implementierung starten

Erst wenn die Anforderung klar ist:

• Alle kritischen Fragen beantwortet
• Oder: Agent hat pragmatische Defaults gewählt und dokumentiert

echo "PROGRESS: 5% - Requirements-Review abgeschlossen, starte Implementierung"

Bei Freitext-Aufgabe (kein Issue)

Wenn die Aufgabe als Freitext kommt (über implement_ticket):

• Selbst ein Issue anlegen mit der Aufgabe
• Fehlende Infos mit Best Practices/Defaults füllen
• Entscheidungen als ADR dokumentieren
• Direkt implementieren (nicht warten)

Wann sind Anforderungen klar?

• Keine offenen Fragen → Anforderungen klar → direkt implementieren
• Offene Fragen → Kommentar am Issue → warten

Ablauf bei offenen Fragen

# 1. Fragen als Kommentar posten
glab issue comment {id} --body "## Offene Fragen ..."

# 2. Signal geben dass du wartest
echo "HELP: Warte auf Antwort zu offenen Fragen am Issue #{id}"

# 3. Warten bis Antwort kommt (via send_message vom User/Kiro)
# → Agent bekommt Nachricht: "Fragen beantwortet, siehe Issue-Kommentar"

# 4. Issue-Kommentare erneut lesen
glab issue view {id} --comments

# 5. Weiterarbeiten
echo "PROGRESS: 5% - Requirements klar, starte Implementierung"

Kiro als Vermittler

Kiro sieht needs_help: true + help_message: "Warte auf Antwort..." und kann:

• Den User informieren
• Selbst die Fragen beantworten (wenn er den Kontext hat)
• Oder send_message an den Agent schicken: "Fragen beantwortet, siehe Kommentar"