Conceptual Review (Konzeptionelle Überprüfung)

Konzeptionelle Überprüfung

Entscheiden, ob eine Argumentation oder ein Implementierungslastenheft Bestand hat, bevor jemand darauf aufbaut. Bleiben Sie schreibgeschützt, es sei denn, der Benutzer fordert separat Bearbeitungen an.

Beginnen Sie mit Beweisen

• Beschaffen Sie zuerst günstige Beweise: Repository-Zustand, Tests, Compiler- oder Typprüfungsausgaben, Dokumentation, Logs, Benchmarks, Konfiguration und Laufzeitverhalten. Die Argumentation beginnt dort, wo die Beweise enden; argumentieren Sie niemals anstatt zu suchen.
• Beachten Sie die angeforderte Revision, den Branch, den Umfang und die Lesebegrenzungen. Wenn ein Lastenheft an einen Commit gebunden ist, lesen Sie diesen Commit, nicht den Arbeitsbaum.
• Behandeln Sie jedes Zitat, jede Zahl, jede Repository-Behauptung und jeden zitierten Präzedenzfall als etwas, das zu überprüfen ist.
• Kennzeichnen Sie jede wesentliche Prämisse als beobachtet, gefolgert, angenommen oder unbekannt. Eine nicht verfügbare Quelle ist eine Abdeckungslücke, keine Bestätigung.

Wählen Sie den Modus

• Argumentationsmodus für eine Entscheidung, Behauptung oder Schlussfolgerung.
• Spezifikationsmodus für einen Implementierungsvertrag, einen Plan oder ein Kurzdossier, dem ein Implementierer folgen wird.

Verwenden Sie beide, wenn eine Spezifikation auf einer bestrittenen Behauptung beruht.

Argumentationsmodus

1. Nennen Sie die Entscheidung oder Behauptung.
2. Listen Sie die Prämissen auf, von denen sie abhängt, gekennzeichnet wie oben.
3. Überprüfen Sie, ob die Beweise die Schlussfolgerung stützen, ohne übersprungene Schritte, zirkuläre Unterstützung oder mehr Sicherheit, als die Prämissen zulassen.
4. Suchen Sie nach Prämissen, die nicht alle wahr sein können.
5. Nennen Sie das schwächste wichtige Glied.
6. Nennen Sie das stärkste glaubwürdige Gegenargument oder die stärkste konkurrierende Erklärung. Keine Strohmänner.
7. Fragen Sie, ob eine andere Entscheidung die Schlüsselunsicherheit besser behandelt, einschließlich der Umkehrbarkeit, wenn dies relevant ist.
8. Empfehlen Sie die kleinste Korrektur: beibehalten, ändern, eine benannte Unbekannte untersuchen oder wechseln.

Spezifikationsmodus

Überprüfen Sie, was die Implementierung oder deren Abnahme falsch machen könnte:

1. Ergebnis: Verhalten, Ausnahmen und Voraussetzungen stimmen miteinander überein.
2. Quellen: Zitate, Bereiche, Protokollregeln, Formeln und externe Fakten stimmen mit ihren Primärquellen überein.
3. Arithmetik: Anzahlen, Grenzen, Matrizen und Summen ergeben bei Neuberechnung exakt das Gleiche.
4. Abdeckung: Jeder betroffene Aufrufer, Test, jede Schnittstelle, Invariante, Kompatibilitätszusage und jeder Dokumentsatz wird berücksichtigt. Führen Sie eine begrenzte Suche über die vom Lastenheft genannten Pfade hinaus durch, ohne in eine unzusammenhängende Architekturüberprüfung abzudriften.
5. Abnahmekraft: Jeder erforderliche Test kann für den Fehler, den er abdeckt, fehlschlagen. Kontrollen sind aussagekräftig, und negative Fälle haben beobachtbare Fehlschläge.
6. Ausführungsklarheit: Dateiumfang, Reihenfolge, Rand- und Fehlerverhalten sowie Fertigstellungsnachweis lassen nichts Wesentliches dem Raten überlassen.
7. Umfang: Präzedenzfälle und zukünftige Arbeiten rechtfertigen nicht stillschweigend mehr, als die vorliegenden Beweise erfordern.

Bewerten Sie die Ergebnisse mit den Schweregradbegriffen des Repositorys, oder:

• BLOCKING: kann eine falsche Implementierung, einen falschen Bestehenstest oder unvermeidbares Rätselraten verursachen.
• AMEND: eine konkrete Lücke oder Unklarheit; der Ansatz bleibt bestehen.
• NIT: eine Formulierungs- oder Beweiskorrektur, die die Implementierung nicht ändert.

Ausgabe

• Beginnen Sie mit dem Urteil. Argumentationsmodus: Die Argumentation hält stand, oder was sie bricht. Spezifikationsmodus: Bereit oder Nicht bereit, mit dem entscheidenden Grund.
• Der Argumentationsmodus gibt dann nur das Wesentliche: Schlüsselannahmen, schwächstes Glied, bestes Gegenargument und Empfehlung.
• Der Spezifikationsmodus gibt dann nummerierte Ergebnisse in Prioritätsreihenfolge (Titel, Schweregrad, genauer Beleg, warum es wichtig ist, konkrete Korrektur) und eine kurze Verifiziert-Liste wichtiger Behauptungen, die Bestand hatten.
• Beenden Sie mit Konfidenz (hoch, mittel oder niedrig), dem Beweis, der das Urteil am ehesten ändern würde, sowie etwaigen Abdeckungslücken oder nicht verifizierten Quellen.

Regeln

• Bringen Sie nur Punkte vor, die die Entscheidung ändern könnten. Ein sauberes Urteil ist gültig; erfinden Sie niemals Ergebnisse.
• Erfinden Sie keine Wahrscheinlichkeiten oder Bewertungen, die die Beweise nicht stützen können.
• Fragen Sie den Benutzer nur, wenn eine fehlende Entscheidung oder Anforderung die Überprüfung blockiert. Beschaffen Sie verfügbare Fakten selbst.
• Diese Überprüfung autorisiert keine Implementierung, Bearbeitungen oder andere folgenreiche Aktionen.
• Für Schnittstellen- und Nahtstellendesign empfehlen Sie $codebase-design, anstatt dessen Methode zu wiederholen.

Grundlage: Anthropic and Redwood Research's Conceptual Reasoning Index work, angepasst als Entwickler-Workflow. Dieser Skill implementiert CRI oder seine Benchmarks nicht.