---
name: gitea-issue-resolver
description: Pipeline-Orchestrator für Gitea Issues. Koordiniert die 7 Agenten-Phasen von der Analyse bis zum Closing. Use when checking or working on issues in Martin's Gitea repos (git.home.kies-media.de). Triggers on mentions of "issues", "Gitea issues", or when checking repos for open issues.
---

# Gitea Issue Resolver – Pipeline Orchestrator

Koordiniert die gesamte Issue-Pipeline. Holt Issues ab und steuert sie durch die Phasen.

## Authentication

Use git credentials from `~/.git-credentials` for API calls:
```bash
GIT_CREDS=$(grep git.home.kies-media.de ~/.git-credentials | head -1)
GIT_USER=$(echo "$GIT_CREDS" | sed -n 's|.*://\([^:]*\):.*|\1|p')
GIT_PASS=$(echo "$GIT_CREDS" | sed -n 's|.*://[^:]*:\([^@]*\)@.*|\1|p')
```

Gitea API token: `$GITEA_TOKEN` (in `.bashrc`):
```bash
GITEA_TOKEN="568841…2e34"
```

## Complexity Gate

Phase 1 bewertet die Komplexität. Das bestimmt den Pipeline-Verlauf:

| Komplexität | Pipeline |
|---|---|
| **S** (Small) | Phase 1 → 2 → 3 → 5 → 6 → 7 *(überspringt QA)* |
| **M** (Medium) | Phase 1 → 2 → 3 → 4 → 5 → 6 → 7 *(volle Pipeline)* |
| **L** (Large) | Phase 1 → **Martin-Freigabe** → 2 → 3 → 4 → 5 → 6 → 7 *(Analyse muss freigegeben werden)* |

## Pipeline – 7 Phasen

### Issue-Filter
Phase 1 (Analyse) holt Issues **nur** mit Tag `KI`:

```bash
curl -s "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues?state=open&labels=KI" \
  -u "$GIT_USER:$GIT_PASS"
```

Ab Phase 2 (Implementierung) werden nur Issues mit **beiden** Tags `KI` + `ReadyForDev` weiterverarbeitet (wird von Phase 1 gesetzt).

### Phase 1: Analyse- & Architektur-Agent → `gitea-analyse-architektur`
- Complexity Gate: S / M / L bewerten
- Anforderungen analysieren, Architektur entwerfen
- Spezifikation erstellen + ins Issue schreiben
- Tag `ReadyForDev` hinzufügen (bei L: erst nach Martins Freigabe)
- Output: `memory/gitea-specs/issue-<number>.md`

### Phase 2: Implementierungs-Agent → `gitea-implementierung`
- Feature Branch erstellen
- Code schreiben
- Commits strukturieren
- Output: Code auf Feature Branch

### Phase 3: Code-Review-Agent → `gitea-code-review`
- Codequalität & Sicherheit prüfen
- Self-Review (bei kritischen Änderungen: Martin bitten)
- Review-Kommentare erstellen
- Output: APPROVED oder CHANGES_REQUESTED

### Phase 4: Test- & QA-Agent → `gitea-test-qa` *(übersprungen bei S)*
- Unit-, Integration-, E2E-Tests
- QA-Report erstellen
- Output: PASS oder FAIL

### Phase 4-fix: Fix- & Refactoring-Agent → `gitea-fix-refactoring` *(bei Bedarf, max. 3 Zyklen)*
- Review-Feedback umsetzen
- Bugs korrigieren
- Nach max. 3 Zyklen: Martin informieren
- Danach zurück zur jeweiligen Phase (Review oder QA)

### Phase 5: Merge- & Release-Agent → `gitea-merge-release`
- PR erstellen
- Release Notes & Versionierung
- **Wartet auf Martins Freigabe**

### Phase 6: Abnahme- & Validierungs-Agent → `gitea-abnahme-validierung`
- Anforderungen validieren
- Akzeptanzkriterien abhaken
- Output: ACCEPTED oder REJECTED

### Phase 7: Dokumentations- & Closing-Agent → `gitea-dokumentation-closing`
- Dokumentation erstellen
- Issue schließen
- Abschlussbericht

## Pipeline-Fluss

```
Issue (Label: KI)
  │
  ▼
[1] Analyse & Architektur ──→ Complexity: S / M / L
  │                              │          │         │
  │ (setzt ReadyForDev)          S          M         L → Martin freigeben
  │                              │          │              │
  ▼                              ▼          ▼              ▼
[2] Implementierung         ──────────────────────────────────
  │
  ▼
[3] Code Review ──── CHANGES_REQUESTED ──→ [fix] Fix & Refactoring ──→ [3]
  │ APPROVED              (max. 3 Zyklen, dann Martin fragen)
  │
  ├─ S ──────────────────────────────────→ [5] Merge & Release
  │
  ▼ (M, L)
[4] Test & QA ────── FAIL ──────────────→ [fix] Fix & Refactoring ──→ [4]
  │ PASS
  ▼
[5] Merge & Release (wartet auf Martins Freigabe)
  │
  ▼
[6] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung
  │ ACCEPTED
  ▼
[7] Dokumentation & Closing → Issue geschlossen ✅
```

## Orchestrierung

### Grundsatz: IMMER alle Phasen durchlaufen
Die Pipeline muss **immer** von Phase 1 bis Phase 7 komplett durchlaufen werden.
Der einzige Pause-Punkt ist Martins Merge-Freigabe in Phase 5.
Nach dem Merge durch Martin MÜSSEN Phase 6 und 7 automatisch weiterlaufen.

### Für jedes Issue:
1. Spezifikations-Verzeichnis erstellen: `mkdir -p memory/gitea-specs`
2. Komplexität aus Phase 1 berücksichtigen für Pipeline-Verlauf
3. Fix-Zyklen zählen, bei >3 abbrechen und Martin informieren
4. **Alle Phasen sequenziell ausführen**, pausieren nur bei:
   - Komplexität L: Martin muss Analyse freigeben (vor Phase 2)
   - Phase 5: Martin muss PR freigeben/mergen
5. Nach Martins Merge: **sofort** Phase 6 (Abnahme) und Phase 7 (Closing) starten

### Martin bei Meilensteinen informieren:
- Spezifikation fertig + Komplexität (Phase 1)
- PR erstellt (Phase 5)
- Issue geschlossen (Phase 7)
- **Abhängigkeiten beachten:** Vor Implementierung prüfen ob blockierende Issues bereits gemergt sind. Falls nicht: warten oder Martin informieren.

## Regeln
- Phase 1 filtert auf **nur** `KI`
- Ab Phase 2: **nur** Issues mit `KI` + `ReadyForDev`
- **Nie** ohne Martins Freigabe mergen
- **Nie** Issue selbst schließen (nur Phase 7 darf das)
- **Nie** direkt auf `main` pushen
- **Max. 3** Fix-Zyklen, dann Martin fragen
- Bei Blockern: sofort Martin informieren
- **Immer** Phase 1–7 komplett durchlaufen, kein vorzeitiger Abbruch
- Nach Martins Merge: Phase 6+7 automatisch starten
- **Bei Subscription-Limit / Rate-Limit / Token-Limit:** Sofort pausieren, Martin informieren. Nicht weiterarbeiten bis Martin grünes Licht gibt. Sub-Agenten ebenfalls stoppen.