---
name: aenderung-pruefen
description: Prüft einen Diff oder abgeschlossenen Arbeitsschritt gegen Task, Akzeptanzkriterien, Projektrichtlinien, Tests sowie Sicherheits- und Datenschutzrisiken. Verwenden, bevor eine Änderung als fertig erklärt oder committed wird, und wenn ein Branch, Commit, Diff, Bericht oder anderes Arbeitsergebnis reviewed werden soll.
---

# Änderung prüfen

Prüfe das tatsächliche Ergebnis gegen seinen Auftrag. Tests und Formatierer sind
wichtige Nachweise, ersetzen aber kein Review von Zweck, Risiken und Klarheit.

## Fachliche Grundlage

Der [Google Code Review Guide](https://google.github.io/eng-practices/review/)
nennt Funktion, Design, Komplexität, Tests, Benennung und Dokumentation als
Review-Gegenstände und empfiehlt kontinuierliche Verbesserung statt Perfektion.

## Ablauf

1. Bestimme den festen Ausgangspunkt und den zu prüfenden Diff oder das konkrete
   Textartefakt. Prüfe keine unbekannte oder leere Änderungsmenge.
2. Lies Task, Akzeptanzkriterien, relevante ADRs, `PROJECT_GUIDE.md`,
   `docs/domain/DOMAIN.md` und die vereinbarte Prüfstrategie.
3. Prüfe getrennt:
   - **Auftrag:** Ist das geforderte Ergebnis vollständig und ohne unnötige
     Erweiterung umgesetzt?
   - **Korrektheit:** Stimmen Verhalten, Grenzfälle, Fehlerbehandlung und Daten?
   - **Sicherheit und Datenschutz:** Entstehen neue Datenflüsse,
     Berechtigungsprobleme, Offenlegungen oder unsichere Voreinstellungen?
   - **Nachweise:** Würden die Tests oder redaktionellen Prüfungen bei einem
     echten Fehler anschlagen?
   - **Gestaltung:** Ist die Lösung verständlich, lokal änderbar und frei von
     unbegründeter Komplexität?
   - **Dokumentation:** Sind Typ, Reifegrad, Arbeitsstatus, Blockierung und
     Beziehungen in Backlog, Plan, Task, Domänenmodell, ADRs und Nutzertexten
     konsistent?
   - **Nachvollziehbarkeit:** Erklärt das Task-Ergebnis allgemeinverständlich,
     was erreicht wurde, und verweist ein vorgesehener Commit mit dem
     `Task:`-Trailer auf genau diese Datei?
4. Berichte nur konkrete, durch Diff und Anforderung belegte Funde. Nenne Datei
   und möglichst eine enge Stelle sowie die Auswirkung.
5. Ordne jeden Fund ein:
   - **blockierend:** falsches Ergebnis, wesentliches Sicherheits- oder
     Datenschutzrisiko, fehlendes Akzeptanzkriterium;
   - **wichtig:** wahrscheinlicher Fehler oder deutliche Wartungsbelastung;
   - **optional:** begründete Verbesserung ohne Abschlussrisiko.
6. Ignoriere reine Geschmacksfragen und Dinge, die vorhandene Werkzeuge bereits
   zuverlässig erzwingen.
7. Wenn nur ein Review verlangt wurde, verändere nichts. Im Rahmen einer
   beauftragten Umsetzung behebe in-scope Funde, führe die relevanten Prüfungen
   erneut aus und wiederhole das Review.

## Übergabe am Ende der Arbeitswelle

Nach erfolgreicher Prüfung eines Tasks:

1. Setze Task und Backlog-Eintrag auf `pruefung` und berichte Ergebnis,
   Prüfergebnis und bekannte Einschränkungen. Verwende `erledigt` erst für ein
   akzeptiertes Ergebnis und halte Register, Task und Plan dabei konsistent.
2. Zeige unter der gut sichtbaren Überschrift `Commit und Push ausstehend` den
   vorgesehenen Betreff, den vollständigen `Task:`-Trailer und den genauen
   Änderungsumfang.
3. Frage, ob genau dieser geprüfte Stand committed und gepusht werden darf.
4. Schlage gleichzeitig genau einen nächsten kleinen Task mit Ziel,
   Nicht-Zielen und Prüfkriterien vor.
5. Beginne den nächsten Task erst nach Zustimmung, erfolgreichem Commit und
   Push sowie bestätigtem Remote-Gleichstand. Ein ausdrückliches `ok` ohne
   Einschränkung bestätigt den unmittelbar zuvor vollständig ausgewiesenen
   Commit/Push und den vorgeschlagenen nächsten Task.
6. Prüfe nach dem Commit die gespeicherte Nachricht, pushe den Commit, prüfe den
   Gleichstand des lokalen Branchs mit seinem Upstream und melde den Hash.
7. Bei Ablehnung weder committen noch pushen. Kläre, ob die Anmerkung noch in
   denselben Task gehört oder ein neuer Task nötig ist. Bei einem neuen Task
   frage zusätzlich, ob der bisherige geprüfte Stand separat committed und
   gepusht werden darf.

Ein ausgelassener oder fehlgeschlagener Commit beziehungsweise Push blockiert
die Arbeitswelle. Verwende `Kein Commit erstellt` nicht als unauffälligen
normalen Abschluss. Weise den ausstehenden Zustand sichtbar aus und beginne
keinen nächsten Task. Widerspricht eine spätere Bitte um gesammelt geprüfte
Commits der geltenden Commit-pro-Task-Regel, benenne den Konflikt und verlange
eine ausdrückliche Ausnahme, statt einen Aufschub zu unterstellen.

## Übergabe zum Commit

Führe diese Schritte nur aus, wenn der Benutzer einen Commit verlangt:

1. Bestimme genau einen primären Task für den überprüfbaren Arbeitsschritt.
   Fehlt ein geeigneter Task, stoppe und frage, ob einer angelegt werden soll.
2. Schliesse im Task Status, Prüfergebnis, Ergebnis, bekannte Einschränkungen
   und nächsten Schritt ab. Erfinde keine erfolgreiche Prüfung.
3. Zeige dem Benutzer vor dem Commit:
   - einen kurzen Betreff, der die erreichte Wirkung beschreibt;
   - den vollständigen Trailer nach den Projektregeln, zum Beispiel
     `Task: docs/tasks/TASK-NNNNN-kurzer-titel.md`;
   - die Dateien oder Änderungsmenge, die committed werden sollen.
4. Committe erst nach ausdrücklicher Freigabe, prüfe danach die tatsächlich
   gespeicherte Commit-Nachricht, pushe und bestätige den Remote-Gleichstand.
   Melde den Commit-Hash in der Übergabe. Schreibe ihn nicht in denselben Task
   zurück; der Trailer in Git ist die führende Zuordnung.

Nutze für eine unabhängige Gegenprüfung einen frischen Agenten, wenn dies ohne
zusätzliche Risiken oder externe Änderungen möglich ist. Ein Review ohne Funde
darf ausdrücklich `keine Funde` melden.

## Fertig, wenn

- Änderungsmenge und Anforderungsquelle eindeutig sind.
- jeder Fund belegbar, priorisiert und handlungsrelevant ist.
- Auftragstreue und technische Qualität getrennt betrachtet wurden.
- Sicherheits- und Datenschutzfolgen bereits im Design und erneut im Diff
  geprüft wurden.
- der abgeschlossene Arbeitsschritt über Task und Commit nachvollziehbar ist.
- eine verlangte Commit-Nachricht vorab freigegeben und danach geprüft wurde;
- Commit und Push erfolgreich sind und der lokale Branch seinem Upstream
  entspricht, bevor der nächste Task beginnt.