yurgeno/taut-data-community

dev-review – der Prüfer (Stufe 3)

Unabhängiger Blick auf die Änderung. Prüfen Sie den DIFF gegen die AUFGABE – nicht den Diff gegen nichts.

Aufruf	dev-review <AUFGABE>
Eingabe	der Working-Tree-Diff + memory/spec/<AUFGABE>/analysis.md und implementation.md
Ausgabe	memory/spec/<AUFGABE>/review.md, status: draft, Urteil approve / needs-changes
Tor	der Eigentümer akzeptiert das Urteil – siehe Das Eigentümer-Tor unten
Weiter	needs-changes → erneut dev-implement <AUFGABE>; approve → der Eigentümer mergt sie

0. Einstiegsprüfung

• Keine <AUFGABE> angegeben → nachfragen.
• implementation.md fehlt oder ist leer → stop: es gibt noch nichts zu prüfen.
• implementation.md ist noch status: draft → dies mitteilen und trotzdem prüfen, wenn der Eigentümer darum bittet, aber im Urteil vermerken, dass Stufe 2 ihr Tor nicht passiert hatte.
• Das ANALYSE-Dokument VOR dem Diff lesen. Eine Änderung zu beurteilen, ohne zu wissen, was beabsichtigt war, erzeugt Stilkommentare und übersieht den wichtigen Befund.

Prozess (allgemein)

1. Die Absicht ableiten aus der Aufgabe und der Analyse; dann beurteilen, ob der Diff sie erreicht. Eine schöne Änderung an der falschen Stelle ist ein kritischer Befund.

2. Korrektheit zuerst: Randfälle, Fehlerpfade, Parallelität, Datenstrukturen an den Grenzen. Dann Konventionen und Klarheit. Stilistische Kleinigkeiten zuletzt und als solche markiert.

3. Vertrauen Sie nicht den Beweisen des Implementierers – reproduzieren Sie sie. Führen Sie die entscheidende Verifikation selbst durch (delegieren Sie an den dev-reviewer-Subagenten, wenn die Testsuite lang ist). Die Implementierungsnotizen sagen, was ausgeführt wurde; Ihre Aufgabe ist es zu prüfen, dass es noch gilt und dass die RICHTIGEN Dinge ausgeführt wurden.

4. Prüfen Sie die Reichweite: Was konsumiert noch den geänderten Code? Durchsuchen Sie nach Verwendungen, die der Diff nicht berührt hat; unbeabsichtigte Lockfile-/Konfigurations-/generierte-Datei-Änderungen sind Befunde.

5. Befunde, keine Korrekturen. Melden Sie nach Schweregrad (kritisch / sollte-behoben-werden / Kleinigkeit) mit Datei und Zeile; triviale mechanische Korrekturen DÜRFEN direkt angewendet werden, alles andere geht zurück an dev-implement. Schreiben Sie das Urteil in memory/spec/<AUFGABE>/review.md, beginnend mit:

   ---
   task: <AUFGABE>
   stage: review
   status: draft
   verdict: approve | needs-changes
   ---
   

Stapelspezifische Prüfungen

node: Typ-Lecks (any, as, @ts-ignore), die der Diff einführt; Promise-Ketten ohne Fehlerbehandlung; unbeabsichtigte Abhängigkeits- oder Lockfile-Abweichungen; Monorepo-Änderungen, die den Projektgraphen umgehen (tiefe relative Imports über Pakete hinweg).

jvm: Nullability an den neuen Grenzen (Kotlin-Plattformtypen, Optional-Missbrauch); Ressourcenverwaltung (try-with-resources / use); Transaktions- und DI-Scope neuer Beans; Tests, die so platziert sind, dass sie tatsächlich ausgeführt werden (richtiges Modul, richtige Namenskonvention).

android: Prüfen Sie den Lebenszyklus, nicht nur die Logik – eine Arbeit, die in einem Composable oder einer Activity gestartet wurde, muss Drehungen überleben und enden, wenn der Scope stirbt (sammeln in repeatOnLifecycle/collectAsStateWithLifecycle, Coroutinen mit dem richtigen Scope abbrechen). Ein Context, der in einem langlebigen Objekt gehalten wird, ist ein Leak. Neue Berechtigungen in AndroidManifest.xml benötigen auch den Runtime-Request-Pfad; APIs oberhalb von minSdk benötigen ein explizites Tor. Release-Builds unterscheiden sich von Debug – R8/ProGuard-Regeln für alles Reflexive (Serialisierung, Room, DI) sind Teil der Änderung. Und fragen Sie, ob die instrumentierten Tests tatsächlich AUSGEFÜHRT wurden: sie sind die, die CI am häufigsten überspringt.

php: declare(strict_types=1) und Parameter-/Rückgabetypen für neuen Code; Injektions- flächen (rohes SQL, unescapte Ausgabe) in den berührten Pfaden; Fehlerunterdrückung (@), die der Diff einführt; Konfigurations-/DI-Änderungen konsistent mit den Konventionen des Frameworks.

python: Typisierung an den neuen Grenzen (Any, fehlende Rückgabetypen, # type: ignore eingeführt durch den Diff); veränderbare Standardargumente und veränderbarer Klassenstatus; Ressourcen geschlossen (with für Dateien und Verbindungen) und async-Aufrufe tatsächlich awaited; Ausnahmebehandlung, die schluckt (except Exception: pass); Manifest und Lock gemeinsam geändert (pyproject.toml vs uv.lock / poetry.lock) oder keins; Django: eine Migration für jede Modelländerung, umkehrbar; Tests dort platziert, wo der Runner sie findet (tests/, test_*.py, conftest.py-Fixtures) und nicht durch einen veralteten Marker übersprungen.

Das Eigentümer-Tor

STOP hier – der Prüfer merged die Änderung nie und implementiert sie nie neu. Melden Sie das Urteil in zwei Sätzen mit den Befunden, die es begründen.

• needs-changes → der Eigentümer entscheidet; auf sein Wort hin geht die Schleife zurück zu dev-implement <AUFGABE>, das an implementation.md anhängt, statt neu zu beginnen. review.md bleibt als Aufzeichnung dessen, was falsch war.
• approve → nach expliziter Annahme durch den Eigentümer setzen Sie status: approved. Die Änderung mergen (Commit, Branch, Push) ist die Handlung des Eigentümers unter dem Workspace-Git-Gesetz – nicht die dieses Skills.

Erledigt, wenn

review.md sein Frontmatter und das Urteil mit Befunden nach Schweregrad trägt, die entscheidende Verifikation von IHNEN erneut ausgeführt wurde und die Zusammenfassung das Urteil in zwei Sätzen wiedergibt. Nur das genehmigen, was Sie bei einer nachträglichen Analyse eines anderen verteidigen würden.