diff --git a/memory/2026-05-10-1853.md b/memory/2026-05-10-1853.md new file mode 100644 index 0000000..55dee17 --- /dev/null +++ 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. 🐾 diff --git a/memory/2026-05-10-2004.md b/memory/2026-05-10-2004.md new file mode 100644 index 0000000..7df134e --- /dev/null +++ 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? diff --git a/memory/email-check.log b/memory/email-check.log index 7317bc1..f1c5972 100644 --- 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 diff --git a/skills/gitea-abnahme-validierung/SKILL.md b/skills/gitea-abnahme-validierung/SKILL.md new file mode 100644 index 0000000..bf42e1b --- /dev/null +++ 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-.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--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--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 diff --git a/skills/gitea-analyse-architektur/SKILL.md b/skills/gitea-analyse-architektur/SKILL.md new file mode 100644 index 0000000..d7efe99 --- /dev/null +++ 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-.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-.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 diff --git a/skills/gitea-code-review/SKILL.md b/skills/gitea-code-review/SKILL.md new file mode 100644 index 0000000..445c760 --- /dev/null +++ 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-.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--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 diff --git a/skills/gitea-deployment/SKILL.md b/skills/gitea-deployment/SKILL.md new file mode 100644 index 0000000..bd5456c --- /dev/null +++ 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 pushen: `docker push /:` +- 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 diff --git a/skills/gitea-dokumentation-closing/SKILL.md b/skills/gitea-dokumentation-closing/SKILL.md new file mode 100644 index 0000000..924a11e --- /dev/null +++ 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-.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///issues/" \ + -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--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/`) + +## Ausgang +- Issue geschlossen +- Dokumentation erstellt und gepflegt +- Abschlussbericht: `memory/gitea-specs/issue--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 diff --git a/skills/gitea-fix-refactoring/SKILL.md b/skills/gitea-fix-refactoring/SKILL.md new file mode 100644 index 0000000..a6f4f28 --- /dev/null +++ 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--review.md` (CHANGES_REQUESTED) +- oder QA-Report: `memory/gitea-specs/issue--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 diff --git a/skills/gitea-implementierung/SKILL.md b/skills/gitea-implementierung/SKILL.md new file mode 100644 index 0000000..c5172f2 --- /dev/null +++ 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-.md` +- Feature Branch: `feature/issue--` +- Repo geklont in `/tmp/` 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 #: ` +- 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 diff --git a/skills/gitea-issue-resolver/SKILL.md b/skills/gitea-issue-resolver/SKILL.md index ad7b7eb..6308240 100644 --- 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///issues?state=open" \ +curl -s "https://git.home.kies-media.de/api/v1/repos///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-.md` -1. **Create a feature branch** from `main`: - ```bash - git checkout main && git pull - git checkout -b feature/issue-- - ``` +### Phase 2: Implementierungs-Agent → `gitea-implementierung` +- Feature Branch erstellen +- Code schreiben +- Commits strukturieren +- Output: Code auf Feature Branch -2. **Clone repo if needed** (work in a temp dir): - ```bash - git clone https://git.home.kies-media.de//.git /tmp/ - ``` +### Phase 3: Code-Review-Agent → `gitea-code-review` +- Codequalität & Sicherheit prüfen +- Review-Kommentare erstellen +- Output: APPROVED oder CHANGES_REQUESTED -3. **Implement the fix** – read the issue body, understand the requirement, implement it. +### Phase 4: Test- & QA-Agent → `gitea-test-qa` +- Unit-, Integration-, E2E-Tests +- QA-Report erstellen +- Output: PASS oder FAIL -4. **Commit and push**: - ```bash - git add -A - git commit -m "Fix #: " - git push -u origin feature/issue-- - ``` +### Phase 5: Fix- & Refactoring-Agent → `gitea-fix-refactoring` *(bei Bedarf)* +- Review-Feedback umsetzen +- Bugs korrigieren +- Danach zurück zur jeweiligen Phase (Review oder QA) -5. **Inform Martin** – send a summary of what was done and that the branch is ready for review/merge. +### Phase 6: Merge- & Release-Agent → `gitea-merge-release` +- PR erstellen +- Release Notes & Versionierung +- Warten auf Martins Freigabe -### 3. Do NOT +### Phase 7: Deployment-Agent → `gitea-deployment` +- Anwendungen deployen +- Health Checks +- Bei Problemen: Rollback -- Do not merge the branch yourself -- Do not close the issue yourself -- Do not push to `main` directly +### 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: +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) + +## 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 `main` pushen +- Bei Blockern: sofort Martin informieren diff --git a/skills/gitea-merge-release/SKILL.md b/skills/gitea-merge-release/SKILL.md new file mode 100644 index 0000000..d7634b1 --- /dev/null +++ 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--qa.md` (PASS) +- Spezifikation: `memory/gitea-specs/issue-.md` + +## Aufgaben + +### Pull Requests verwalten +- PR via Gitea API erstellen: +```bash +curl -s -X POST "https://git.home.kies-media.de/api/v1/repos///pulls" \ + -H "Authorization: token $GITEA_TOKEN" \ + -H "Content-Type: application/json" \ + -d '{ + "head": "feature/issue--", + "base": "main", + "title": "Fix #: ", + "body": "Resolves #\n\nSpec: memory/gitea-specs/issue-.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 -m "Release v: " +git push origin v +``` + +### 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 diff --git a/skills/gitea-test-qa/SKILL.md b/skills/gitea-test-qa/SKILL.md new file mode 100644 index 0000000..62de775 --- /dev/null +++ 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-.md` +- Review-Ergebnis: `memory/gitea-specs/issue--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--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--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