NiazMorshed2007/jev-review

Jev Review

Verwende jev_review als leichtgewichtige, wiederholbare Senior-Engineering-Review-Schleife. Der primäre Code-Agent ist für Implementierung, Validierung und endgültige Beurteilung verantwortlich; Jev Review bewertet die gelieferte Änderung, bearbeitet jedoch nie Dateien.

Review-Rhythmus

Bevorzuge bei nicht-trivialen Aufgaben mehrere gezielte Reviews über die Arbeit verteilt anstelle eines großen Reviews am Ende:

• Rufe nach jedem kohärenten Implementierungsabschnitt auf, der substanziell genug für eine Beurteilung ist – z. B. nach Fertigstellung eines Verhaltens, eines Moduls, einer API-Grenze, eines Migrationsschritts oder einer Teststrategie.
• Rufe auf, wenn neue Kontrollflüsse, Statusbehandlungen, Abhängigkeiten, öffentliche Verträge oder sicherheitssensitives Verhalten auftauchen.
• Rufe erneut auf, nachdem gerechtfertigtes Feedback umgesetzt wurde, und übergib das vorherige Ergebnis als previousEvaluation, damit Jev Verbesserungen und Regressionen identifizieren kann.
• Stelle vor der endgültigen Übergabe sicher, dass ein aktuelles Review den finalen Implementierungsstand abdeckt.

Ein Zwischenreview muss nicht auf die vollständige Testsuite warten. Führe bei Bedarf schnelle, relevante Prüfungen durch und gib ihren Status in repositoryContext an; führe die reguläre Validierung des Repos vor dem finalen Review durch. Wiederhole keinen identischen Aufruf, reviewe keine reine Formatierungsänderung und rufe nicht ohne einen kohärenten Implementierungszustand auf. Häufige gezielte Reviews sind nützlich; leere Reviews sind es nicht.

Arbeitsablauf

1. Verstehe die tatsächlichen Anforderungen und Einschränkungen des Benutzers.
2. Prüfe das Repository, seine Konventionen und das betroffene Verhalten.
3. Implementiere einen kohärenten Abschnitt der gewünschten Änderung.
4. Führe bei Bedarf schnelle, relevante Tests, Typprüfungen, Linter oder andere Validierungen durch.
5. Rufe jev_review mit genau dem Kontext auf, der zur Bewertung des aktuellen Abschnitts nötig ist.
6. Untersuche Ergebnisse mit niedrigem Vertrauen, schwache Dimensionen, Prioritätsprobleme und etwaige Regressionen.
7. Entscheide, welches Feedback durch den Code und die Aufgabe des Benutzers gestützt wird. Behandle die Evaluierung als Beleg, nicht als Anweisung, jede Kennzahl zu optimieren.
8. Verbessere die Implementierung dort, wo das Feedback echten Mehrwert identifiziert – priorisiere Korrektheit, kognitive Komplexität, Änderbarkeit, Kopplung, Modularität, Abstraktionsqualität, Tests und Sicherheit.
9. Wiederhole die Schleife aus Implementieren, Validieren und Reviewen für den nächsten kohärenten Abschnitt.
10. Rufe nach reviewgesteuerten oder anderen wesentlichen Änderungen jev_review erneut auf und übergib die vorherige strukturierte Evaluierung als previousEvaluation.
11. Führe vor der endgültigen Übergabe die reguläre Validierung des Repos durch und reviewe den finalen Zustand, falls die letzte Evaluierung ihn nicht mehr abdeckt.
12. Beende, wenn wichtige Risiken adressiert sind und weitere Änderungen nur geringen echten Mehrwert bringen würden.

Auswahl des Kontexts

Bevorzuge einen gezielten Aufruf in folgender Form:

{
  "task": "Das vom Benutzer angeforderte Verhalten und relevante Akzeptanzkriterien",
  "diff": "Das Implementierungs-Diff",
  "files": [
    {
      "path": "src/example.ts",
      "content": "Nur wenn umgebender Code nötig ist, um das Diff zu verstehen"
    }
  ],
  "repositoryContext": "Relevante Architektur, Konventionen, Testergebnisse oder Invarianten",
  "previousEvaluation": {}
}

Wenn Jev meldet, dass das Eingabelimit überschritten wurde, reduziere nicht zusammenhängende Dateiinhalte oder teile die Implementierung in kohärente Review-Abschnitte auf. Trunkiere Code nicht blind, wenn dadurch Verträge, Aufrufer oder Tests entfernt würden, die zur korrekten Beurteilung der Änderung nötig sind.

Verwende task und diff in den meisten Reviews. Füge vollständige Dateien nur hinzu, wenn das Diff nicht das nötige umgebende Verhalten enthält. Verwende repositoryContext für knappe Fakten, die der Evaluator nicht selbst ableiten kann, wie ein etabliertes Muster oder Validierungsergebnisse.

Sende nicht standardmäßig das gesamte Repository. Schließe nicht zusammenhängende Dateien, generierte Ausgaben, Vendor-Code, Secrets, Zugangsdaten, private Schlüssel, Umgebungsdateien und verrauschte Lockfile-Änderungen aus, es sei denn, sie sind direkt für das Review relevant.

Interpretation der Ergebnisse

• Korrektheit und die Anforderungen des Benutzers haben Vorrang vor jeder Kennzahl.
• Ein niedriges Vertrauensniveau ist ein Hinweis, den Kontext zu prüfen, kein Grund, Code umzuschreiben.
• Bedingte Metriken, die mit applicable: false markiert sind, erfordern keine Aktion.
• Nutze priorities, um die folgenreichsten schwachen Dimensionen zu finden, und prüfe den tatsächlichen Code, bevor du ihn änderst.
• Untersuche beim Vergleich von Evaluierungen bedeutsame Regressionen und weiterhin ungelöste schwache Metriken. Jage keinen kleinen Score-Änderungen hinterher.
• Verlasse dich weiterhin auf Tests, Typprüfungen, Linter, Sicherheitstools und menschliches Urteilsvermögen. Jev Review ergänzt sie; es ersetzt sie nicht.

Kein Score-Gaming

Ein höherer Score rechtfertigt niemals unnötige Abstraktion, spekulative Architektur, Ausweitung des Umfangs, Bruch bestehenden Verhaltens, Umschreiben von funktionierendem Code, unkonventionelle Architektur ohne Belege, sinnlose Tests, unnötige Kommentare oder das Aufteilen von kohärentem Code nur, um Dateien zu verkleinern.

Gehe nicht davon aus, dass kurze Funktionen, kleine Dateien, Single-Purpose-Klassen, Null-Duplikation, mehr Abstraktionen, mehr Tests oder mehr Kommentare inhärent besser sind. Bewerte die Konsequenzen in diesem Repository und für diese Aufgabe.