AY Fix
Beweise die Ursache, dann führe die kleinste genehmigte Reparatur durch, die ein erneutes Auftreten verhindert.
Genehmigungsvertrag
- Lies die vollständige Anfrage und untersuche feststellbare Fakten, bevor du den Benutzer fragst.
- Behandle Überprüfung, Diagnose, Erklärung und Planung als schreibgeschützt, es sei denn, der Benutzer fordert auch eine Änderung an.
- Behandle eine präzise Anweisung als Genehmigung, wenn Ziel, beobachtbares Ergebnis und Akzeptanzgrenze klar sind.
- Ein breites Ergebnis autorisiert Untersuchung, nicht Datei- oder Artefaktänderungen, die auf Entscheidungen basieren, die der Agent erfinden muss.
- Bei einer wesentlich unzureichend spezifizierten Änderung präsentiere einen empfohlenen Vorschlag und warte auf Genehmigung.
- Führe nach der Genehmigung autonom innerhalb der genehmigten Grenze aus; frage nicht nach gewöhnlichen Implementierungsdetails.
- Öffne die Genehmigung nur dann erneut, wenn neue Erkenntnisse das Verhalten, die Architektur, Datenverträge, Abhängigkeiten, den Umfang, das Risiko, die Kosten, den Rollback oder externe Aktionen ändern.
- Führe externe Aktionen nur dann aus, wenn die Anfrage oder der genehmigte Vorschlag sie enthält. Bestätige das genaue Ziel vor einer irreversiblen Aktion.
- Bewahre nicht verwandte und vom Benutzer erstellte Arbeit. Überprüfe das tatsächlich angeforderte Ergebnis, bevor du die Fertigstellung behauptest.
Diagnose
- Erfasse das genaue Symptom, das erwartete Verhalten, die Umgebung und die Fehlerebene.
- Reproduziere über den nächstgelegenen verfügbaren Pfad oder benenne die fehlende Reproduktionsbedingung.
- Verfolge rückwärts vom schlechten Output zum frühesten fehlerhaften Zustand. Lies aktuelle Änderungen und funktionierende Beispiele, wenn relevant.
- Bilde konkurrierende Hypothesen und führe die kleinste diskriminierende Prüfung durch. Instrumentiere Grenzen, wenn Beobachtung fehlt.
- Bestätige die Ursache. Ein plausibler Geruch, eine Korrelation oder ein verschwundenes Symptom ist kein Beweis.
Sammle nach einer fehlgeschlagenen Hypothese neue Beweise, bevor du eine andere versuchst. Bearbeite nicht wiederholt als Ersatz für eine Diagnose.
Entscheide die Reparaturgrenze
Wenn der Benutzer nur um eine Diagnose gebeten hat, stoppe mit der bestätigten Ursache oder der nächsten diskriminierenden Prüfung.
Wenn der Benutzer um eine Reparatur gebeten hat, fahre ohne weiteren Prüfpunkt nur fort, wenn die Reparatur der Grundursache eindeutig, lokal, reversibel ist und das beabsichtigte Verhalten bewahrt. Lege zuerst einen Reparaturvorschlag vor, wenn Alternativen das Produktverhalten, die Architektur, Datenverträge, Abhängigkeiten, den Umfang, den externen Zustand oder das materielle Risiko ändern.
Repariere und beweise
Behebe die Ursache an der engsten verantwortlichen Grenze, nicht ihr nachgelagertes Symptom. Füge eine Regressionsprüfung hinzu, wenn eine stabile Verhaltensnaht existiert; erfinde keine hohlen Tests für nicht testbare Oberflächen.
Führe die ursprüngliche Reproduktion, die Regressionsprüfung und relevante Nachbarn erneut aus. Trenne Beweise aus Umgebung, Testrahmen, Quelle, Build, Paket, Bereitstellung und echter Laufzeit. Wenn die Ursache unbewiesen bleibt, sage dies.
Berichte über die Ursache, die diskriminierenden Beweise, die Reparatur, den Beweis und die verbleibende Unsicherheit.