- gitea-analyse-architektur (Phase 1) - gitea-implementierung (Phase 2) - gitea-code-review (Phase 3) - gitea-test-qa (Phase 4) - gitea-fix-refactoring (Phase 5, on demand) - gitea-merge-release (Phase 6) - gitea-deployment (Phase 7) - gitea-abnahme-validierung (Phase 8) - gitea-dokumentation-closing (Phase 9) - gitea-issue-resolver updated as pipeline orchestrator - Only issues tagged KI + ReadyForDev are processed
3.7 KiB
3.7 KiB
name, description
| name | description |
|---|---|
| gitea-issue-resolver | Pipeline-Orchestrator für Gitea Issues. Koordiniert die 9 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 9 Phasen.
Authentication
Use git credentials from ~/.git-credentials for API calls:
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):
GITEA_TOKEN="568841…2e34"
Pipeline – 9 Phasen
Issue-Filter
Nur Issues mit beiden Tags: KI und ReadyForDev:
curl -s "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues?state=open&labels=KI,ReadyForDev" \
-u "$GIT_USER:$GIT_PASS"
Phase 1: Analyse- & Architektur-Agent → gitea-analyse-architektur
- Anforderungen analysieren
- Architektur entwerfen
- Spezifikation erstellen
- 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
- Review-Kommentare erstellen
- Output: APPROVED oder CHANGES_REQUESTED
Phase 4: Test- & QA-Agent → gitea-test-qa
- Unit-, Integration-, E2E-Tests
- QA-Report erstellen
- Output: PASS oder FAIL
Phase 5: Fix- & Refactoring-Agent → gitea-fix-refactoring (bei Bedarf)
- Review-Feedback umsetzen
- Bugs korrigieren
- Danach zurück zur jeweiligen Phase (Review oder QA)
Phase 6: Merge- & Release-Agent → gitea-merge-release
- PR erstellen
- Release Notes & Versionierung
- Warten auf Martins Freigabe
Phase 7: Deployment-Agent → gitea-deployment
- Anwendungen deployen
- Health Checks
- Bei Problemen: Rollback
Phase 8: Abnahme- & Validierungs-Agent → gitea-abnahme-validierung
- Anforderungen validieren
- Akzeptanzkriterien abhaken
- Output: ACCEPTED oder REJECTED
Phase 9: Dokumentations- & Closing-Agent → gitea-dokumentation-closing
- Dokumentation erstellen
- Issue schließen
- Abschlussbericht
Pipeline-Fluss
Issue (KI + ReadyForDev)
│
▼
[1] Analyse & Architektur
│
▼
[2] Implementierung
│
▼
[3] Code Review ──── CHANGES_REQUESTED ──→ [5] Fix & Refactoring ──→ [3]
│ APPROVED
▼
[4] Test & QA ────── FAIL ──────────────→ [5] Fix & Refactoring ──→ [4]
│ PASS
▼
[6] Merge & Release ( wartet auf Martins Freigabe )
│
▼
[7] Deployment
│
▼
[8] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung
│ ACCEPTED
▼
[9] Dokumentation & Closing → Issue geschlossen ✅
Orchestrierung
Für jedes Issue:
- Spezifikations-Verzeichnis erstellen:
mkdir -p memory/gitea-specs - Phasen sequenziell durchlaufen
- Bei Rücksprüngen (Fix-Phase) den Zyklus wiederholen
- Martin bei wichtigen Meilensteinen informieren:
- Spezifikation fertig (Phase 1)
- PR erstellt (Phase 6)
- Deployment erfolgreich (Phase 7)
- Issue geschlossen (Phase 9)
Regeln
- Nur Issues mit Tags
KI+ReadyForDev - Nie ohne Martins Freigabe mergen
- Nie Issue selbst schließen (nur Phase 9 darf das)
- Nie direkt auf
mainpushen - Bei Blockern: sofort Martin informieren