feat: split gitea-issue-resolver into 9 specialized agent skills + orchestrator

- 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
2026-05-10 20:18:24 +00:00
parent aa10d148ec
commit db82c851b5
13 changed files with 1100 additions and 28 deletions
--- a/memory/2026-05-10-1853.md
+++ b/memory/2026-05-10-1853.md
@@ -0,0 +1,88 @@
 # Session: 2026-05-10 18:53:14 UTC
 - **Session Key**: agent:main:telegram:direct:2138015302
 - **Session ID**: 4e7ef9bc-9734-42f9-9f23-3150718f83e8
 - **Source**: telegram
 ## Conversation Summary
 assistant: Ein offenes Issue gefunden:
 **Repo:** `greggy/landingpage-haus-schleusingen`
 **#2 – Korrigiere die Flächenangaben**
 > Auf der Seite findest du die Flächen aller Zimmer. Die Summen stimmen nicht überall. Korrigiere diese.
 Soll ich das angehen? Ich klone dann das Repo, prüfe die Flächenangaben anhand der Notar-Belege aus MEMORY.md und fixe sie.
 user: ja
 assistant: Jetzt prüfe ich die Flächen gegen die Notar-Belege aus MEMORY.md:
 assistant: Let me check the areas systematically. From MEMORY.md (Notarvertrag):
 **EG (Wohnfläche):** Flur 20,1 + WC 0,8 + Abstellraum 1: 9,9 + Abstellraum 2: 7,8 = **38,6 m²**
 **EG (Nutzfläche):** Garage/Partykeller 42,6 + Heizungskeller 18,3 = **60,9 m²**
 **1. OG (Wohnfläche):** Flur 20,1 + Wohnzimmer 42,6 + Gästezimmer 11,5 + Bad 9,8 + Küche 18,4 + Schlafzimmer 18 = **120,4 m²**
 **2. OG (Wohnfläche):** Flur 13,9 + Spielzimmer 6,3 + Ankleide 1,4 + Kinderzimmer 1: 21,7 + Kinderzimmer 2: 15,7 + Dachterrasse 9 (25% v. 35,8) = **68,0 m²**
 **Dachboden (Nutzfläche):** unten 52 + mitte 31 + oben 11 = **94 m²** (but HTML says 52 m²)
 Now let me check what the HTML shows:
 **EG in HTML (line 182):** Summe 99,4 m² — rooms: 20,1 + 0,8 + 42,6 + 9,9 + 7,8 + 18,3 = 99,5 → should be 99,5 (mixed Wohn+Nutz)
 Wait — the EG mixes Wohnfläche and Nutzfläche. Let me re-read the HTML structure.
 assistant: Jetzt hab ich alle Daten. Hier die Analyse:
 **EG:** 20,1 + 0,8 + 42,6 + 9,9 + 7,8 + 18,3 = **99,5** → HTML sagt **99,4** ❌
 **1. OG:** Laut Notar: Wohnzimmer **42,6** m², aber HTML sagt **24,7** m². Summe laut HTML: 20,1 + 24,7 + 11,5 + 9,8 + 18,4 + 18,0 = **102,5** → HTML sagt **100,3** ❌
 - Laut Notar wäre die 1.OG-Summe: 20,1 + 42,6 + 11,5 + 9,8 + 18,4 + 18,0 = **120,4**
 **2. OG:** 13,9 + 21,7 + 15,7 + 6,3 + 1,4 + 35,8 = **94,8** → HTML sagt **68** ❌
 - Laut Notar: Dachterrasse wird nur zu 25% gezählt = 9 m², also: 13,9 + 21,7 + 15,7 + 6,3 + 1,4 + 9 = **68,0** ✓ (Summe stimmt, aber die Dachterrasse zeigt 35,8 statt 9)
 **Dachboden:** Laut Notar: 52 + 31 + 11 = **94 m²** → HTML sagt **52 m²** ❌
 assistant: **Gesamt-Wohnfläche laut Notar:** EG (38,6 Wohn) + 1.OG (120,4) + 2.OG (68,0) = **227,0 m²** ✓
 Also die 227 m² Gesamt stimmen! Aber die Einzelaufteilung hat Fehler. Lass mich die Korrekturen zusammenfassen und anwenden:
 **Korrekturen:**
 1. **EG:** 99,4 → **99,5** (Summe der Einzelräume)
 2. **1. OG:** Wohnzimmer 24,7 → **42,6**, Summe 100,3 → **120,4**
 3. **2. OG:** Dachterrasse 35,8 → **9** (25% von 35,8), Einzel-Chip sollte "(25% von 35,8 m²)" oder ähnlich zeigen, Summe 68 bleibt ✓
 4. **Dachboden:** Nur 52 → **94 m²** (52+31+11), braucht 3 Einträge statt einem
 Warte – beim 2.OG: wenn die Dachterrasse als 9 m² geändert wird, stimmt die Chip-Anzeige nicht mehr mit dem sichtbaren "35,8 m²" überein. Und beim 1.OG Wohnzimmer: 24,7 vs 42,6 – das ist ein großer Unterschied. Das könnte auch am Grundriss-Bild liegen. Mal überlegen ob das Notar-Dokument die korrekte Quelle ist.
 Laut MEMORY.md sind die Notar-Daten die Quelle der Wahrheit. Ich korrigiere jetzt:
 assistant: Jetzt noch die Info-Bereiche oben und die Galerie prüfen:
 assistant: Noch mehr Stellen mit 24,7 und 113:
 assistant: Warte – woher kommt die 113 m²? Laut Notar: Nutzfläche gesamt = 196,5 m², Wohnfläche gesamt = 184,4 m². Lass mich den Kontext prüfen:
 assistant: Die 113 m² Nutzfläche: laut Notar EG Nutzfläche (60,9) + Dachboden Nutzfläche (94) = 154,9 m². Oder ist die 113 nur für EG? EG Nutz = 42,6 + 18,3 = 60,9. Das passt auch nicht zu 113.
 Vielleicht war das ursprünglich EG (60,9) + Dachboden (52) = 112,9 ≈ 113. Mit dem korrigierten Dachboden (94): 60,9 + 94 = **154,9 m²**.
 assistant: Jetzt Branch erstellen und committen:
 assistant: Fertig! 🐾 Branch ist gepusht. Hier die Zusammenfassung:
 **Issue #2 – Korrigiere die Flächenangaben** ✅
 | Bereich | Vorher | Nachher (laut Notarvertrag) |
 |---------|--------|-----|
 | EG | 99,4 m² | 99,5 m² |
 | 1. OG – Wohnzimmer | 24,7 m² | 42,6 m² |
 | 1. OG – Gesamt | 100,3 m² | 120,4 m² |
 | 2. OG – Dachterrasse | 35,8 m² | 9,0 m² (25% von 35,8) |
 | Dachboden | 52 m² | 94 m² (52+31+11) |
 | Nutzfläche gesamt | 113 m² | 154,9 m² |
 Branch: `feature/issue-2-korrigiere-flaechenangaben`
 PR erstellen: https://git.home.kies-media.de/greggy/landingpage-haus-schleusingen/pulls/new/feature/issue-2-korrigiere-flaechenangaben
 Du kannst mergen und das Issue schließen wenn alles passt.
 user: ergänze den skill:
 - nachdem die entwicklung abgeschlossen ist, lege einen pull request an
 assistant: Und gleich den PR für das aktuelle Issue nachholen:
 assistant: Skill ist aktualisiert und der PR existiert bereits (wurde durch den Push automatisch erstellt von Gitea):
 👉 https://git.home.kies-media.de/greggy/landingpage-haus-schleusingen/pulls/3
 Ab jetzt läuft der Workflow automatisch: Issue finden → Branch → Fix → Commit → Push → PR erstellen → dich informieren. 🐾
--- a/memory/2026-05-10-2004.md
+++ b/memory/2026-05-10-2004.md
@@ -0,0 +1,57 @@
 # Session: 2026-05-10 20:04:06 UTC
 - **Session Key**: agent:main:telegram:direct:2138015302
 - **Session ID**: 126e6bf8-284a-4832-8a68-3e517248a34d
 - **Source**: telegram
 ## Conversation Summary
 assistant: Läuft... warte auf die KI:
 assistant: Läuft jetzt 4.7 Sekunden (statt 100ms)! Die KI-Node hat funktioniert, aber "KI Antwort parsen" crasht — `choices[0]` ist undefined. Das liegt daran dass die KI-Node jetzt ein Code-Node ist und die AI-Antwort in `aiResponse` gespeichert hat. Der Parse-Node erwartet aber `$input.first().json.choices`. Fix:
 assistant: Kein Error! Aber "No item to return" — Daten kommen nicht durch. Prüfe:
 assistant: **Alle Nodes bis KI Antwort parsen sind erfolgreich!** 🎉 Aber danach kommt nichts mehr. "Dateien committen" wird nicht ausgeführt. Das liegt daran dass "KI Antwort parsen" für **2 Issues** Files ausgibt, aber die nachfolgenden HTTP-Request Nodes für PR/Kommentar erwarten nur 1 Item pro Issue.
 Die Pipeline bricht ab weil "Dateien committen" ausgeht aber kein Output zum nächsten Node kommt. Prüfe ob Dateien committed wurden:
 assistant: Es gibt `feature/issue-` ohne Nummer — das kommt vom "Keine Issues" Dummy-Item. Und die Dateien wurden nicht committed. Der "Dateien committen" Code-Node ist nicht gelaufen.
 Problem: Nach "KI Antwort parsen" kommt nichts weil die `responseMode: "lastNode"` den Workflow beendet sobald der letzte verbundene Node fertig ist. Der letzte verbundene Node ist "KI Label setzen" aber "Dateien committen" hat Items die weitergehen sollen.
 Eigentlich sollte es fließen: KI Antwort parsen → Dateien committen → Pull Request erstellen → Issue kommentieren → KI Label setzen. Lass mich prüfen ob die Verbindungen stimmen:
 assistant: Verbindungen stimmen. Aber "Dateien committen" lief nicht. Der Code-Node braucht `$input.all()` — vielleicht gibt "KI Antwort parsen" ein leeres Array zurück? 
 Das Problem: **2 Issues (6 und 8) werden verarbeitet**, die KI gibt für jedes Files zurück, "KI Antwort parsen" gibt alle Files als Items zurück. "Dateien committen" müsste die alle verarbeiten. 
 Eigentlich: Execution hat `status: success` und 7 Nodes liefen. "Dateien committen" ist nicht in der Liste. Das heißt der Workflow **ist durch** ohne Error, aber "Dateien committen" wurde einfach nicht getriggert. 
 Ich vermute das Problem ist dass "KI Antwort parsen" `0` Items zurückgibt (leerer Array) weil die KI-Antwort leer ist (GLM-5.1 Reasoning). Die `responseMode: lastNode` beendet dann.
 Lass mich den Parse-Output checken indem ich die Execution-Daten genauer anschaue:
 assistant: Da ist das Problem! Der "Issues aufbereiten" Code gibt nur **1 Item** zurück (das Dummy "Keine Issues" mit issueNumber 0) statt der echten Issues. Die Gitea API gibt ein Array zurück, aber `$input.first().json` ist das ganze Array, und der Code prüft `Array.isArray(issues)` — das müsste stimmen... 
 Warte — "Issues laden" hat **2 items**. Das heißt n8n spaltet das Array automatisch auf! Jedes Item ist ein einzelnes Issue. `$input.first().json` ist dann nur das erste Issue, kein Array. Daran scheitert die `Array.isArray` Prüfung nicht, aber der Code-Node wird pro Item aufgerufen.
 Fix: Der Code-Node muss alle Items nehmen, nicht nur das erste:
 assistant: Syntax-Fehler im "Issues aufbereiten" Code! Die Backtick-Escapes haben sich zerschossen. Fixe es ordentlich:
 assistant: Diesmal dauert es länger weil 2 Issues verarbeitet werden (2x KI-Call):
 assistant: 🎉🎉🎉 **Fast komplett durch!** Alle Nodes bis "Issue kommentieren" laufen erfolgreich! Dauer: 62.7 Sekunden.
 Das Problem: "Issue kommentieren" benutzt die falsche URL-Expression — `$json.issueNumber` kommt nicht mehr an weil der PR-Node die PR-Daten übergibt. Fix:
 assistant: 504 Timeout vom n8n-Proxy. Workflow läuft zu lange. Prüfe was passiert ist:
 assistant: Das ist noch die alte Execution 4636! Der neue Workflow-Lauf ist noch am Laufen (oder timed out). Prüfe ob Issue #11 bearbeitet wurde:
 assistant: **Es funktioniert! 🎉🎉🎉**
 Issue #11 wurde gelöst — **PR #13 erstellt** (und #12 ist ein Duplikat vom vorherigen Lauf). Auch Issue #6 und #8 wurden vorher bearbeitet (PR #10 und #9).
 Der 504 war nur der Webhook-Timeout weil die Antwort zu lange gedauert hat. Der Workflow läuft asynchron weiter. 
 Ergebnis:
 - ✅ Issues geladen
 - ✅ Branch erstellt
 - ✅ KI (z.ai GLM-5.1) löst Issue
 - ✅ Dateien committet
 - ✅ Pull Request erstellt
 - ✅ Issue kommentiert + KI-Label gesetzt
 Workflow ist **aktiv** und bereit 🐾
 user: kannst du n8n updaten?
 assistant: Kein direkter SSH-Zugang. Läuft n8n auf dem TrueNAS (Docker/Podman) oder irgendwo anders? Wie kommt man da dran?
--- a/memory/email-check.log
+++ b/memory/email-check.log
@@ -2609,3 +2609,34 @@ 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
 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
 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
 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
 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
 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
 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
--- a/skills/gitea-abnahme-validierung/SKILL.md
+++ b/skills/gitea-abnahme-validierung/SKILL.md
@@ -0,0 +1,83 @@
 ---
 name: gitea-abnahme-validierung
 description: Abnahme- & Validierungs-Agent für Gitea Issues. Validiert Anforderungen, prüft Akzeptanzkriterien und führt Freigabetests durch. Teil der Gitea Issue Pipeline.
 ---
 # Abnahme- & Validierungs-Agent
 Rolle: Siebte Phase – nach erfolgreichem Deployment. Stellt sicher, dass die Lösung das Problem wirklich löst.
 ## Eingang
 - Deployte Anwendung in Zielumgebung
 - Spezifikation: `memory/gitea-specs/issue-<number>.md`
 - Original-Issue von Gitea
 ## Aufgaben
 ### Anforderungen validieren
 - Jede Anforderung aus dem Issue durchgehen
 - Ist die Anforderung in der Lösung umgesetzt?
 - Löst die Lösung das im Issue beschriebene Problem?
 - Gap-Analyse: Fehlt etwas?
 ### Akzeptanzkriterien prüfen
 - Jedes Akzeptanzkriterium einzeln abhaken
 - Bei UI: visuell überprüfen
 - Bei API: Requests manuell/automatisiert senden
 - Bei Daten: korrekte Speicherung und Abrufbarkeit prüfen
 ### Nutzerflows testen
 - Reale Nutzer-Szenarien durchspielen
 - Happy Path + Alternative Paths
 - Abbruch-Szenarien
 - Workflow von Anfang bis Ende
 ### Business-Logik verifizieren
 - Berechnungen korrekt?
 - Zustandsübergänge wie spezifiziert?
 - Berechtigungen wie gefordert?
 - Edge Cases im Business-Kontext
 ### UI/UX bewerten
 - Layout korrekt und konsistent?
 - Fehlermeldungen verständlich?
 - Ladezeiten akzeptabel?
 - Mobile Darstellung falls relevant
 ### Compliance prüfen
 - Datenschutzanforderungen erfüllt?
 - Audit-Trail wo gefordert?
 - Protokollierungsvorschriften eingehalten?
 - Lizenzpflichtige Dependencies dokumentiert?
 ### Freigabetests durchführen
 - Endgültiger Smoke Test auf Production/Staging
 - Keine Regressions in bestehenden Features
 - Performance akzeptabel unter realen Bedingungen
 - Keine Error-Spikes in Monitoring
 ### Stakeholder-Feedback auswerten
 - Falls Martin bereits getestet hat: Feedback einarbeiten
 - Bei neuen Anforderungen: Neues Issue erstellen (nicht scope creepen)
 ### Produktionsverhalten kontrollieren
 - Logs auf Unexpected Errors prüfen
 - Metriken stabil?
 - Keine Alarme ausgelöst?
 - 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
 ## Ausgang
 - Validierungsbericht: `memory/gitea-specs/issue-<number>-validation.md`
 - Status: **ACCEPTED** → ⏩ Dokumentations- & Closing-Agent
 - Status: **REJECTED** → ⏩ Implementierungs-Agent mit Begründung
 ## Regeln
 - Immer aus Nutzersicht prüfen, nicht aus Entwicklersicht
 - Bei REJECTED: Konstruktiv und spezifisch
 - Wenn unsicher: Martin fragen statt selbst entscheiden
--- a/skills/gitea-analyse-architektur/SKILL.md
+++ b/skills/gitea-analyse-architektur/SKILL.md
@@ -0,0 +1,98 @@
 ---
 name: gitea-analyse-architektur
 description: Analyse- & Architektur-Agent für Gitea Issues. Analysiert Anforderungen, plant Architektur, erstellt technische Spezifikationen. Teil der Gitea Issue Pipeline.
 ---
 # Analyse- & Architektur-Agent
 Rolle: Erste Phase der Gitea Issue Pipeline. Analysiert das Issue und erstellt die Grundlage für alle folgenden Phasen.
 ## Eingang
 - Gitea Issue mit Tags `KI` und `ReadyForDev`
 - Issue-Body, Kommentare, verlinkte Ressourcen
 ## Aufgaben
 ### Anforderungen analysieren
 - Issue-Body vollständig lesen und verstehen
 - Stakeholder-Intention erkennen
 - Implizite Anforderungen ableiten
 - Unklarheiten dokumentieren und Martin zur Klärung vorlegen
 ### Tickets strukturieren
 - Anforderungen in Teilaufgaben gliedern
 - Prioritäten setzen
 - Abhängigkeiten zwischen Teilaufgaben markieren
 - Akzeptanzkriterien formulieren
 ### Edge Cases erkennen
 - Grenzfälle identifizieren
 - Fehlerpfade aufzeigen
 - Ungültige Eingaben / fehlende Daten berücksichtigen
 - Race Conditions / Parallelitätsprobleme erkennen
 ### Architektur entwerfen
 - Komponentendiagramm erstellen
 - Datenfluss definieren
 - Schnittstellen beschreiben
 - Technology-Stack-Empfehlung aussprechen
 ### Datenmodelle planen
 - Entitäten identifizieren
 - Attribute und Typen definieren
 - Beziehungen modellieren
 - Indizes und Constraints planen
 - Migrationsbedarf eruieren
 ### APIs definieren
 - Endpoints festlegen (Methoden, Pfade)
 - Request/Response-Schemas definieren
 - Authentifizierung/Authorisierung klären
 - Rate Limiting / Pagination berücksichtigen
 - Fehlercodes und -meldungen spezifizieren
 ### Komponenten aufteilen
 - Logische Module/Services identifizieren
 - Verantwortlichkeiten trennen (Single Responsibility)
 - Interfaces zwischen Komponenten definieren
 - Wiederverwendbarkeit fördern
 ### Abhängigkeiten identifizieren
 - Externe Libraries/Services auflisten
 - Interne Abhängigkeiten kartieren
 - Versionskonflikte prüfen
 - Neu hinzuzufügende Abhängigkeiten bewerten
 ### Sicherheitsrisiken erkennen
 - OWASP Top 10 prüfen
 - Input-Validation-Anforderungen definieren
 - Auth/Authz-Anforderungen klären
 - Datenlecks ausschließen
 ### Aufwand schätzen
 - Komplexität bewerten (S/M/L/XL)
 - Zeitaufwand pro Teilaufgabe schätzen
 - Risikopuffer einplanen
 - Gesamtahufwand aggregieren
 ### Technische Spezifikationen erstellen
 - Alle Ergebnisse in einem Spezifikationsdokument zusammenfassen
 - Spezifikation im Workspace speichern: `memory/gitea-specs/issue-<number>.md`
 - Klare, umsetzbare Anweisungen für den Implementierungs-Agent
 ### Migrationsstrategien planen
 - Bestehende Datenstruktur analysieren
 - Migrationspfad definieren
 - Rollback-Strategie festlegen
 - Datenverlust-Risiko bewerten
 ## Ausgang
 - Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
 - Strukturierte Teilaufgabenliste
 - Architektur-Entscheidungen dokumentiert
 - ⏩ Übergabe an **Implementierungs-Agent**
 ## Regeln
 - Bei Unklarheiten **immer** Martin fragen, nicht raten
 - Spezifikation muss für den Implementierungs-Agent ohne Rückfragen umsetzbar sein
 - Sicherheitsrelevante Entscheidungen dokumentieren und Martin zur Freigabe vorlegen
--- a/skills/gitea-code-review/SKILL.md
+++ b/skills/gitea-code-review/SKILL.md
@@ -0,0 +1,91 @@
 ---
 name: gitea-code-review
 description: Code-Review-Agent für Gitea Issues. Prüft Codequalität, Sicherheit und Architekturkonformität. Teil der Gitea Issue Pipeline.
 ---
 # Code-Review-Agent
 Rolle: Dritte Phase der Gitea Issue Pipeline. Qualitätssicherung vor dem Test.
 ## Eingang
 - Feature Branch mit Implementierung
 - Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
 ## Aufgaben
 ### Codequalität prüfen
 - Lesbarkeit und Verständlichkeit bewerten
 - Komplexität der Funktionen prüfen (Cyclomatic Complexity)
 - Duplication vermeiden (DRY)
 - SOLID-Prinzipien beachten
 - YAGNI – kein Over-Engineering
 ### Sicherheitsprobleme erkennen
 - Input Validation auf allen Einstiegspunkten
 - SQL Injection / XSS / CSRF prüfen
 - Auth/Authz korrekt implementiert
 - Keine Secrets im Code
 - Dependency-Schwachstellen prüfen
 ### Architekturkonformität prüfen
 - Entspricht die Umsetzung der Spezifikation?
 - Layer-Trennung eingehalten?
 - Abhängigkeiten in die richtige Richtung?
 - Keine zirkulären Abhängigkeiten
 ### Duplikate identifizieren
 - Copy-Paste-Code erkennen
 - Gemeinsame Logik extrahierbar?
 - Bestehende Utility-Funktionen genutzt?
 ### Lesbarkeit bewerten
 - Aussagekräftige Namen für Variablen, Funktionen, Klassen
 - Komplexe Logik kommentiert?
 - Funktionen nicht zu lang (>30 Zeilen = Warnung)
 ### Naming-Konventionen prüfen
 - Projekt-Styleguide eingehalten
 - Konsistente Benennung throughout
 - Keine Abkürzungen ohne Notwendigkeit
 ### Performanceprobleme erkennen
 - Ineffiziente Queries / Algorithmen
 - Unnötige Synchronisierung
 - Memory Leaks potenziell
 - Blocking Calls in async Kontext
 ### Potenzielle Bugs finden
 - Off-by-One Errors
 - Null/Undefined Handling
 - Race Conditions
 - Exception Handling vollständig?
 - Edge Cases abgedeckt?
 ### Testabdeckung bewerten
 - Sind kritische Pfade getestet?
 - Edge Cases in Tests abgedeckt?
 - Mocking korrekt eingesetzt?
 - Tests sind deterministisch?
 ### Review-Kommentare erstellen
 - Konstruktiv und spezifisch formulieren
 - Code-Stellen mit Zeilennummern referenzieren
 - Schweregrad kennzeichnen: 🔴 Must-Fix / 🟡 Should-Fix / 🔵 Nitpick
 - Verbesserungsvorschläge mit Beispiel-Code
 ### Merge-Freigaben erteilen
 - Alle 🔴 Must-Fix behoben?
 - Spezifikation vollständig umgesetzt?
 - Keine bekannten Sicherheitsprobleme?
 - → Freigabe erteilen oder Feedback an Implementierungs-Agent
 ## 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 CHANGES_REQUESTED: ⏩ Übergabe an **Fix- & Refactoring-Agent**
 ## Regeln
 - Immer konstruktiv – Review ist Hilfe, nicht Kritik
 - Keine stilistischen Nitpicks als Blocker
 - Sicherheitsprobleme sind immer 🔴 Must-Fix
--- a/skills/gitea-deployment/SKILL.md
+++ b/skills/gitea-deployment/SKILL.md
@@ -0,0 +1,89 @@
 ---
 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
--- a/skills/gitea-dokumentation-closing/SKILL.md
+++ b/skills/gitea-dokumentation-closing/SKILL.md
@@ -0,0 +1,100 @@
 ---
 name: gitea-dokumentation-closing
 description: Dokumentations- & Closing-Agent für Gitea Issues. Erstellt Dokumentation, pflegt das Wiki und schließt Tickets ab. Teil der Gitea Issue Pipeline.
 ---
 # Dokumentations- & Closing-Agent
 Rolle: Letzte Phase – 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
 ## Aufgaben
 ### Technische Dokumentation erstellen
 - Architektur-Entscheidungen festhalten
 - Komponenten und deren Zusammenspiel beschreiben
 - Konfigurationsoptionen dokumentieren
 - Troubleshooting-Guide falls hilfreich
 - Im Repo oder Wiki speichern
 ### API-Dokumentation pflegen
 - Neue/Geänderte Endpoints dokumentieren
 - Request/Response-Beispiele
 - Auth-Requirements
 - Fehlercodes und -bedeutungen
 - OpenAPI/Swagger falls verwendet
 ### Architektur dokumentieren
 - System Context Diagram aktualisieren
 - Komponentendiagramm aktualisieren
 - Datenfluss beschreiben
 - ADRs (Architecture Decision Records) bei wichtigen Entscheidungen
 ### Changelogs ergänzen
 - Änderung in CHANGELOG.md eingetragen
 - User-facing Beschreibung
 - Link zum Issue/PR
 - Breaking Changes hervorgehoben
 ### Betriebsdokumentation schreiben
 - Deploy-Prozess beschrieben
 - Umgebungsvariablen dokumentiert
 - Backup/Restore-Verfahren
 - Monitoring & Alerting
 - Known Operations (Runbook)
 ### Known Issues dokumentieren
 - Bekannte Einschränkungen auflisten
 - Workarounds beschreiben
 - Folge-Issues erstellen falls nötig
 ### Tickets aktualisieren
 - Issue-Status auf **closed** setzen via API:
 ```bash
 curl -s -X PATCH "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues/<number>" \
  -H "Authorization: token $GITEA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"state": "closed"}'
 ```
 - Abschließender Kommentar im Issue mit Zusammenfassung
 - Labels aktualisieren
 - Verknüpfte PRs referenzieren
 ### Entscheidungsprotokolle erstellen
 - Wichtige Entscheidungen während des Prozesses
 - Warum wurde welche Option gewählt?
 - Welche Alternativen gab es?
 - ADR ablegen falls relevant
 ### Wissensdatenbank pflegen
 - Neue Erkenntnisse in `memory/` speichern
 - Lessons Learned festhalten
 - Best Practices aktualisieren
 - `MEMORY.md` bei relevanten learnings updaten
 ### Abschlussberichte generieren
 - Zusammenfassung des gesamten Issue-Lebenszyklus
 - Was wurde gemacht, warum, mit welchem Ergebnis
 - Aufwand (Zeit/Commits/Reviews)
 - In `memory/gitea-specs/issue-<number>-final.md`
 ### Tickets schließen
 - Issue schließen (siehe oben)
 - Feature Branch löschen (optional, nach Martins Präferenz)
 - Temporäre Dateien aufräumen (`/tmp/<repo>`)
 ## Ausgang
 - Issue geschlossen
 - Dokumentation erstellt und gepflegt
 - Abschlussbericht: `memory/gitea-specs/issue-<number>-final.md`
 - Martin final informiert über Abschluss
 ## Regeln
 - Kein Ticket ohne abschließenden Kommentar schließen
 - Dokumentation so, dass ein neuer Entwickler den Kontext versteht
 - Bei wichtigen Learnings: `MEMORY.md` updaten
--- a/skills/gitea-fix-refactoring/SKILL.md
+++ b/skills/gitea-fix-refactoring/SKILL.md
@@ -0,0 +1,88 @@
 ---
 name: gitea-fix-refactoring
 description: Fix- & Refactoring-Agent für Gitea Issues. Setzt Review-Feedback um, behebt Bugs und reduziert technische Schulden. Teil der Gitea Issue Pipeline.
 ---
 # Fix- & Refactoring-Agent
 Rolle: Wird bei Bedarf eingeschaltet – nach Code Review mit Änderungswünschen oder nach QA-Testfehlern.
 ## Eingang
 - 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)
 ## Aufgaben
 ### Review-Feedback umsetzen
 - Alle 🔴 Must-Fix Comments adressieren
 - Alle 🟡 Should-Fix Comments prüfen und umsetzen
 - Konstruktives Feedback priorisieren
 - Nachvollziehbare Commits pro Fix
 ### Bugs korrigieren
 - Root Cause identifizieren
 - Minimaler, korrekter Fix
 - Regressionstest hinzufügen
 - Keine neuen Bugs einführen
 ### Technische Schulden reduzieren
 - TODOs mit Issue-Referenz auflösen
 - Workarounds durch saubere Lösungen ersetzen
 - Veraltete Patterns modernisieren
 ### Code vereinfachen
 - Überflüssige Komplexität entfernen
 - Verschachtelte Conditionals reduzieren
 - Early Returns nutzen
 - Helper-Methoden extrahieren
 ### Legacy-Code modernisieren
 - Veraltete APIs ersetzen
 - Neue Sprachfeatures nutzen
 - Patterns aktualisieren
 ### Performance verbessern
 - Identifizierte Bottlenecks beheben
 - Ineffiziente Algorithmen ersetzen
 - Caching einführen wo sinnvoll
 - Datenbankabfragen optimieren
 ### Sicherheitslücken schließen
 - Review identifizierte Schwachstellen beheben
 - Input Validation nachziehen
 - Auth/Authz-Lücken schließen
 - Dependencies aktualisieren bei Bedarf
 ### Redundanzen entfernen
 - Doppelten Code zusammenführen
 - Unbenutzte Imports/Variablen entfernen
 - Tote Code-Pfade eliminieren
 ### Module entkoppeln
 - Enge Kopplung reduzieren
 - Interfaces nutzen
 - Dependency Injection wo passend
 - Seiteneffekte isolieren
 ### Typisierung verbessern
 - Strikte Typisierung wo möglich
 - Generics sinnvoll einsetzen
 - Type Guards für Runtime-Sicherheit
 ### Refactorings dokumentieren
 - Was wurde geändert und warum
 - Breaking Changes kenntlich machen
 - Migrationsschritte falls nötig
 ## Ausgang
 - Alle Fixes auf Feature Branch committet
 - Änderungen dokumentiert
 - ⏩ Zurück an den Agent der das Feedback gegeben hat:
  - Bei Review-Feedback → **Code-Review-Agent**
  - Bei QA-Fail → **Test- & QA-Agent**
 ## Regeln
 - Ein Fix = ein Commit (atomic)
 - Kein Refactoring ohne klaren Grund
 - Bei Unsicherheit: Martin fragen
--- a/skills/gitea-implementierung/SKILL.md
+++ b/skills/gitea-implementierung/SKILL.md
@@ -0,0 +1,93 @@
 ---
 name: gitea-implementierung
 description: Implementierungs-Agent für Gitea Issues. Setzt Features und Bugfixes basierend auf der Spezifikation des Analyse-Agents um. Teil der Gitea Issue Pipeline.
 ---
 # Implementierungs-Agent
 Rolle: Zweite Phase der Gitea Issue Pipeline. Setzt die Spezifikation in Code um.
 ## Eingang
 - Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
 - Feature Branch: `feature/issue-<number>-<short-description>`
 - Repo geklont in `/tmp/<repo>` oder Arbeitsverzeichnis
 ## Aufgaben
 ### Features implementieren
 - Spezifikation Schritt für Schritt umsetzen
 - Code modular und wartbar halten
 - Nur das implementieren, was in der Spezifikation steht (kein Scope Creep)
 ### Bugs beheben
 - Ursache identifizieren (Root Cause Analysis)
 - Fix minimal aber korrekt halten
 - Nicht nur Symptome behandeln
 ### Clean Code schreiben
 - Lesbarkeit über Cleverness
 - Aussagekräftige Variablen-/Funktionsnamen
 - Funktionen kurz und fokussiert
 - Kommentare für *warum*, nicht *was*
 ### Bestehenden Code erweitern
 - Bestehende Patterns und Konventionen beachten
 - Keine unnötigen Refactorings im gleichen PR
 - Rückwärtskompatibilität wahren
 ### Datenbankzugriffe implementieren
 - Prepared Statements / Parameterized Queries verwenden
 - Transaktionen wo nötig
 - Index-Nutzung berücksichtigen
 - N+1 Queries vermeiden
 ### APIs integrieren
 - Fehlerbehandlung für externe Calls
 - Timeouts konfigurieren
 - Retry-Logik wo sinnvoll
 - Rate Limits respektieren
 ### UI-Komponenten erstellen
 - Responsive Design beachten
 - Accessibility-Grundlagen einhalten
 - Bestehende Design-System-Komponenten nutzen
 ### Logging integrieren
 - Strukturiertes Logging (JSON wo möglich)
 - Log-Level korrekt setzen (DEBUG/INFO/WARN/ERROR)
 - Keine sensiblen Daten loggen
 - Korrelations-IDs wo hilfreich
 ### Fehlerbehandlung umsetzen
 - Errors niemals stillschweigend schlucken
 - User-freundliche Fehlermeldungen
 - Technische Details ins Logging, nicht in die UI
 - Globale Error-Handler nutzen
 ### Performance optimieren
 - O(n²) vermeiden wo möglich
 - Caching wo sinnvoll
 - Lazy Loading nutzen
 - Große Datenmengen paginieren/streamen
 ### Coding Standards einhalten
 - Linter-Regeln befolgen
 - Formatter nutzen (Prettier, Black, etc.)
 - Projekt-spezifische Konventionen respektieren
 ### Commits strukturieren
 - Kleine, atomare Commits
 - Conventional Commits Format: `type(scope): description`
 - Fix-Referenz: `Fix #<number>: <description>`
 - Kein WIP-Commit am Ende – History clean halten
 ## Ausgang
 - Implementierter Code auf Feature Branch
 - Alle Commits sauber strukturiert
 - Code bereit für Review
 - ⏩ Übergabe an **Code-Review-Agent**
 ## Regeln
 - Keine Secrets/Credentials im Code
 - Keine TODOs zurücklassen (außer mit Issue-Referenz)
 - Bei Blockern sofort Martin informieren
--- a/skills/gitea-issue-resolver/SKILL.md
+++ b/skills/gitea-issue-resolver/SKILL.md
@@ -1,9 +1,11 @@
 ---
 name: gitea-issue-resolver
-description: Resolve open Gitea issues by creating feature branches, implementing fixes, and committing. 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 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
+# Gitea Issue Resolver – Pipeline Orchestrator
 Koordiniert die gesamte Issue-Pipeline. Holt Issues ab und steuert sie durch die 9 Phasen.
 ## Authentication
@@ -14,43 +16,113 @@ GIT_USER=$(echo "$GIT_CREDS" | sed -n 's|.*://\([^:]*\):.*|\1|p')
 GIT_PASS=$(echo "$GIT_CREDS" | sed -n 's|.*://[^:]*:\([^@]*\)@.*|\1|p')
 ```
-For API calls use `-u "$GIT_USER:$GIT_PASS"`. If Basic Auth fails, ask Martin for a Gitea API token.
+Gitea API token: `$GITEA_TOKEN` (in `.bashrc`):
 ```bash
 GITEA_TOKEN="568841…2e34"
 ```
-## Workflow
+## Pipeline – 9 Phasen
-### 1. Check for Open Issues
+### Issue-Filter
 Nur Issues mit **beiden** Tags: `KI` **und** `ReadyForDev`:
 ```bash
-curl -s "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues?state=open" \
+curl -s "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues?state=open&labels=KI,ReadyForDev" \
  -u "$GIT_USER:$GIT_PASS"
 ```
-### 2. For Each Open Issue
+### Phase 1: Analyse- & Architektur-Agent → `gitea-analyse-architektur`
 - Anforderungen analysieren
 - Architektur entwerfen
 - Spezifikation erstellen
 - Output: `memory/gitea-specs/issue-<number>.md`
-1. **Create a feature branch** from `main`:
+### Phase 2: Implementierungs-Agent → `gitea-implementierung`
-   ```bash
+- Feature Branch erstellen
-   git checkout main && git pull
+- Code schreiben
-   git checkout -b feature/issue-<number>-<short-description>
+- 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 ✅
 ```
-2. **Clone repo if needed** (work in a temp dir):
+## Orchestrierung
   ```bash
   git clone https://git.home.kies-media.de/<owner>/<repo>.git /tmp/<repo>
   ```
-3. **Implement the fix** – read the issue body, understand the requirement, implement it.
+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
 4. Martin bei wichtigen Meilensteinen informieren:
   - Spezifikation fertig (Phase 1)
   - PR erstellt (Phase 6)
   - Deployment erfolgreich (Phase 7)
   - Issue geschlossen (Phase 9)
-4. **Commit and push**:
+## Regeln
-   ```bash
+- **Nur** Issues mit Tags `KI` + `ReadyForDev`
-   git add -A
+- **Nie** ohne Martins Freigabe mergen
-   git commit -m "Fix #<number>: <description>"
+- **Nie** Issue selbst schließen (nur Phase 9 darf das)
-   git push -u origin feature/issue-<number>-<short-description>
+- **Nie** direkt auf `main` pushen
-   ```
+- Bei Blockern: sofort Martin informieren
 5. **Inform Martin** – send a summary of what was done and that the branch is ready for review/merge.
 ### 3. Do NOT
 - Do not merge the branch yourself
 - Do not close the issue yourself
 - Do not push to `main` directly
--- a/skills/gitea-merge-release/SKILL.md
+++ b/skills/gitea-merge-release/SKILL.md
@@ -0,0 +1,91 @@
 ---
 name: gitea-merge-release
 description: Merge- & Release-Agent für Gitea Issues. Verwaltet Pull Requests, Releases und Versionierung. Teil der Gitea Issue Pipeline.
 ---
 # Merge- & Release-Agent
 Rolle: Fünfte Phase – nach erfolgreichem Review und QA. Kümmert sich um Merge und Release-Vorbereitung.
 ## Eingang
 - Feature Branch mit APPROVED Code und PASS-Status im QA
 - QA-Report: `memory/gitea-specs/issue-<number>-qa.md` (PASS)
 - Spezifikation: `memory/gitea-specs/issue-<number>.md`
 ## Aufgaben
 ### Pull Requests verwalten
 - PR via Gitea API erstellen:
 ```bash
 curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/pulls" \
  -H "Authorization: token $GITEA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "head": "feature/issue-<number>-<short-description>",
    "base": "main",
    "title": "Fix #<number>: <description>",
    "body": "Resolves #<number>\n\nSpec: memory/gitea-specs/issue-<number>.md\nQA: PASS"
  }'
 ```
 - PR-Beschreibung vollständig ausfüllen
 - Labels und Assignees setzen
 ### Merge-Konflikte lösen
 - `main` in Feature Branch mergen
 - Konflikte manuell auflösen
 - Sicherstellen dass Tests noch grün
 - Bei komplexen Konflikten: Martin involvieren
 ### Release Notes erstellen
 - Änderungen zusammenfassen (user-facing)
 - Breaking Changes hervorheben
 - Neue Features / Bugfixes / Verbesserungen kategorisieren
 - Contributors erwähnen falls relevant
 ### Versionen verwalten
 - Aktuelle Version aus `package.json` / `VERSION` / Git Tags auslesen
 - Nächste Version nach Schema festlegen
 ### Semantic Versioning anwenden
 - **PATCH** (x.y.Z): Bugfixes, keine neuen Features
 - **MINOR** (x.Y.z): Neue Features, rückwärtskompatibel
 - **MAJOR** (X.y.z): Breaking Changes
 - Pre-Release Tags bei Bedarf: `-alpha`, `-beta`, `-rc.1`
 ### Changelogs generieren
 - Alle Commits seit letztem Release sammeln
 - Nach Typ gruppieren (feat/fix/refactor/chore)
 - In CHANGELOG.md eintragen
 - Format: Keep a Changelog
 ### Release-Tags erstellen
 ```bash
 git tag -a v<version> -m "Release v<version>: <summary>"
 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
 ### Build-Artefakte validieren
 - Build erfolgreich?
 - Artefakt-Größe plausibel?
 - Checksummen verifizieren
 - Signaturen wo nötig
 ### Release-Freigaben koordinieren
 - Martin über Release informieren
 - PR-Link und Release Notes senden
 - Auf Martins Freigabe warten vor Merge
 ## Ausgang
 - PR erstellt und Martin informiert
 - Warte auf Martins Merge-Freigabe
 - Nach Freigabe: ⏩ Deployment-Agent
 ## Regeln
 - **NIEMALS** ohne Martins Freigabe mergen
 - **NIEMALS** direkt auf `main` pushen
 - Release Notes IMMER vor dem Merge erstellen
--- a/skills/gitea-test-qa/SKILL.md
+++ b/skills/gitea-test-qa/SKILL.md
@@ -0,0 +1,91 @@
 ---
 name: gitea-test-qa
 description: Test- & QA-Agent für Gitea Issues. Erstellt und führt Tests durch, sichert Qualität ab. Teil der Gitea Issue Pipeline.
 ---
 # Test- & QA-Agent
 Rolle: Vierte Phase der Gitea Issue Pipeline. Stellt sicher, dass die Implementierung korrekt und robust ist.
 ## Eingang
 - Feature Branch mit APPROVED Code
 - Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
 - Review-Ergebnis: `memory/gitea-specs/issue-<number>-review.md`
 ## Aufgaben
 ### Unit-Tests erstellen
 - Für jede neue Funktion/Methode
 - Positive und Negative Cases
 - Grenzwerte testen
 - Mocking für externe Abhängigkeiten
 ### Integrationstests erstellen
 - Modulgrenzen testen
 - Datenbank-Integration prüfen
 - API-End-to-End innerhalb des Services
 - externe API-Mocks nutzen
 ### E2E-Tests durchführen
 - Nutzerflows durchspielen
 - Kritische Pfade abdecken
 - Browser-basiert wenn UI betroffen
 ### Regressionstests ausführen
 - Bestehende Test-Suite laufen lassen
 - Sicherstellen dass nichts kaputt gegangen ist
 - Bei Fehlschlägen: Root Cause dokumentieren
 ### Testdaten generieren
 - Realistische Testdaten erzeugen
 - Edge Cases in Testdaten abdecken
 - Keine Produktionsdaten verwenden
 - Testdaten reproduzierbar (Seeds/Fixtures)
 ### Fehler reproduzieren
 - Gemeldete Bugs nachstellen
 - Minimal reproduzierbares Example erstellen
 - Umgebungsdetails dokumentieren
 ### Edge Cases testen
 - Leere Eingaben
 - Ungültige Formate
 - Gleichzeitige Zugriffe
 - Netzwerkfehler / Timeouts
 - Datenüberläufe / Grenzwerte
 ### API-Tests durchführen
 - Alle Endpoints abdecken
 - Status Codes verifizieren
 - Response-Schemas validieren
 - Auth/Authz testen
 - Rate Limiting prüfen
 ### UI-Tests automatisieren
 - Kritische User Flows
 - Formularvalidierung
 - Responsive Breakpoints
 - Accessibility-Basics
 ### Performance-Tests ausführen
 - Antwortzeiten messen
 - Lasttests bei relevanten Endpoints
 - Memory-Verbrauch prüfen
 - Bottlenecks identifizieren
 ### Testreports erstellen
 - Ergebnisse zusammenfassen in `memory/gitea-specs/issue-<number>-qa.md`
 - Testabdeckung (%)
 - Gefundene Issues mit Schweregrad
 - Gesamtbewertung: PASS / FAIL / PASS_WITH_ISSUES
 ## Ausgang
 - Test-Code auf Feature Branch committet
 - QA-Report: `memory/gitea-specs/issue-<number>-qa.md`
 - Status: **PASS** → ⏩ Merge- & Release-Agent
 - Status: **FAIL** → ⏩ Fix- & Refactoring-Agent
 ## Regeln
 - Keine Tests nur für die Statistik – jeder Test muss einen Wert haben
 - Flaky Tests sofort fixen oder entfernen
 - Performance-Regressionen als FAIL werten