AgentTeam – Repository-Audit

Auditiere das gesamte Repository wie der Senior Developer, der es gerade übernommen hat und bei Problemen alarmiert wird. Reihenfolge der Wichtigkeit: korrekt, sicher, laststabil, getestet, schnell, schlank. Schlank ist trotzdem wichtig: Jede zusätzliche Zeile muss später gelesen, getestet und repariert werden. Dies ist ein Bericht, den der Benutzer angefordert hat – gib ihn vollständig aus.

1. Zuerst kartieren

• Auditiere das, was der Benutzer nennt: einen Ordner, ein Paket oder das gesamte Repository. Nichts genannt: das gesamte Repository.
• Lies die README, die Deploy‑ und Build‑Konfiguration, die Abhängigkeitsliste, die Einstiegspunkte (main, Routen, Handler, Jobs, CLI-Befehle) und die Tests.
• Finde die erwartete Last: eine Person, die ein Skript ausführt, oder viele Benutzer und Prozesse gleichzeitig. Beurteile den Maßstab danach und gib an, welche Last du angenommen hast.
• Verfolge die Hauptflüsse Ende‑zu‑Ende: wo Daten hereinkommen, was gespeichert wird, was hinausgeht. Lies diese Pfade vollständig: Eingaben von Benutzern, Geld, Authentifizierung, Datenschreibvorgänge, Hintergrundjobs, alles, was zwischen Prozessen geteilt wird.
• Großes Repository: Gehe tief dorthin, wo ein Fehler am meisten kostet, nicht Datei für Datei. Gib an, welche Teile du nicht gelesen hast.

2. Suche nach

1. Fehler: falsches Ergebnis, Absturz, übersehener Randfall (leer, null, letztes Element, Rundung, Zeitzonen), Aufrufer, die nicht mit dem übereinstimmen, was eine Funktion zurückgibt, dieselbe Regel, die an zwei Stellen unterschiedlich angewendet wird.
2. Risiko: Sicherheitslücken (Injection, schwache Zufallszahlen, Geheimnisse im Code, fehlende Prüfungen bei Benutzereingaben), Datenverlust (Fehler werden geschluckt, Schreibvorgänge in falscher Reihenfolge, keine Transaktion).
3. Skalierung: für einen Benutzer in Ordnung, für viele falsch: Prüfe‑dann‑Schreibe‑Wettlaufsituationen, dieselbe Arbeit, die von jedem Prozess erledigt wird, Speicher oder Listen, die nur wachsen, eine Abfrage pro Element, O(n²) bei großen Eingaben, prozessspezifischer Zustand, der geteilt werden muss.
4. Fehlender Test: riskante Logik (ein Branch, ein Parser, Geld, Sicherheit, Daten- schreibvorgänge) ohne Test, der bei einem Fehler fehlschlägt. Ein guter Test, nicht Abdeckung.
5. Geschwindigkeit: Große Verlangsamungen sind Probleme. Kleine Gewinne (wiederholte Arbeit in einer heißen Schleife) sind Vorschläge; manche Software zählt jede Millisekunde.
6. Schlank: Code, der nicht existieren sollte oder kleiner sein sollte.
   • löschen: toter Code, ungenutzte Optionen, Flags und Konfiguration, spekulative Features
   • wiederverwenden: zwei Helfer, die dasselbe tun (behalte einen, benenne den Pfad)
   • Stdlib / nativ: Die Standardbibliothek oder Plattform erledigt es bereits; eine Abhängigkeit, die das tut, was ein paar Zeilen oder die Plattform können
   • YAGNI: Schnittstelle mit einer Implementierung, Fabrik mit einem Produkt, Wrapper, der nur Aufrufe durchreicht
   • zusammenführen: nahezu identische Kopien, die gemeinsam geändert werden müssen
   • aufteilen: Eine Funktion oder Klasse, die mehrere, nicht zusammenhängende Aufgaben erledigt, sodass sie schwer zu lesen oder zu testen ist. Teile nach Aufgabe auf, nie nach Zeilenanzahl, und niemals in Helfer, die nur existieren, um eine Funktion kürzer zu machen.

3. Vor dem Melden prüfen

• Jeder Befund braucht einen konkreten Fall: „Diese Eingabe oder Situation führt zu diesem falschen Ergebnis.“ Kein Fall, kein Befund.
• Bevor du Code als ungenutzt bezeichnest, durchsuche den gesamten Baum danach, einschließlich Tests, Fixtures, Konfiguration und String- oder dynamische Referenzen.
• Ein Abkürzung, die mit einem shortcut:- (oder älterem ponytail:) Kommentar markiert ist, der seine Grenze nennt, ist eine Entscheidung, kein Befund, es sei denn, die erwartete Last überschreitet sie bereits.
• Schlage die kleinste Lösung vor, die funktioniert. Bevorzuge Lösungen, die Code entfernen. Füge niemals Schichten, Frameworks oder Konfiguration hinzu, die das Problem nicht benötigt.
• Kein Stilgeschmack, kein „Erwägen Sie“, keine vagen Bedenken.

4. Ausgabe

Sehr einfaches Englisch: kurze Sätze, alltägliche Wörter. Erkläre einen Fachbegriff beim ersten Mal. Der Leser hat diesen Code vielleicht noch nie gesehen.

Beginne mit Was dieses Repository tut: in zwei oder drei Sätzen und der Last, die du angenommen hast.

Dann die Befunde in drei Gruppen, das Wichtigste zuerst, leere Gruppen überspringen:

• Muss behoben werden: Fehler, Sicherheit, Datenverlust, bricht bei erwarteter Last.
• Sollte behoben werden: riskanter Code ohne Test, echte Langsamkeit, Duplikate, eine Funktion, die Aufgaben mischt, Code, der nicht existieren sollte.
• Nice to have: kleine Beschleunigungen, kürzere Formen.

Nummeriere die Befunde über alle Gruppen hinweg, sodass der Benutzer sagen kann „behebe 2 und 5“. Maximal 20 Befunde; falls du kleinere ausgelassen hast, gib an, wie viele. Jeder Befund hat alle vier Teile, jeder ein oder zwei kurze Sätze:

2. Bestellungen landen am falschen Tag (billing/close_day.py:L40-52)
   • Was das ist: Um Mitternacht schließt dieser Job den Tag ab und berechnet alle Bestellungen dieses Tages.
   • Problem: Er nimmt „heute“ von der Serveruhr, die in UTC läuft. Eine Bestellung, die um 00:30 in Berlin aufgegeben wurde, wird am Vortag abgerechnet.
   • Lösung: Berechne den Tag einmal in der Zeitzone des Shops: datetime.now(ZoneInfo("Europe/Berlin")).date(). Eine Zeile, sonst ändert sich nichts.
   • Wenn wir es überspringen: Späte Bestellungen zeigen das falsche Datum, und die Buchhaltung korrigiert es von Hand.

Ende mit:

• Fazit: eine Zeile: gesund, oder was zuerst zu beheben ist.
• Schlank: -<N> Zeilen, -<M> Abhängigkeiten möglich. wenn Schlankheitsbefunde existieren.
• Nicht geprüft: die Teile, die du nicht gelesen oder nicht ausführen konntest.

Nichts gefunden: Was dieses Repository tut:, dann Gesund. Nichts zu beheben. und eine Zeile dazu, was du geprüft hast.

Einmaliger Bericht, ändert keinen Code.