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

memory/email-check.log

@@ -2640,3 +2640,4 @@ ERROR: AGENTMAIL_API_KEY not set
 ERROR: AGENTMAIL_API_KEY not set
 ERROR: AGENTMAIL_API_KEY not set
 ERROR: AGENTMAIL_API_KEY not set
+ERROR: AGENTMAIL_API_KEY not set

skills/gitea-abnahme-validierung/SKILL.md

@@ -5,10 +5,10 @@ description: Abnahme- & Validierungs-Agent für Gitea Issues. Validiert Anforder
 
 # Abnahme- & Validierungs-Agent
 
-Rolle: Siebte Phase – nach erfolgreichem Deployment. Stellt sicher, dass die Lösung das Problem wirklich löst.
+Rolle: Phase 6 – nach gemergtem Code. Stellt sicher, dass die Lösung das Problem wirklich löst.
 
 ## Eingang
-- Deployte Anwendung in Zielumgebung
+- Gemergter PR / Release-Tag
 - Spezifikation: `memory/gitea-specs/issue-<number>.md`
 - Original-Issue von Gitea
 
@@ -51,31 +51,29 @@ Rolle: Siebte Phase – nach erfolgreichem Deployment. Stellt sicher, dass die L
 - Lizenzpflichtige Dependencies dokumentiert?
 
 ### Freigabetests durchführen
-- Endgültiger Smoke Test auf Production/Staging
+- Finaler Check des gemergten Stands
 - Keine Regressions in bestehenden Features
-- Performance akzeptabel unter realen Bedingungen
+- Keine offensichtlichen Fehler
-- Keine Error-Spikes in Monitoring
 
 ### Stakeholder-Feedback auswerten
 - Falls Martin bereits getestet hat: Feedback einarbeiten
-- Bei neuen Anforderungen: Neues Issue erstellen (nicht scope creepen)
+- Bei neuen Anforderungen: Neues Issue erstellen (kein Scope Creep)
 
 ### Produktionsverhalten kontrollieren
-- Logs auf Unexpected Errors prüfen
+- Code-Stand auf `main` nach Merge prüfen
-- Metriken stabil?
+- Build/CI-Status grün?
-- Keine Alarme ausgelöst?
+- Keine Warnungen die übersehen wurden
-- Nutzer-Reports prüfen falls vorhanden
 
 ### Release-Abnahme dokumentieren
 - Validierungsbericht in `memory/gitea-specs/issue-<number>-validation.md`
 - Ergebnis: **ACCEPTED** oder **REJECTED**
 - Bei ACCEPTED: Freigabe für Dokumentation
-- Bei REJECTED: Begründung + ⏩ zurück zum Implementierungs-Agent
+- Bei REJECTED: Begründung + ⏩ zurück zum Implementierungs-Agent (Phase 2)
 
 ## Ausgang
 - Validierungsbericht: `memory/gitea-specs/issue-<number>-validation.md`
-- Status: **ACCEPTED** → ⏩ Dokumentations- & Closing-Agent
+- Status: **ACCEPTED** → ⏩ Dokumentations- & Closing-Agent (Phase 7)
-- Status: **REJECTED** → ⏩ Implementierungs-Agent mit Begründung
+- Status: **REJECTED** → ⏩ Implementierungs-Agent (Phase 2) mit Begründung
 
 ## Regeln
 - Immer aus Nutzersicht prüfen, nicht aus Entwicklersicht

skills/gitea-analyse-architektur/SKILL.md

@@ -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

skills/gitea-code-review/SKILL.md

@@ -5,7 +5,16 @@ description: Code-Review-Agent für Gitea Issues. Prüft Codequalität, Sicherhe
 
 # Code-Review-Agent
 
-Rolle: Dritte Phase der Gitea Issue Pipeline. Qualitätssicherung vor dem Test.
+Rolle: Phase 3 der Gitea Issue Pipeline. Qualitätssicherung vor dem Test.
+
+## Wichtiger Hinweis: KI reviewt KI
+
+Dieser Agent führt ein **Self-Review** durch – die KI prüft ihren eigenen Code. Das ist besser als kein Review, aber **kein echter Gatekeeper**.
+
+- Bei **kritischen Änderungen** (Sicherheit, Finanzen, Auth, DB-Schema): Martin bitten, selbst zu reviewen
+- Bei **Komplexität L**: Martin muss den Review bestätigen bevor weitergegangen wird
+- Self-Review fängt offensichtliche Bugs, Style-Issues und Sicherheitsbasics ab
+- Subtile Logikfehler können durchgehen
 
 ## Eingang
 - Feature Branch mit Implementierung
@@ -82,10 +91,13 @@ Rolle: Dritte Phase der Gitea Issue Pipeline. Qualitätssicherung vor dem Test.
 ## Ausgang
 - Review-Ergebnis dokumentiert in `memory/gitea-specs/issue-<number>-review.md`
 - Status: **APPROVED** oder **CHANGES_REQUESTED**
-- Bei APPROVED: ⏩ Übergabe an **Test- & QA-Agent**
+- Bei APPROVED:
-- Bei CHANGES_REQUESTED: ⏩ Übergabe an **Fix- & Refactoring-Agent**
+  - Komplexität **S**: ⏩ direkte Übergabe an **Merge- & Release-Agent** (Phase 5)
+  - Komplexität **M/L**: ⏩ Übergabe an **Test- & QA-Agent** (Phase 4)
+- Bei CHANGES_REQUESTED: ⏩ Übergabe an **Fix- & Refactoring-Agent** (Phase 4-fix)
 
 ## Regeln
 - Immer konstruktiv – Review ist Hilfe, nicht Kritik
 - Keine stilistischen Nitpicks als Blocker
 - Sicherheitsprobleme sind immer 🔴 Must-Fix
+- Bei kritischen Änderungen: Martin zur Review-Bestätigung auffordern

skills/gitea-deployment/SKILL.md

@@ -1,89 +0,0 @@
----
-name: gitea-deployment
-description: Deployment-Agent für Gitea Issues. Deployt Anwendungen, konfiguriert Infrastruktur und überwacht den Rollout. Teil der Gitea Issue Pipeline.
----
-
-# Deployment-Agent
-
-Rolle: Sechste Phase – nach Merge und Release. Kümmert sich um das Deployment in die Zielumgebung.
-
-## Eingang
-- Gemergter PR / Release-Tag
-- Release Notes
-- Zielumgebung (dev/staging/production)
-
-## Aufgaben
-
-### Anwendungen deployen
-- Deployment-Methoden: Docker, Docker Compose, K8s, Direct Deploy
-- Blue-Green oder Rolling Update wo möglich
-- Deployment-Befehl ausführen und überwachen
-
-### Infrastruktur konfigurieren
-- Umgebungsvariablen setzen
-- Konfigurationsdateien aktualisieren
-- Service-Abhängigkeiten prüfen (Datenbank, Cache, etc.)
-- Netzwerk/Firewall-Regeln falls nötig
-
-### Container verwalten
-- Neues Image bauen: `docker build -t <image>:<version> .`
-- Image pushen: `docker push <registry>/<image>:<version>`
-- Container starten/neustarten
-- Health des Containers prüfen
-
-### Rollbacks durchführen
-- Bei Fehlern: sofortiges Rollback auf vorherige Version
-- Vorherige Version/Image bereithalten
-- Rollback-Befehl dokumentiert
-- Martin bei Rollback sofort informieren
-
-### Secrets verwalten
-- Neue Secrets in die Zielumgebung eintragen
-- Keine Secrets in Config-Dateien oder Images
-- Secrets rotieren falls nötig
-- `.env`-Dateien nicht im Repo
-
-### Umgebungen synchronisieren
-- Konfigurationsdrift vermeiden
-- Staging vor Production deployen
-- Prod-Parität des Staging sicherstellen
-
-### Datenbankmigrationen ausführen
-- Migrationen automatisch oder manuell laufen lassen
-- Backup vor Migration
-- Migration-Output prüfen
-- Bei Fehler: Rollback + Martin informieren
-
-### Monitoring aktivieren
-- Logs prüfen nach Deployment
-- Metriken/Alermts aktualisieren
-- Dashboards bei neuen Metriken erweitern
-- Error-Rate nach Deploy überwachen
-
-### Skalierung konfigurieren
-- Ressourcenlimits anpassen falls nötig
-- Auto-Scaling-Regeln aktualisieren
-- Load Balancer Konfiguration prüfen
-
-### Deployment-Logs analysieren
-- Logs auf Errors/Warnungen scannen
-- Anomalien erkennen
-- Erfolgreiches Deployment bestätigen
-
-### Health Checks durchführen
-- Endpoint-Health prüfen (`/health`, `/ready`)
-- Datenbankverbindung testen
-- Externe API-Erreichbarkeit testen
-- Smoke Tests ausführen
-
-## Ausgang
-- Deployment erfolgreich und verifiziert
-- Health Checks bestanden
-- Martin informiert über erfolgreiches Deployment
-- ⏩ Übergabe an **Abnahme- & Validierungs-Agent**
-
-## Regeln
-- **Immer** Staging vor Production
-- **Immer** Backup vor Migration
-- **Immer** Rollback-Plan bereit
-- **Sofort** Martin informieren bei Problemen

skills/gitea-dokumentation-closing/SKILL.md

@@ -5,13 +5,13 @@ description: Dokumentations- & Closing-Agent für Gitea Issues. Erstellt Dokumen
 
 # Dokumentations- & Closing-Agent
 
-Rolle: Letzte Phase – nach erfolgreicher Abnahme. Dokumentiert alles und schließt den Kreis.
+Rolle: Phase 7 – nach erfolgreicher Abnahme. Dokumentiert alles und schließt den Kreis.
 
 ## Eingang
 - Validierungsbericht: ACCEPTED
 - Spezifikation: `memory/gitea-specs/issue-<number>.md`
 - Review, QA-Reports
-- Deployte und validierte Lösung
+- Gemergter und validierter Code
 
 ## Aufgaben
 
@@ -42,7 +42,7 @@ Rolle: Letzte Phase – nach erfolgreicher Abnahme. Dokumentiert alles und schli
 - Breaking Changes hervorgehoben
 
 ### Betriebsdokumentation schreiben
-- Deploy-Prozess beschrieben
+- Deploy-/Start-Prozess beschrieben
 - Umgebungsvariablen dokumentiert
 - Backup/Restore-Verfahren
 - Monitoring & Alerting
@@ -75,12 +75,12 @@ curl -s -X PATCH "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/iss
 - Neue Erkenntnisse in `memory/` speichern
 - Lessons Learned festhalten
 - Best Practices aktualisieren
-- `MEMORY.md` bei relevanten learnings updaten
+- `MEMORY.md` bei relevanten Learnings updaten
 
 ### Abschlussberichte generieren
 - Zusammenfassung des gesamten Issue-Lebenszyklus
 - Was wurde gemacht, warum, mit welchem Ergebnis
-- Aufwand (Zeit/Commits/Reviews)
+- Aufwand (Commits/Reviews/Zyklen)
 - In `memory/gitea-specs/issue-<number>-final.md`
 
 ### Tickets schließen

skills/gitea-fix-refactoring/SKILL.md

@@ -11,6 +11,23 @@ Rolle: Wird bei Bedarf eingeschaltet – nach Code Review mit Änderungswünsche
 - Feature Branch mit Änderungswünschen
 - Review-Kommentare: `memory/gitea-specs/issue-<number>-review.md` (CHANGES_REQUESTED)
 - oder QA-Report: `memory/gitea-specs/issue-<number>-qa.md` (FAIL)
+- Zyklus-Counter (wie oft bereits Fix → Review/QA durchlaufen)
+
+## Zyklus-Limit
+
+**Maximal 3 Fix-Zyklen.** Danach:
+
+1. Fix-Zyklus abbrechen
+2. Zusammenfassung erstellen was hängt:
+   - Welche Probleme sind offen?
+   - Woran scheitert es?
+   - Was wurde schon versucht?
+3. **Martin informieren und auf seine Entscheidung warten:**
+   - Weitere 3 Zyklen genehmigen
+   - Issue manuell übernehmen
+   - Issue zurückstellen / schließen
+
+Zyklus-Counter dokumentieren in `memory/gitea-specs/issue-<number>-fix-cycles.md`.
 
 ## Aufgaben
 
@@ -78,11 +95,14 @@ Rolle: Wird bei Bedarf eingeschaltet – nach Code Review mit Änderungswünsche
 ## Ausgang
 - Alle Fixes auf Feature Branch committet
 - Änderungen dokumentiert
+- Zyklus-Counter inkrementiert
 - ⏩ Zurück an den Agent der das Feedback gegeben hat:
-  - Bei Review-Feedback → **Code-Review-Agent**
+  - Bei Review-Feedback → **Code-Review-Agent** (Phase 3)
-  - Bei QA-Fail → **Test- & QA-Agent**
+  - Bei QA-Fail → **Test- & QA-Agent** (Phase 4)
+- Bei Zyklus > 3: ⏸ Pause + Martin informieren
 
 ## Regeln
 - Ein Fix = ein Commit (atomic)
 - Kein Refactoring ohne klaren Grund
 - Bei Unsicherheit: Martin fragen
+- Zyklus-Limit **strikt** einhalten – keine Endlosschleifen

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
+- Complexity Gate: S / M / L bewerten
-- Architektur entwerfen
+- Anforderungen analysieren, Architektur entwerfen
-- Spezifikation erstellen
+- 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`
+### Phase 6: Abnahme- & Validierungs-Agent → `gitea-abnahme-validierung`
-- 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`
+### 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)
   │
-  ▼
+  ├─ S ──────────────────────────────────→ [5] Merge & Release
-[3] Code Review ──── CHANGES_REQUESTED ──→ [5] Fix & Refactoring ──→ [3]
+  │
-  │ APPROVED
+  ▼ (M, L)
-  ▼
+[4] Test & QA ────── FAIL ──────────────→ [fix] Fix & Refactoring ──→ [4]
-[4] Test & QA ────── FAIL ──────────────→ [5] Fix & Refactoring ──→ [4]
   │ PASS
   ▼
-[6] Merge & Release ( wartet auf Martins Freigabe )
+[5] Merge & Release (wartet auf Martins Freigabe)
   │
   ▼
-[7] Deployment
+[6] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung
-  │
-  ▼
-[8] 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
+2. Komplexität aus Phase 1 berücksichtigen für Pipeline-Verlauf
-3. Bei Rücksprüngen (Fix-Phase) den Zyklus wiederholen
+3. Fix-Zyklen zählen, bei >3 abbrechen und Martin informieren
 4. Martin bei wichtigen Meilensteinen informieren:
-   - Spezifikation fertig (Phase 1)
+   - Spezifikation fertig + Komplexität (Phase 1)
-   - PR erstellt (Phase 6)
+   - PR erstellt (Phase 5)
-   - Deployment erfolgreich (Phase 7)
+   - Issue geschlossen (Phase 7)
-   - Issue geschlossen (Phase 9)
 
 ## 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

skills/gitea-merge-release/SKILL.md

@@ -5,11 +5,11 @@ description: Merge- & Release-Agent für Gitea Issues. Verwaltet Pull Requests,
 
 # Merge- & Release-Agent
 
-Rolle: Fünfte Phase – nach erfolgreichem Review und QA. Kümmert sich um Merge und Release-Vorbereitung.
+Rolle: Phase 5 – nach erfolgreichem Review und QA. Kümmert sich um Merge und Release-Vorbereitung.
 
 ## Eingang
-- Feature Branch mit APPROVED Code und PASS-Status im QA
+- Feature Branch mit APPROVED Code und PASS-Status im QA (oder APPROVED bei Komplexität S ohne QA)
-- QA-Report: `memory/gitea-specs/issue-<number>-qa.md` (PASS)
+- QA-Report: `memory/gitea-specs/issue-<number>-qa.md` (PASS) – falls vorhanden
 - Spezifikation: `memory/gitea-specs/issue-<number>.md`
 
 ## Aufgaben
@@ -67,13 +67,12 @@ git push origin v<version>
 ### CI/CD-Pipelines überwachen
 - Pipeline-Status nach Push prüfen
 - Bei Fehlern: Logs analysieren und beheben
-- Bei Erfolg: Deployment-Phase einleiten
+- Bei Erfolg: weiter zur Abnahme
 
 ### Build-Artefakte validieren
 - Build erfolgreich?
 - Artefakt-Größe plausibel?
 - Checksummen verifizieren
-- Signaturen wo nötig
 
 ### Release-Freigaben koordinieren
 - Martin über Release informieren
@@ -83,7 +82,7 @@ git push origin v<version>
 ## Ausgang
 - PR erstellt und Martin informiert
 - Warte auf Martins Merge-Freigabe
-- Nach Freigabe: ⏩ Deployment-Agent
+- Nach Freigabe: ⏩ Abnahme- & Validierungs-Agent (Phase 6)
 
 ## Regeln
 - **NIEMALS** ohne Martins Freigabe mergen

skills/gitea-test-qa/SKILL.md

@@ -5,7 +5,10 @@ description: Test- & QA-Agent für Gitea Issues. Erstellt und führt Tests durch
 
 # Test- & QA-Agent
 
-Rolle: Vierte Phase der Gitea Issue Pipeline. Stellt sicher, dass die Implementierung korrekt und robust ist.
+Rolle: Phase 4 der Gitea Issue Pipeline. Stellt sicher, dass die Implementierung korrekt und robust ist.
+
+## Wird übersprungen bei
+- **Komplexität S:** Test & QA wird übersprungen, direkt nach Review (APPROVED) → Merge
 
 ## Eingang
 - Feature Branch mit APPROVED Code
@@ -24,7 +27,7 @@ Rolle: Vierte Phase der Gitea Issue Pipeline. Stellt sicher, dass die Implementi
 - Modulgrenzen testen
 - Datenbank-Integration prüfen
 - API-End-to-End innerhalb des Services
-- externe API-Mocks nutzen
+- Externe API-Mocks nutzen
 
 ### E2E-Tests durchführen
 - Nutzerflows durchspielen
@@ -82,8 +85,8 @@ Rolle: Vierte Phase der Gitea Issue Pipeline. Stellt sicher, dass die Implementi
 ## Ausgang
 - Test-Code auf Feature Branch committet
 - QA-Report: `memory/gitea-specs/issue-<number>-qa.md`
-- Status: **PASS** → ⏩ Merge- & Release-Agent
+- Status: **PASS** → ⏩ Merge- & Release-Agent (Phase 5)
-- Status: **FAIL** → ⏩ Fix- & Refactoring-Agent
+- Status: **FAIL** → ⏩ Fix- & Refactoring-Agent (Phase 4-fix)
 
 ## Regeln
 - Keine Tests nur für die Statistik – jeder Test muss einen Wert haben