frank/forgecli

Watch

Fork 0

Strukturelle Analyse der Codebase #59

New issue

Open

opened 2026-07-13 02:32:21 +02:00 by frank · 0 comments

frank commented

2026-07-13 02:32:21 +02:00

Owner

Auftrag: Strukturelle Codebase-Analyse und gezielte Refaktorierung

Analysiere die gesamte Codebase systematisch hinsichtlich:

Wartbarkeit
Performance
Security
Architektur und struktureller Qualität
Fehleranfälligkeit und technischer Schulden

Führe anschließend konkrete Verbesserungen direkt im Repository durch.

Ziel

Die Codebase soll nach der Bearbeitung:

leichter verständlich und erweiterbar sein,
klarere Verantwortlichkeiten besitzen,
weniger Redundanz enthalten,
sicherer gegen typische Angriffsvektoren sein,
unnötige Ressourcenverwendung vermeiden,
besser testbar sein,
keine unbegründeten oder riskanten Verhaltensänderungen enthalten.

Arbeite evidenzbasiert. Verändere keinen Code ausschließlich aufgrund persönlicher Stilpräferenzen.

Phase 1: Repository und System verstehen

Untersuche zunächst:

Projektstruktur
verwendete Programmiersprachen und Frameworks
Build-, Test- und Deployment-Prozesse
Anwendungseinstiegspunkte
zentrale Module und Abhängigkeiten
Datenflüsse
externe Schnittstellen
Authentifizierung und Autorisierung
Datenbankzugriffe
Konfigurationsverwaltung
Logging und Fehlerbehandlung
Hintergrundprozesse
Netzwerkkommunikation
Datei- und Ressourcenverwaltung

Erstelle daraus ein kompaktes Architekturmodell.

Identifiziere insbesondere:

kritische Ausführungspfade,
Vertrauensgrenzen,
sicherheitsrelevante Komponenten,
performancekritische Bereiche,
stark gekoppelte Module,
globale Zustände,
zyklische Abhängigkeiten,
unklare Verantwortlichkeiten.

Phase 2: Strukturelle Analyse

Prüfe die Codebase auf folgende Probleme.

Wartbarkeit

übergroße Dateien, Klassen oder Funktionen
hohe zyklomatische und kognitive Komplexität
unklare Namensgebung
vermischte Verantwortlichkeiten
Copy-and-paste-Code
unnötige Abstraktionen
fehlende Abstraktionen
versteckte Seiteneffekte
globale oder implizite Zustände
schwer nachvollziehbare Kontrollflüsse
zyklische Modulabhängigkeiten
enge Kopplung
geringe Kohäsion
fehlende Typisierung oder unklare Datenmodelle
inkonsistente Fehlerbehandlung
unzureichende Tests
veraltete oder nicht verwendete Komponenten
tote Codepfade
fehlerhafte oder irreführende Kommentare
Magic Numbers und hart codierte Werte

Performance

unnötig wiederholte Berechnungen
ineffiziente Schleifen oder Datenstrukturen
N+1-Abfragen
unnötige Datenbankzugriffe
fehlende Indizes, soweit aus dem Repository ableitbar
blockierende Operationen in asynchronen Pfaden
unnötige Netzwerkaufrufe
fehlendes Caching
unkontrolliertes Caching
übermäßige Serialisierung
unnötige Speicherallokationen
Memory Leaks
nicht geschlossene Dateien, Streams oder Verbindungen
unnötig große Payloads
ineffiziente Start-up- oder Build-Prozesse
schlecht begrenzte Parallelität
Race Conditions
unkontrollierte Retry-Schleifen
fehlende Timeouts
unbeschränkte Datenmengen
algorithmisch ungünstige Implementierungen

Optimiere nur dort, wo die Verbesserung nachvollziehbar ist. Vermeide spekulative Mikrooptimierungen.

Security

Prüfe unter anderem auf:

fehlende Eingabevalidierung
SQL-, Command-, Template- oder Code-Injection
Cross-Site Scripting
Cross-Site Request Forgery
Server-Side Request Forgery
Path Traversal
unsichere Deserialisierung
offene Redirects
fehlerhafte Authentifizierung
fehlerhafte Autorisierung
horizontale oder vertikale Privilege Escalation
Insecure Direct Object References
unsichere Datei-Uploads
unsichere Dateizugriffe
ungeschützte administrative Funktionen
Secrets im Quellcode
schwache kryptografische Verfahren
vorhersehbare Tokens
fehlende Token-Validierung
unsichere Session-Verwaltung
fehlende Rate Limits
Brute-Force-Risiken
unsichere CORS-Konfiguration
unsichere Header
detaillierte interne Fehlermeldungen
Logging sensibler Daten
fehlende Timeouts und Größenlimits
Supply-Chain-Risiken
gefährliche Abhängigkeiten
unsichere Standardkonfigurationen
unzureichende Mandantentrennung
TOCTOU-Probleme
Race Conditions mit Security-Auswirkung
unzureichende Berechtigungen bei Dateien oder Ressourcen

Berücksichtige die konkrete Technologie und das tatsächliche Bedrohungsmodell des Projekts.

Phase 3: Findings priorisieren

Dokumentiere jedes relevante Finding mit:

Titel
Kategorie
betroffene Dateien und Funktionen
technische Ursache
konkrete Auswirkung
realistisches Fehlerszenario oder Angriffsszenario
Evidenz aus dem Code
Priorität
empfohlene Maßnahme
Risiko der Änderung

Verwende folgende Prioritäten:

Kritisch
Hoch
Mittel
Niedrig
Informativ

Ordne Findings nicht allein nach theoretischer Schwere ein. Berücksichtige:

Erreichbarkeit
Ausnutzbarkeit
betroffene Daten und Systeme
Auftretenswahrscheinlichkeit
Blast Radius
bestehende Schutzmaßnahmen
operative Relevanz

Phase 4: Verbesserungsplan

Erstelle vor größeren Änderungen einen konkreten Plan.

Der Plan soll enthalten:

welche Änderungen durchgeführt werden,
welche Dateien betroffen sind,
welche Abhängigkeiten bestehen,
welche Änderungen das größte Risiko tragen,
wie die Funktionalität verifiziert wird,
welche Tests ergänzt oder angepasst werden,
wie Verhaltensänderungen vermieden werden.

Bevorzuge kleine, logisch getrennte Änderungen.

Phase 5: Umsetzung

Setze die identifizierten Verbesserungen direkt um.

Regeln für Änderungen

Bestehendes externes Verhalten möglichst erhalten.
Keine öffentlichen APIs ohne zwingenden Grund verändern.
Keine großflächige Neuschreibung, wenn eine gezielte Änderung genügt.
Keine neuen Frameworks oder Abhängigkeiten ohne klaren Mehrwert einführen.
Keine Security-Kontrollen entfernen oder abschwächen.
Fehler nicht verschlucken.
Keine sensiblen Daten zusätzlich protokollieren.
Keine Tests löschen, nur um einen Build grün zu bekommen.
Keine Warnungen oder Fehler pauschal deaktivieren.
Keine unsicheren Type-Casts oder Validierungs-Bypässe als Abkürzung verwenden.
Keine Performanceoptimierung durchführen, die Korrektheit oder Lesbarkeit unverhältnismäßig verschlechtert.

Wartbarkeitsverbesserungen

Nutze bei Bedarf:

Extraktion klarer Module
Trennung von Verantwortlichkeiten
Dependency Injection
explizite Schnittstellen
stärkere Typisierung
zentrale Validierung
konsistente Fehlerobjekte
Reduktion globaler Zustände
Entfernung toten Codes
Zusammenführung tatsächlicher Duplikate
Vereinfachung verschachtelter Kontrollflüsse
bessere Testbarkeit

Vermeide Abstraktionen, die nur einmal verwendet werden und keinen erkennbaren strukturellen Nutzen liefern.

Performanceverbesserungen

Bei Performanceänderungen:

dokumentiere den vorherigen Engpass,
beschreibe die erwartete Verbesserung,
ergänze nach Möglichkeit Benchmarks oder Messungen,
erhalte funktionale Korrektheit,
begrenze Speicher-, Netzwerk- und Parallelitätsverbrauch,
ergänze Timeouts, Limits und Abbruchmöglichkeiten.

Security-Fixes

Bei Security-Fixes:

behebe die Ursache und nicht nur das Symptom,
validiere Eingaben an Vertrauensgrenzen,
verwende parametrisierte APIs,
führe Autorisierungsprüfungen serverseitig durch,
verwende Allowlisting, wo sinnvoll,
reduziere Berechtigungen,
verhindere Informationslecks,
ergänze sichere Defaults,
teste negative und missbräuchliche Eingaben,
achte darauf, dass Schutzmaßnahmen nicht umgangen werden können.

Phase 6: Tests und Verifikation

Führe alle verfügbaren Prüfungen aus:

Build
Unit-Tests
Integrationstests
End-to-End-Tests
Linter
Formatter
Type-Checker
statische Analyse
Security-Scanner
Dependency-Audit
projektspezifische Validierungen

Ergänze Tests insbesondere für:

behobene Bugs
Security-Grenzfälle
Autorisierungsentscheidungen
Eingabevalidierung
Fehlerpfade
Race Conditions
Ressourcenfreigabe
Performancekritische Logik
bislang ungetestete zentrale Komponenten

Falls Tests oder Tools nicht ausführbar sind, dokumentiere:

den genauen Befehl,
die Fehlermeldung,
die wahrscheinliche Ursache,
welche Validierung stattdessen durchgeführt wurde.

Behaupte keine erfolgreiche Prüfung, die nicht tatsächlich ausgeführt wurde.

Phase 7: Abschlussbericht

Erstelle am Ende einen strukturierten Bericht mit:

1. Architekturübersicht

zentrale Komponenten
Abhängigkeiten
Datenflüsse
Vertrauensgrenzen

2. Wichtigste Findings

Je Finding:

Priorität
Kategorie
Ursache
Auswirkung
betroffene Dateien
Status: behoben, teilweise behoben oder offen

3. Durchgeführte Änderungen

Datei
Änderung
Begründung
erwartete Wirkung

4. Verifikation

ausgeführte Befehle
Testergebnisse
Build-Ergebnis
Analyseergebnisse
verbleibende Warnungen

5. Verbleibende Risiken

noch offene technische Schulden
nicht verifizierbare Annahmen
größere Architekturprobleme
empfohlene Folgearbeiten

6. Änderungssicherheit

Bewerte abschließend:

Risiko funktionaler Regressionen
Risiko von API-Brüchen
Risiko von Datenmigrationen
Risiko von Deployment-Problemen

Arbeitsweise

Arbeite in dieser Reihenfolge:

Codebase verstehen
Architektur und Angriffsflächen modellieren
Findings sammeln
Findings priorisieren
Verbesserungsplan erstellen
Änderungen implementieren
Tests und Analysen ausführen
Ergebnisse erneut prüfen
Abschlussbericht erstellen

Beginne nicht sofort mit großflächigen Refactorings.

Teile frühzeitig konkrete Findings mit, sobald sie eindeutig belegt sind. Arbeite danach weiter, bis Analyse, Umsetzung und Verifikation abgeschlossen sind.

Falls mehrere unabhängige Probleme existieren, bearbeite zuerst:

kritische Security-Probleme
Fehler mit Datenverlust- oder Stabilitätsrisiko
strukturelle Ursachen wiederkehrender Fehler
messbare Performanceprobleme
allgemeine Wartbarkeitsverbesserungen

Erwartetes Ergebnis

Das Endergebnis soll aus folgenden Bestandteilen bestehen:

einer strukturellen Analyse,
priorisierten Findings,
konkreten Codeänderungen,
ergänzten oder aktualisierten Tests,
ausgeführten Verifikationen,
einer transparenten Liste verbleibender Risiken.

Führe die Analyse und die Änderungen jetzt im aktuell geöffneten Repository durch.

# Auftrag: Strukturelle Codebase-Analyse und gezielte Refaktorierung Analysiere die gesamte Codebase systematisch hinsichtlich: 1. Wartbarkeit 2. Performance 3. Security 4. Architektur und struktureller Qualität 5. Fehleranfälligkeit und technischer Schulden Führe anschließend konkrete Verbesserungen direkt im Repository durch. ## Ziel Die Codebase soll nach der Bearbeitung: - leichter verständlich und erweiterbar sein, - klarere Verantwortlichkeiten besitzen, - weniger Redundanz enthalten, - sicherer gegen typische Angriffsvektoren sein, - unnötige Ressourcenverwendung vermeiden, - besser testbar sein, - keine unbegründeten oder riskanten Verhaltensänderungen enthalten. Arbeite evidenzbasiert. Verändere keinen Code ausschließlich aufgrund persönlicher Stilpräferenzen. --- ## Phase 1: Repository und System verstehen Untersuche zunächst: - Projektstruktur - verwendete Programmiersprachen und Frameworks - Build-, Test- und Deployment-Prozesse - Anwendungseinstiegspunkte - zentrale Module und Abhängigkeiten - Datenflüsse - externe Schnittstellen - Authentifizierung und Autorisierung - Datenbankzugriffe - Konfigurationsverwaltung - Logging und Fehlerbehandlung - Hintergrundprozesse - Netzwerkkommunikation - Datei- und Ressourcenverwaltung Erstelle daraus ein kompaktes Architekturmodell. Identifiziere insbesondere: - kritische Ausführungspfade, - Vertrauensgrenzen, - sicherheitsrelevante Komponenten, - performancekritische Bereiche, - stark gekoppelte Module, - globale Zustände, - zyklische Abhängigkeiten, - unklare Verantwortlichkeiten. --- ## Phase 2: Strukturelle Analyse Prüfe die Codebase auf folgende Probleme. ### Wartbarkeit - übergroße Dateien, Klassen oder Funktionen - hohe zyklomatische und kognitive Komplexität - unklare Namensgebung - vermischte Verantwortlichkeiten - Copy-and-paste-Code - unnötige Abstraktionen - fehlende Abstraktionen - versteckte Seiteneffekte - globale oder implizite Zustände - schwer nachvollziehbare Kontrollflüsse - zyklische Modulabhängigkeiten - enge Kopplung - geringe Kohäsion - fehlende Typisierung oder unklare Datenmodelle - inkonsistente Fehlerbehandlung - unzureichende Tests - veraltete oder nicht verwendete Komponenten - tote Codepfade - fehlerhafte oder irreführende Kommentare - Magic Numbers und hart codierte Werte ### Performance - unnötig wiederholte Berechnungen - ineffiziente Schleifen oder Datenstrukturen - N+1-Abfragen - unnötige Datenbankzugriffe - fehlende Indizes, soweit aus dem Repository ableitbar - blockierende Operationen in asynchronen Pfaden - unnötige Netzwerkaufrufe - fehlendes Caching - unkontrolliertes Caching - übermäßige Serialisierung - unnötige Speicherallokationen - Memory Leaks - nicht geschlossene Dateien, Streams oder Verbindungen - unnötig große Payloads - ineffiziente Start-up- oder Build-Prozesse - schlecht begrenzte Parallelität - Race Conditions - unkontrollierte Retry-Schleifen - fehlende Timeouts - unbeschränkte Datenmengen - algorithmisch ungünstige Implementierungen Optimiere nur dort, wo die Verbesserung nachvollziehbar ist. Vermeide spekulative Mikrooptimierungen. ### Security Prüfe unter anderem auf: - fehlende Eingabevalidierung - SQL-, Command-, Template- oder Code-Injection - Cross-Site Scripting - Cross-Site Request Forgery - Server-Side Request Forgery - Path Traversal - unsichere Deserialisierung - offene Redirects - fehlerhafte Authentifizierung - fehlerhafte Autorisierung - horizontale oder vertikale Privilege Escalation - Insecure Direct Object References - unsichere Datei-Uploads - unsichere Dateizugriffe - ungeschützte administrative Funktionen - Secrets im Quellcode - schwache kryptografische Verfahren - vorhersehbare Tokens - fehlende Token-Validierung - unsichere Session-Verwaltung - fehlende Rate Limits - Brute-Force-Risiken - unsichere CORS-Konfiguration - unsichere Header - detaillierte interne Fehlermeldungen - Logging sensibler Daten - fehlende Timeouts und Größenlimits - Supply-Chain-Risiken - gefährliche Abhängigkeiten - unsichere Standardkonfigurationen - unzureichende Mandantentrennung - TOCTOU-Probleme - Race Conditions mit Security-Auswirkung - unzureichende Berechtigungen bei Dateien oder Ressourcen Berücksichtige die konkrete Technologie und das tatsächliche Bedrohungsmodell des Projekts. --- ## Phase 3: Findings priorisieren Dokumentiere jedes relevante Finding mit: - Titel - Kategorie - betroffene Dateien und Funktionen - technische Ursache - konkrete Auswirkung - realistisches Fehlerszenario oder Angriffsszenario - Evidenz aus dem Code - Priorität - empfohlene Maßnahme - Risiko der Änderung Verwende folgende Prioritäten: - Kritisch - Hoch - Mittel - Niedrig - Informativ Ordne Findings nicht allein nach theoretischer Schwere ein. Berücksichtige: - Erreichbarkeit - Ausnutzbarkeit - betroffene Daten und Systeme - Auftretenswahrscheinlichkeit - Blast Radius - bestehende Schutzmaßnahmen - operative Relevanz --- ## Phase 4: Verbesserungsplan Erstelle vor größeren Änderungen einen konkreten Plan. Der Plan soll enthalten: - welche Änderungen durchgeführt werden, - welche Dateien betroffen sind, - welche Abhängigkeiten bestehen, - welche Änderungen das größte Risiko tragen, - wie die Funktionalität verifiziert wird, - welche Tests ergänzt oder angepasst werden, - wie Verhaltensänderungen vermieden werden. Bevorzuge kleine, logisch getrennte Änderungen. --- ## Phase 5: Umsetzung Setze die identifizierten Verbesserungen direkt um. ### Regeln für Änderungen - Bestehendes externes Verhalten möglichst erhalten. - Keine öffentlichen APIs ohne zwingenden Grund verändern. - Keine großflächige Neuschreibung, wenn eine gezielte Änderung genügt. - Keine neuen Frameworks oder Abhängigkeiten ohne klaren Mehrwert einführen. - Keine Security-Kontrollen entfernen oder abschwächen. - Fehler nicht verschlucken. - Keine sensiblen Daten zusätzlich protokollieren. - Keine Tests löschen, nur um einen Build grün zu bekommen. - Keine Warnungen oder Fehler pauschal deaktivieren. - Keine unsicheren Type-Casts oder Validierungs-Bypässe als Abkürzung verwenden. - Keine Performanceoptimierung durchführen, die Korrektheit oder Lesbarkeit unverhältnismäßig verschlechtert. ### Wartbarkeitsverbesserungen Nutze bei Bedarf: - Extraktion klarer Module - Trennung von Verantwortlichkeiten - Dependency Injection - explizite Schnittstellen - stärkere Typisierung - zentrale Validierung - konsistente Fehlerobjekte - Reduktion globaler Zustände - Entfernung toten Codes - Zusammenführung tatsächlicher Duplikate - Vereinfachung verschachtelter Kontrollflüsse - bessere Testbarkeit Vermeide Abstraktionen, die nur einmal verwendet werden und keinen erkennbaren strukturellen Nutzen liefern. ### Performanceverbesserungen Bei Performanceänderungen: - dokumentiere den vorherigen Engpass, - beschreibe die erwartete Verbesserung, - ergänze nach Möglichkeit Benchmarks oder Messungen, - erhalte funktionale Korrektheit, - begrenze Speicher-, Netzwerk- und Parallelitätsverbrauch, - ergänze Timeouts, Limits und Abbruchmöglichkeiten. ### Security-Fixes Bei Security-Fixes: - behebe die Ursache und nicht nur das Symptom, - validiere Eingaben an Vertrauensgrenzen, - verwende parametrisierte APIs, - führe Autorisierungsprüfungen serverseitig durch, - verwende Allowlisting, wo sinnvoll, - reduziere Berechtigungen, - verhindere Informationslecks, - ergänze sichere Defaults, - teste negative und missbräuchliche Eingaben, - achte darauf, dass Schutzmaßnahmen nicht umgangen werden können. --- ## Phase 6: Tests und Verifikation Führe alle verfügbaren Prüfungen aus: - Build - Unit-Tests - Integrationstests - End-to-End-Tests - Linter - Formatter - Type-Checker - statische Analyse - Security-Scanner - Dependency-Audit - projektspezifische Validierungen Ergänze Tests insbesondere für: - behobene Bugs - Security-Grenzfälle - Autorisierungsentscheidungen - Eingabevalidierung - Fehlerpfade - Race Conditions - Ressourcenfreigabe - Performancekritische Logik - bislang ungetestete zentrale Komponenten Falls Tests oder Tools nicht ausführbar sind, dokumentiere: - den genauen Befehl, - die Fehlermeldung, - die wahrscheinliche Ursache, - welche Validierung stattdessen durchgeführt wurde. Behaupte keine erfolgreiche Prüfung, die nicht tatsächlich ausgeführt wurde. --- ## Phase 7: Abschlussbericht Erstelle am Ende einen strukturierten Bericht mit: ### 1. Architekturübersicht - zentrale Komponenten - Abhängigkeiten - Datenflüsse - Vertrauensgrenzen ### 2. Wichtigste Findings Je Finding: - Priorität - Kategorie - Ursache - Auswirkung - betroffene Dateien - Status: behoben, teilweise behoben oder offen ### 3. Durchgeführte Änderungen - Datei - Änderung - Begründung - erwartete Wirkung ### 4. Verifikation - ausgeführte Befehle - Testergebnisse - Build-Ergebnis - Analyseergebnisse - verbleibende Warnungen ### 5. Verbleibende Risiken - noch offene technische Schulden - nicht verifizierbare Annahmen - größere Architekturprobleme - empfohlene Folgearbeiten ### 6. Änderungssicherheit Bewerte abschließend: - Risiko funktionaler Regressionen - Risiko von API-Brüchen - Risiko von Datenmigrationen - Risiko von Deployment-Problemen --- ## Arbeitsweise Arbeite in dieser Reihenfolge: 1. Codebase verstehen 2. Architektur und Angriffsflächen modellieren 3. Findings sammeln 4. Findings priorisieren 5. Verbesserungsplan erstellen 6. Änderungen implementieren 7. Tests und Analysen ausführen 8. Ergebnisse erneut prüfen 9. Abschlussbericht erstellen Beginne nicht sofort mit großflächigen Refactorings. Teile frühzeitig konkrete Findings mit, sobald sie eindeutig belegt sind. Arbeite danach weiter, bis Analyse, Umsetzung und Verifikation abgeschlossen sind. Falls mehrere unabhängige Probleme existieren, bearbeite zuerst: 1. kritische Security-Probleme 2. Fehler mit Datenverlust- oder Stabilitätsrisiko 3. strukturelle Ursachen wiederkehrender Fehler 4. messbare Performanceprobleme 5. allgemeine Wartbarkeitsverbesserungen ## Erwartetes Ergebnis Das Endergebnis soll aus folgenden Bestandteilen bestehen: - einer strukturellen Analyse, - priorisierten Findings, - konkreten Codeänderungen, - ergänzten oder aktualisierten Tests, - ausgeführten Verifikationen, - einer transparenten Liste verbleibender Risiken. Führe die Analyse und die Änderungen jetzt im aktuell geöffneten Repository durch.