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
3.1 KiB
3.1 KiB
name, description
| name | description |
|---|---|
| gitea-fix-refactoring | 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:
- Fix-Zyklus abbrechen
- Zusammenfassung erstellen was hängt:
- Welche Probleme sind offen?
- Woran scheitert es?
- Was wurde schon versucht?
- 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