Review-Stil

Fähigkeit: Code-Stil-Prüfung (Review Style)

Zweck

Überprüfen, ob der Code allen Projekt-Stilrichtlinien entspricht. Dies ist ein Bestehen/Durchfallen-Tor, keine Feedback-Sitzung.

Wann verwenden

• TDD-Überprüfungsphase
• PR-Review auf Einhaltung des Stils
• Jegliche Code-Überprüfung, die eine Stilvalidierung erfordert

Erforderliche Eingaben

context_files

• Stilleitfaden für die zu überprüfende Phase (z. B. docs/style/rust-design.md)
• Zu überprüfende geänderte Dateien
• Ledger-Datei (optional) für mehrzyklische Überprüfungen

context_data

• phase: Welche Phase (Designer/Tester/Implementierer) – bestimmt, welche Stilregeln gelten
• changed_files: Liste der zu überprüfenden Dateien

Antwortformat

Geben Sie eine strukturierte Antwort zurück, die diesem Schema entspricht:

class StyleResult(BaseModel):
    status: Literal["accept", "violations"]
    violations: list[str] = []  # Jeder Eintrag: "datei:zeile - beschreibung"
    themes: str | None = None   # Optionales Muster über die Verstöße hinweg

Wenn alle Prüfungen bestanden sind:

StyleResult(status="accept")

Wenn eine Prüfung fehlschlägt:

StyleResult(
    status="violations",
    violations=[
        "src/config.rs:23 - snafu-Selektoren auf Modulebene importiert; sollten innerhalb einer Funktion sein",
        "src/parser.rs:45 - Fehlende Given/When/Then-Kommentare im Test",
    ],
    themes="Mehrere Verstöße resultieren aus einem inkonsistenten Fehlerbehandlungsansatz"
)

Ledger-Bewusstsein

Wenn eine Ledger-Datei in context_files bereitgestellt wird:

1. Vorherige Zyklen lesen – Überprüfen, welche Verstöße gemeldet wurden und wie der Implementierer reagiert hat
2. AUFGELÖSTE Elemente überprüfen – Bestätigen, dass Korrekturen tatsächlich angewendet wurden
3. BESTRITTENE Elemente respektieren – NICHT erneut melden, wenn der Grund des Implementierers gültig ist
4. Nur NEUE Verstöße melden – Probleme, die zuvor nicht besprochen wurden

Stilleitfäden (Autoritative Quellen)

Die Stilleitfäden in docs/style/ sind die EINZIGE Quelle der Wahrheit:

• docs/style/rust-design.md – Regeln für die Designphase (Typen, Signaturen, bon, nutype, snafu)
• docs/style/rust-impl.md – Regeln für die Implementierungsphase (Fehlerbehandlung, Importe, keine Panics)
• docs/style/rust-test.md – Regeln für die Testphase (Given/When/Then, test_case, Behauptungen)

Lesen Sie den anwendbaren Leitfaden und wenden Sie Ihr Urteilsvermögen an. Verlassen Sie sich nicht auf Zusammenfassungen.

Vorgehen

1. Anwendbare Regeln identifizieren

Basierend auf der Phase:

• designer: Regeln aus rust-design.md (insbesondere die Tabelle „Projekt-Crate-Auswahl“)
• tester: Regeln aus rust-test.md
• implementor: Regeln aus rust-impl.md
• Testdateien (#[cfg(test)]-Module) erhalten unabhängig von der Phase immer die Regeln aus rust-test.md

2. Jede Datei überprüfen

Prüfen gegen die anwendbaren Stilregeln. Nur eindeutige Verstöße melden, keine Stilpräferenzen.

Wichtige Prüfungen für die Designphase:

• Zusammengesetzte Strukturen (2+ Felder) verwenden #[derive(Builder)] mit #[non_exhaustive]
• Validierte neue Typen verwenden nutype
• Fehler verwenden snafu mit #[snafu(module)]
• Funktionsrümpfe sind todo!(), keine Implementierungen

Wichtige Prüfungen für die Implementierungsphase:

• Kein unwrap()/expect() im Produktionscode
• Snafu-Kontextselektoren innerhalb von Funktionen importieren
• Keine Leerzeilen zwischen Importen

Wichtige Prüfungen für die Testphase:

• Given/When/Then-Kommentare in jedem Test
• test_case für parametrisierte Tests

3. Strukturiertes Ergebnis zurückgeben

Verwenden Sie das StyleResult-Schema. Der Orchestrator parst dies, um die nächsten Schritte zu bestimmen.

Was diese Fähigkeit NICHT tut

• Verbesserungen vorschlagen, die nicht mit Verstößen zusammenhängen
• Allgemeines konstruktives Feedback geben
• Umfang/Korrektheit überprüfen (dafür ist review-scope zuständig)
• Stilpräferenzen melden, die nicht in den Leitfäden stehen

Dies ist ein binäres Tor: Bestanden oder Verstöße.