Überprüfe den letzten verfügbaren Plan, behalte das ursprüngliche Ziel, den Umfang und das vernünftige Design bei, ohne die Anforderungsanalyse zu wiederholen. Prüfe zuerst das Projekt und die Dokumentation, frage nicht erneut nach bereits bekannten Antworten; wenn kein ursprünglicher Plan vorhanden ist, fordere ihn an.
1. Grill: Implizite Entscheidungen (Pflicht)
Finde Entscheidungen, die der Plan stillschweigend für den Benutzer getroffen oder ausgelassen hat und die schwerwiegende Konsequenzen haben. Prüfe entlang des Benutzerflusses Standardwerte, Fehler-/Abbruch-/Wiederholungsfälle, Statuswiederherstellung, modulübergreifende Verträge, Kompatibilitätsmigration und Berechtigungsgrenzen. Verwende konkrete Gegenbeispiele, um Annahmen zu hinterfragen, und arbeite keine Checkliste mechanisch ab.
Frage nur nach echten Kompromissen, die die Erfahrung, Architektur, Daten, Sicherheit oder Kosten signifikant verändern; überprüfbare Fakten und kostengünstig reversible Details kläre selbst. Beschreibe bei jeder Frage die Annahme/Lücke, die Konsequenz und einen Vorschlag. Ermögliche mehrere Runden mit vielen Fragen pro Runde, nummeriere sie thematisch und frage zuerst nach vorgelagerten Entscheidungen; warte auf Antwort, um abzuschließen, Stille gilt nicht als Zustimmung.
2. Oracle: Objektive Abnahme (Optional)
Aktiviere nur, wenn glaubwürdige und kosteneffiziente objektive Kriterien existieren; der Benutzer kann sie überspringen. Halte für kritische Anforderungen die Quelle des Kriteriums, die Prüfmethode und die Bestehensbedingung fest; bevorzuge Spezifikationen, Referenzimplementierungen, vom Benutzer bestätigte Beispiele und Invarianten. Liste für Optimierungsaufgaben separate Basislinien, Metriken und Einschränkungen auf, die nicht unterschritten werden dürfen. Täusche keine Wahrheit durch Modell-Selbsteinschätzung oder Agentenmetriken vor; Teile, die nicht automatisch verifiziert werden können, behalte der manuellen Abnahme vor.
3. Prototype: Subjektiver Vergleich (Optional)
Aktiviere nur, wenn das Erscheinungsbild oder die Interaktionserfahrung die Lösung beeinflusst und Text allein nicht ausreicht, um eine Entscheidung zu treffen; der Benutzer kann sie überspringen. Nutze Referenzen oder minimal unterschiedliche Prototypen mit wesentlichem Unterschied, damit der Benutzer vergleichen und wählen kann, anstatt weiter nach abstrakten Präferenzen zu fragen. Erstelle isolierte Prototypen nur, wenn der aktuelle Modus dies erlaubt und der Benutzer autorisiert hat; andernfalls schreibe „Prototypenvergleich → Benutzerauswahl → entsprechende Implementierung” in die zweite Version und behalte die entsprechenden unerledigten Punkte. Behaupte keine Validierung, ohne sie gezeigt oder verglichen zu haben.
Konvergenz
Konvergiere, nachdem wichtige Entscheidungen bestätigt, explizit delegiert oder aufgeschoben wurden; konvergiere auch, wenn der Benutzer das Ende verlangt. Gib einen eigenständigen, vollständigen zweiten Plan aus, der die getroffenen Entscheidungen, Implementierungsschritte und geltenden Abnahme-/Prototypen-Schwellen integriert, zusammen mit einer kurzen Änderungsliste und verbleibenden Annahmen; vermerke bei aufgeschobenen Punkten, wann sie entschieden werden und was sie blockieren. Gib nicht nur einen Fragebogen oder Patches aus, behaupte nicht, alle Risiken ausgeschöpft zu haben. Stoppe nach der Ausgabe, implementiere oder starte keine Überprüfung von selbst.