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

skills/gitea-issue-resolver/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: gitea-issue-resolver
-description: 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.
+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 9 Phasen.
+Koordiniert die gesamte Issue-Pipeline. Holt Issues ab und steuert sie durch die Phasen.
 
 ## Authentication
 
@@ -21,7 +21,17 @@ Gitea API token: `$GITEA_TOKEN` (in `.bashrc`):
 GITEA_TOKEN="568841…2e34"
 ```
 
-## Pipeline – 9 Phasen
+## 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`:
@@ -34,9 +44,10 @@ curl -s "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues?state
 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`
-- Anforderungen analysieren
-- Architektur entwerfen
-- Spezifikation erstellen
+- 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`
@@ -47,35 +58,32 @@ Ab Phase 2 (Implementierung) werden nur Issues mit **beiden** Tags `KI` + `Ready
 
 ### 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`
+### Phase 4: Test- & QA-Agent → `gitea-test-qa` *(übersprungen bei S)*
 - Unit-, Integration-, E2E-Tests
 - QA-Report erstellen
 - Output: PASS oder FAIL
 
-### Phase 5: Fix- & Refactoring-Agent → `gitea-fix-refactoring` *(bei Bedarf)*
+### 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 6: Merge- & Release-Agent → `gitea-merge-release`
+### Phase 5: Merge- & Release-Agent → `gitea-merge-release`
 - PR erstellen
 - Release Notes & Versionierung
-- Warten auf Martins Freigabe
+- **Wartet auf Martins Freigabe**
 
-### Phase 7: Deployment-Agent → `gitea-deployment`
-- Anwendungen deployen
-- Health Checks
-- Bei Problemen: Rollback
-
-### Phase 8: Abnahme- & Validierungs-Agent → `gitea-abnahme-validierung`
+### Phase 6: Abnahme- & Validierungs-Agent → `gitea-abnahme-validierung`
 - Anforderungen validieren
 - Akzeptanzkriterien abhaken
 - Output: ACCEPTED oder REJECTED
 
-### Phase 9: Dokumentations- & Closing-Agent → `gitea-dokumentation-closing`
+### Phase 7: Dokumentations- & Closing-Agent → `gitea-dokumentation-closing`
 - Dokumentation erstellen
 - Issue schließen
 - Abschlussbericht
@@ -83,48 +91,51 @@ Ab Phase 2 (Implementierung) werden nur Issues mit **beiden** Tags `KI` + `Ready
 ## Pipeline-Fluss
 
 ```
-Issue (KI + ReadyForDev)
+Issue (Label: KI)
   │
   ▼
-[1] Analyse & Architektur
+[1] Analyse & Architektur ──→ Complexity: S / M / L
+  │                              │          │         │
+  │ (setzt ReadyForDev)          S          M         L → Martin freigeben
+  │                              │          │              │
+  ▼                              ▼          ▼              ▼
+[2] Implementierung         ──────────────────────────────────
   │
   ▼
-[2] Implementierung
+[3] Code Review ──── CHANGES_REQUESTED ──→ [fix] Fix & Refactoring ──→ [3]
+  │ APPROVED              (max. 3 Zyklen, dann Martin fragen)
   │
-  ▼
-[3] Code Review ──── CHANGES_REQUESTED ──→ [5] Fix & Refactoring ──→ [3]
-  │ APPROVED
-  ▼
-[4] Test & QA ────── FAIL ──────────────→ [5] Fix & Refactoring ──→ [4]
+  ├─ S ──────────────────────────────────→ [5] Merge & Release
+  │
+  ▼ (M, L)
+[4] Test & QA ────── FAIL ──────────────→ [fix] Fix & Refactoring ──→ [4]
   │ PASS
   ▼
-[6] Merge & Release ( wartet auf Martins Freigabe )
+[5] Merge & Release (wartet auf Martins Freigabe)
   │
   ▼
-[7] Deployment
-  │
-  ▼
-[8] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung
+[6] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung
   │ ACCEPTED
   ▼
-[9] Dokumentation & Closing → Issue geschlossen ✅
+[7] Dokumentation & Closing → Issue geschlossen ✅
 ```
 
 ## Orchestrierung
 
 Für jedes Issue:
 1. Spezifikations-Verzeichnis erstellen: `mkdir -p memory/gitea-specs`
-2. Phasen sequenziell durchlaufen
-3. Bei Rücksprüngen (Fix-Phase) den Zyklus wiederholen
+2. Komplexität aus Phase 1 berücksichtigen für Pipeline-Verlauf
+3. Fix-Zyklen zählen, bei >3 abbrechen und Martin informieren
 4. Martin bei wichtigen Meilensteinen informieren:
-   - Spezifikation fertig (Phase 1)
-   - PR erstellt (Phase 6)
-   - Deployment erfolgreich (Phase 7)
-   - Issue geschlossen (Phase 9)
+   - Spezifikation fertig + Komplexität (Phase 1)
+   - PR erstellt (Phase 5)
+   - Issue geschlossen (Phase 7)
 
 ## Regeln
-- **Nur** Issues mit Tags `KI` + `ReadyForDev`
+- 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 9 darf das)
+- **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