doFastTed/AgentDock

Code-Qualitätsprüfung

Umfassende Qualitätsprüfung für kürzlich geschriebenen Code. Kombiniert Spezifikationskonformität, schichtübergreifende Sicherheit und Pre-Commit-Prüfungen.

---

Schritt 1: Identifiziere, was sich geändert hat

git diff --name-only HEAD
git status

Schritt 2: Lies Aufgabenartefakte und anwendbare Spezifikationen

Lies die aktuellen Aufgabenartefakte in dieser Reihenfolge:

• prd.md
• design.md, falls vorhanden
• implement.md, falls vorhanden

python3 ./.trellis/scripts/get_context.py --mode packages

Lies für jedes geänderte Paket / jede Schicht den Spezifikationsindex und folge seinem Qualitätsprüfungs-Abschnitt:

cat .trellis/spec/<package>/<layer>/index.md

Lies die spezifischen referenzierten Richtliniendateien – der Index ist ein Verweis, nicht das Ziel.

Schritt 3: Projektprüfungen ausführen

Führe die Lint-, Typprüfungs- und Testbefehle des Projekts aus. Behebe alle Fehler, bevor du fortfährst.

Schritt 4: Prüfung gegen Checkliste

Code-Qualität

• Linter erfolgreich?
• Typprüfer erfolgreich (falls zutreffend)?
• Tests erfolgreich?
• Keine Debug-Logging-Ausgaben mehr vorhanden?
• Keine unterdrückten Warnungen oder Umgehungen der Typsicherheit?

Testabdeckung

• Neue Funktion > Unit-Test hinzugefügt?
• Fehlerbehebung > Regressionstest hinzugefügt?
• Geändertes Verhalten > bestehende Tests aktualisiert?

Spezifikationssynchronisation

• Muss .trellis/spec/ aktualisiert werden? (neue Muster, Konventionen, gewonnene Erkenntnisse)

"Wenn ich einen Fehler behoben oder etwas nicht Offensichtliches entdeckt habe, sollte ich es dokumentieren, damit zukünftiges Ich nicht das gleiche Problem hat?" → Wenn JA, aktualisiere das relevante Spezifikationsdokument.

Scope-Disziplin

• Wurde Code aufgeräumt, den die Aufgabe nicht erforderte?
• Wurde eine Abstraktion, Konfiguration oder ein Erweiterungspunkt für einen noch nicht existierenden Fall hinzugefügt?
• Wurde ein spekulativer Fallback für einen Zustand hinzugefügt, der nicht eintreten kann?
• Wurde eine Datei geändert, die in den Akzeptanzkriterien nicht erwähnt wird?
• Wurde ein Workaround beim Aufrufer hinzugefügt, anstatt eine Behebung dort, wo das Verhalten tatsächlich liegt?

Schritt 5: Schichtübergreifende Dimensionen (falls zutreffend)

Überspringe diesen Schritt, wenn deine Änderung auf eine einzelne Schicht beschränkt ist.

A. Datenfluss (Änderungen betreffen 3+ Schichten)

• Lese-Datenflüsse korrekt: Speicher → Dienst → API → Benutzeroberfläche
• Schreib-Datenflüsse korrekt: Benutzeroberfläche → API → Dienst → Speicher
• Typen/Schemata korrekt zwischen den Schichten übergeben?
• Fehler korrekt an den Aufrufer weitergegeben?

B. Code-Wiederverwendung (Konstanten ändern, Hilfsfunktionen erstellen)

• Nach ähnlichem existierendem Code gesucht, bevor neuer erstellt wurde?

  grep -r „pattern“ src/
  

• Wenn derselbe Wert mehrfach vorkommt, repräsentiert er ein stabiles Konzept, dessen Aufrufer gemeinsam geändert werden müssen? Nur dann extrahieren – zwei Literale, die heute zufällig gleich sind, sollten getrennt bleiben.
• Nach Batch-Änderung alle Vorkommen aktualisiert?

C. Import/Abhängigkeit (neue Dateien erstellen)

• Korrekte Importpfade (relativ vs. absolut)?
• Keine zirkulären Abhängigkeiten?

D. Schichtinterne Konsistenz

• Andere Stellen, die dasselbe Konzept verwenden, sind konsistent?

---

Schritt 6: Melden und Beheben

Melde jeden Verstoß, den du findest. Dann:

• Mechanisch und lokal (Lint-Nitpick, fehlender Typ, falscher Import, toter Zweig, fehlgeschlagene Assertion) → an Ort und Stelle beheben, dann Projektprüfungen erneut ausführen.
• Design oder Urteilsvermögen (Benennung eines gemeinsam genutzten Konzepts, Verschieben einer Modulgrenze, Ändern einer öffentlichen Schnittstelle, Neuzuweisung, wo das Verhalten lebt) → dokumentiere die Beweise und deine Empfehlung und halte an. Schreibe es nicht stillschweigend um.

Wenn eine Behebung Dateien außerhalb des aktuellen Aufgabenbereichs betreffen würde, sage dies und halte an, anstatt die Änderung auszuweiten.