f94cfb41e6
- 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
109 lines
3.1 KiB
Markdown
109 lines
3.1 KiB
Markdown
---
|
||
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)
|
||
- 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
|
||
|
||
### 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
|
||
- Zyklus-Counter inkrementiert
|
||
- ⏩ Zurück an den Agent der das Feedback gegeben hat:
|
||
- Bei Review-Feedback → **Code-Review-Agent** (Phase 3)
|
||
- 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
|