review-scope

Skill zur Umfangsprüfung

Zweck

Überprüfen, dass Codeänderungen genau das tun, was sie tun sollen – nicht mehr und nicht weniger. Dies ist ein Prüfgatter (Bestanden/Durchgefallen), keine Feedback-Sitzung.

Wann verwenden

• TDD-Verifikationsphase
• PR-Review zur Einhaltung des Umfangs
• Jede Code-Review, die eine Umfangsvalidierung erfordert

Erforderliche Eingaben

Kontextdateien

• Implementierungsplan oder Anforderungsdokument
• Entwurfsdokument (falls vorhanden)
• Geänderte Dateien zur Überprüfung

Kontextdaten

• commit_details: Was diese Änderung bewirken soll
• requirements: Liste der adressierten REQ-*
• constraints: Liste der CC-*-Einschränkungen, die erfüllt sein müssen
• allowed_files: Dateien, die geändert werden dürfen (Umfangsgrenze)

Vorgehen

1. Umfangsgrenzen festlegen

Aus den Eingaben ermitteln:

• Was MUSS getan werden (Anforderungen)
• Was DARF NICHT getan werden (Einschränkungen)
• Welche Dateien DÜRFEN geändert werden
• Welches Verhalten wird erwartet

2. Änderungen überprüfen

Für jede geänderte Datei:

1. Ist diese Datei in der erlaubten Menge?
2. Adressieren die Änderungen die genannten Anforderungen?
3. Gibt es Änderungen, die nichts mit den Anforderungen zu tun haben?
4. Verstoßen die Änderungen gegen Einschränkungen?

3. Ergebnis melden

Wenn alle Prüfungen bestanden sind:

ACCEPT

Wenn eine Prüfung fehlschlägt, Verstöße auflisten:

VIOLATIONS:
- <datei>:<zeile> - <Beschreibung in eigenen Worten>
- <datei> - <Beschreibung>

[Optional] THEMES: <erwähnenswertes Muster>

Format der Verstöße

Verstöße natürlich beschreiben mit Ort und klarer Erklärung:

- src/parser.rs:45 - Protokollierungsinfrastruktur hinzugefügt, die nicht im Commit-Umfang liegt
- src/config.rs - Datei außerhalb des erlaubten Satzes geändert

Wenn Muster über mehrere Verstöße hinweg auffallen, diese benennen:

THEMES: Mehrere Änderungen gehen über die genannten Anforderungen hinaus in die Refaktorisierung der Fehlerbehandlung

Prüfung auf minimale Änderungstendenz

Der implementierende Agent neigt dazu, die kleinstmögliche Änderung vorzunehmen, um sein Ziel zu erreichen. Nachdem Verstöße identifiziert wurden, abwägen:

Deuten die Verstöße auf eine potenzielle Refaktorisierung hin, die den Code wartbarer machen würde? Hat der Implementierer eine bessere strukturelle Lösung zugunsten einer schnellen Lösung vermieden?

Wenn ja, dies in einem REFACTORING-Abschnitt vermerken:

REFACTORING: <Beschreibung der strukturellen Verbesserung, die der Implementierer vermieden hat>

Dies ist kein Verstoß – es ist ein Hinweis für den Orchestrator.

Was diese Skill NICHT tut

• Verbesserungen vorschlagen, die nichts mit Verstößen zu tun haben
• Allgemeines konstruktives Feedback geben
• Codestil überprüfen (dafür die Skill review-style verwenden)

Dies ist ein binäres Gatter: ACCEPT oder VIOLATIONS. Refaktorisierungsnotizen sind optionale Hinweise, keine Blockaden.