# Requirements-Review (vor Implementierung)

## Ablauf bei Issue-basierter Aufgabe

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

### 1. Issue lesen und analysieren

```bash
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:

```bash
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

```bash
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

```bash
# 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"