feat: pipeline improvements + remove deployment phase
- Complexity Gate: S/M/L in Phase 1, S skips QA, L needs Martin approval - Max 3 fix cycles, then pause and ask Martin - KI self-review disclaimer in Code Review - Removed Phase 7 (Deployment) entirely - Renumbered: 7 phases instead of 9 - Updated all skills with new phase numbers
This commit is contained in:
@@ -5,12 +5,24 @@ description: Analyse- & Architektur-Agent für Gitea Issues. Analysiert Anforder
|
||||
|
||||
# Analyse- & Architektur-Agent
|
||||
|
||||
Rolle: Erste Phase der Gitea Issue Pipeline. Analysiert das Issue und erstellt die Grundlage für alle folgenden Phasen.
|
||||
Rolle: Erste Phase der Gitea Issue Pipeline. Analysiert das Issue, bewertet die Komplexität und erstellt die Grundlage für alle folgenden Phasen.
|
||||
|
||||
## Eingang
|
||||
- Gitea Issue **nur** mit Label `KI`
|
||||
- Issue-Body, Kommentare, verlinkte Ressourcen
|
||||
|
||||
## Complexity Gate
|
||||
|
||||
**Pflicht am Anfang:** Bewerte die Komplexität des Issues:
|
||||
|
||||
| Level | Kriterien | Auswirkung auf Pipeline |
|
||||
|---|---|---|
|
||||
| **S** (Small) | Typo-Fix, Config-Änderung, einfacher Bugfix, < 30min geschätzt | Überspringt Phase 4 (Test & QA). Nach Review direkt zu Merge. |
|
||||
| **M** (Medium) | Neues Feature, Refactoring, API-Änderung, 30min–4h | Volle Pipeline. |
|
||||
| **L** (Large) | Architektur-Änderung, neues Modul, DB-Migration, > 4h | Volle Pipeline + Martin muss Analyse freigeben bevor Implementierung startet. |
|
||||
|
||||
Komplexität ins Issue schreiben und im Spezifikationsdokument festhalten.
|
||||
|
||||
## Aufgaben
|
||||
|
||||
### Anforderungen analysieren
|
||||
@@ -83,7 +95,7 @@ Rolle: Erste Phase der Gitea Issue Pipeline. Analysiert das Issue und erstellt d
|
||||
|
||||
## Ausgang
|
||||
- Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
|
||||
- **Issue aktualisieren** mit allen Erkenntnissen (Architektur, Teilaufgaben, Akzeptanzkriterien, etc.)
|
||||
- **Issue aktualisieren** mit allen Erkenntnissen (Komplexität, Architektur, Teilaufgaben, Akzeptanzkriterien, etc.)
|
||||
- Spezifikation als Kommentar ins Issue geschrieben
|
||||
- Dem Issue den Tag **`ReadyForDev`** hinzufügen:
|
||||
```bash
|
||||
@@ -99,3 +111,4 @@ curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issu
|
||||
- Spezifikation muss für den Implementierungs-Agent ohne Rückfragen umsetzbar sein
|
||||
- Sicherheitsrelevante Entscheidungen dokumentieren und Martin zur Freigabe vorlegen
|
||||
- Tag `ReadyForDev` **erst** hinzufügen, wenn Analyse & Architektur vollständig abgeschlossen
|
||||
- **Bei Komplexität L:** Martin muss die Analyse freigeben bevor `ReadyForDev` gesetzt wird
|
||||
|
||||
Reference in New Issue
Block a user