Gedankenexperiment Version 0.6.0 alpha — Rigoroses Audit von Fehlerszenarien und Fehlerbehebungen
Auslöser: die Phrase „Gedankenexperiment“ – und nur diese Phrase. Keine impliziten Äquivalente. Wird nie ohne explizite Aufforderung und ein klares Ziel ausgeführt – dies ist bewusst gewählt, nicht autonom.
Umfang: zielagnostisch. Eine einzelne Datei, ein ganzes Projekt, eine Konfiguration, ein API-Vertrag, eine Infrastruktureinrichtung – alles, das Behauptungen aufstellt (über sein eigenes Verhalten, seine Struktur oder über etwas, von dem es abhängt), die falsch sein könnten.
Was dies von einer normalen Überprüfung unterscheidet: zwei Dinge. Erstens produziert es konkrete Szenarien – „bei dieser Eingabe/diesem Zustand passiert genau das und das und warum“ – nicht vage „das könnte sauberer sein“-Vorschläge. Zweitens sucht es gezielt nach Behauptungen des Ziels darüber, wie sich etwas außerhalb seiner selbst verhält, da diese Art von Behauptung am ehesten aus dem Gedächtnis stillschweigend falsch ist, anstatt durch das Lesen der eigenen Logik des Ziels aufgefangen zu werden.
Pre-Runde Commit-Prüfung (Sicherheitsschiene): nachdrücklich nachfragen und empfehlen, einen Commit/Push aller vorhandenen uncommitteten Änderungen durchzuführen, bevor eine Runde begonnen wird. Ein sauberer Prüfpunkt vorher bedeutet, dass die Runde selbst jederzeit darauf zurückgesetzt werden kann, falls sie Schaden anrichtet.
Ablauf
- Das Ziel frisch einlesen. Den aktuellen, realen Zustand abrufen – Dateien, Konfigurationen, alles, woraus es besteht – sich nicht auf früheren Kontext darüber verlassen, was es enthalten soll.
- Seine Abhängigkeiten auflisten. Alles, was das Ziel als Grundwahrheit außerhalb seiner selbst behandelt: bei einem Skript – importierte Bibliotheken, aufgerufene APIs, CLI-Tools und deren Flags, Umgebungs-/Konfigurationsannahmen; bei einem Dienst oder Cloud-Setup – andere Dienste, mit denen es spricht, Berechtigungen/IAM, DNS, Zertifikate, Drittanbieter-APIs, Netzwerkpfade; bei einem Dokument – jede sachliche Behauptung, die es darüber aufstellt, wie sich etwas anderes verhält. Diese Liste bewusst erstellen – Schritt 4 verifiziert sie, und eine übersprungene Abhängigkeit ist eine verpasste Chance, einen echten Fehler zu finden. Wenn das Ziel speziell für die Bereitstellung bestimmt ist, zusätzlich prüfen: Rollback-Sicherheit, Entwicklungs-/Produktionskonfigurationsparität, Geheimnisbehandlung, die angegebene Kompatibilitätsbasis und Leistung bei erstem Laden/unter realen Bedingungen im Vergleich zu reinem Entwicklungstest – diese treten nicht immer bei einem rein generischen Abhängigkeitsscan zutage. Bei gepaarter Dokumentation (eine README und ihre SKILL.md, oder Dokumentation und der von ihr beschriebene Code/die von ihr beschriebene Konfiguration) jede Behauptung einer Datei über das, was die andere sagt oder tut, als eine zu verifizierende Abhängigkeit behandeln – und separat prüfen, ob etablierte Formatierungskonventionen (fette/Schreibweise von aufgezählten Werten, Überschriftenstil) innerhalb des Ziels und über seine Geschwisterdateien hinweg konsistent angewendet werden, nur wo eine solche Konvention tatsächlich existiert, um sie zu prüfen.
- Konkrete Fehlerszenarien-Gedankenexperimente konstruieren. Spezifische Eingaben oder Zustände, die zu einer bestimmten falschen Ausgabe, einem Absturz oder einem Sicherheitsloch führen – keine allgemeinen Eindrücke. Keine Szenarioanzahl im Voraus festlegen; weiterhin Szenarien generieren, bis die tatsächliche Risikooberfläche des Ziels abgedeckt erscheint, nicht bis eine willkürliche Zahl erreicht ist.
- Jede Abhängigkeitsverhaltensbehauptung, auf die ein Szenario angewiesen ist, gegen eine Live- oder Autoritätsquelle verifizieren – echte Dokumentation, eine tatsächliche API-Antwort, die reale Ausgabe des Tools – anstatt dem Gedächtnis zu vertrauen. Dieser Schritt ist normalerweise der, bei dem die wertvollsten Erkenntnisse gefunden werden.
- Fragen, wie Korrekturen autorisiert werden sollen, einmal, bevor welche angewendet werden – CRUD-Optionen. Lesen wird immer frei gewährt, nie eingeschränkt; nur Erstellen/Aktualisieren/Löschen werden autorisiert. Pauschal (jeder bestätigte Befund, keine weiteren Nachfragen), prozessbasiert (einmal pro Runde bestätigen, nicht pro Datei darin), dateibasiert (bestätigen, bevor zu den Korrekturen der nächsten Datei übergegangen wird) oder pro CRUD-Schritt (jede einzelne Bearbeitung bestätigen) – welche der Benutzer wählt, gilt für den Rest des Laufs. Pauschal deckt routinemäßige bestätigte Befunde ab, keine bedingungslose Überschreibung: ein wirklich überraschender oder risikoreicherer Befund als das, was der Benutzer bei der Gewährung im Sinn hatte, wird trotzdem pausiert und nachgefragt.
- Korrekturen anwenden für bestätigte Befunde, in der autorisierten Granularität.
- Diesen gleichen Prozess erneut gegen den korrigierten Zustand durchführen. Eine Korrektur kann ihr eigenes neues Problem einführen – eine Genauigkeitskorrektur, die etwas anderes inkonsistent macht, eine korrigierte Behauptung, die eine andere Annahme an anderer Stelle bricht. Die Schleife ist nicht beendet, bis ein Durchlauf nichts Neues ergibt.
- Bericht. Jedes Szenario als bestanden/fehlgeschlagen klar angeben. Nur für bestätigte Fehlschläge oder wenn explizit nach Details gefragt wird, vollständige Details liefern – ein sauberer Durchlauf braucht keinen Aufsatz darüber. Jeden Fehlschlag als blockierend (muss vor der Bereitstellung/Auslieferung behoben werden) oder nicht blockierend (sicher auszuliefern, später beheben) kennzeichnen, sodass der Bericht als Go/No-Go-Eingabe dient, nicht nur als eine Liste von Befunden. Jeden Durchlauf mit einer konsolidierten nummerierten Zusammenfassung abschließen, nicht nur mit szenariobasierten Erwähnungen, die über den Prozess verstreut sind – skaliert auf den Umfang: ein Multi-Ziel-Lauf (mehrere Dateien, mehrere Skills) erhält einen Abschnitt pro Ziel; ein einzelnes sauberes Ziel erhält eine einfache Urteilszeile, kein aufgeblähtes Zeremoniell.
Neue Zeile, jeden Bericht mit gedankenexperiment abschließen.