chimera-reproduce-before-diagnosing
Eine Diagnose ist eine Behauptung über eine Maschine, die du nicht ausgeführt hast. Reproduziere den Fehler erst mit einem kurzen Befehl — besonders dann, wenn die Diagnose von jemand anderem kam.
Verliehen von der Person, die die Karte gelesen hat — nicht von der Datei über sich selbst behauptet. Eine Karte, die der Agent während eines Laufs mit nicht vertrauenswürdigen Inhalten destilliert, kommt kontaminiert zur Welt und wird bis zur Prüfung zurückgehalten, bevor sie jemals abgerufen wird.
Wann sie in den Sinn kommt
- ein Bugreport ist eingegangen
- ein anderer Agent hat die Ursache erklärt
- der Traceback zeigt auf eine Datei
- etwas reparieren, das man nie scheitern sah
In Vermeiden und Prüfen steckt meist der Wert. Tun ist der Abschnitt, den alle schreiben.
Der Kartentext oben ist eine Übersetzung. Das englische Original ist das, was die CLI importiert, was der Agent zur Laufzeit liest und was der Hash unten bezeugt.
Auslöser
Sie sind dabei, Code zu ändern wegen eines Fehlschlags, den Sie nicht persönlich haben passieren sehen: ein roter CI-Job, ein Log-Auszug in einem Issue, die Beschreibung eines Nutzers, oder — der Fall, um den es dieser Karte wirklich geht — eine zuversichtliche Diagnose, die Ihnen ein Reviewer, ein Sub-Agent oder ein statisches Analysewerkzeug überreicht hat, samt Datei und Zeilennummer.
Das gilt nicht, wenn der Fehlschlag bereits ein Befehl ist. Ein Test, der lokal scheitert, wenn Sie ihn ausführen, ist eine Reproduktion; bauen Sie keine zweite. Es gilt auch nicht für Arbeit, in der kein Fehlschlag steckt — ein neues Feature, ein Refactoring, eine Designfrage. Die haben nichts zu reproduzieren.
Tun
- Schreiben Sie das Kürzeste, das scheitert und für sich allein ausführbar ist: ein Skript, eine pytest-Node-ID, ein CLI-Aufruf. „Die Suite ausführen und auf den dritten Fehler schauen" ist es nicht — Sie werden jedes Mal über den Fehler hinweglesen.
- Führen Sie es aus. Kopieren Sie die echte Ausgabe in Ihre Notizen: den Exception-Typ, den falschen Wert neben dem erwarteten, den Exit-Code. Nicht Ihre Zusammenfassung davon.
- Nennen Sie jetzt die Diagnose, und versuchen Sie sofort, sie zu töten. Setzen Sie ein
raise RuntimeError("here")an den Anfang der Funktion, die die Diagnose beschuldigt, und lassen Sie die Reproduktion erneut laufen. Wenn der ursprüngliche Fehlschlag unverändert erscheint, liegt diese Funktion nicht auf dem scheiternden Pfad und die Diagnose ist falsch, egal wie gut sie begründet war. - Beheben, denselben Befehl erneut ausführen, und die Reproduktion als Test in derselben Änderung behalten. Eine Repro, die nach dem Fix gelöscht wird, kann Ihnen nicht sagen, wann der Fix zurückgenommen wird.
Vermeiden
Den Frame des Tracebacks zu bearbeiten, den Sie wiedererkennen. Der Frame, den Sie wiedererkennen, ist der, den Sie schon einmal gelesen haben, nicht der, der falsch ist, und eine plausible Änderung dort verschiebt das Symptom oft nur woandershin — was sich dann als Fortschritt liest.
Vermeiden Sie es, eine Diagnose als Tatsache zu erben. Eine übergebene Erklärung ist Text, und der Prozess, der eine flüssige falsche Erklärung erzeugt, ist derselbe Prozess, der eine flüssige richtige erzeugt — die Flüssigkeit trägt also keine Information darüber, welche Sie bekommen haben. Behandeln Sie sie als Hypothese mit einem Namen daran: nützlich, um zu ordnen, was zu probieren ist, wertlos als Beleg.
# reviewer says the cache key is missing the tenant id
key = f"{tenant.id}:{user.id}"
# yes — first make the failure appear on demand
# repro.py: two tenants, same user id, assert the second read misses
Und vermeiden Sie den Reflex, bei einem sporadischen Fehlschlag bis grün neu zu starten. Neu laufen lassen diagnostiziert keine Race Condition, es versteckt eine, und es verwandelt einen einmal reproduzierbaren Bug in einen, den niemand mehr reproduzieren kann.
Prüfen
Beantworten Sie mit Ja oder Nein, bevor Sie den Fix schreiben: Kann ich diesen Fehlschlag genau jetzt mit einem Befehl erneut auslösen? Wenn nein, debuggen Sie nicht, Sie spekulieren mit offenem Editor.
Nach dem Fix: Besteht derselbe Befehl jetzt, und haben Sie ihn vorher mit eigenen Augen scheitern sehen? Ein Fix, der nur dadurch validiert ist, dass die Suite grün wird, beweist, dass die Suite grün ist — was sie aus dem falschen Grund gewesen sein kann, wenn der scheiternde Fall nie in der Suite war.
Risiko
Manche Fehlschläge sind wirklich teuer zu reproduzieren: eine Race Condition, die einmal am Tag auftritt, ein Zustand, den es nur in Produktion gibt, ein Absturz sechs Stunden in einen langen Job hinein. Dort auf einer billigen Reproduktion zu bestehen verbrennt mehr, als der Bug kostet. Setzen Sie eine Zeitgrenze, und wenn sie abläuft, sagen Sie klar, dass der Fix unverifiziert ist, statt ihn als bestätigt zu beschreiben.
Die subtilere Falle ist Über-Minimierung. Ein abgespecktes Skript kann aus einem anderen Grund zu scheitern beginnen als das Original, und dann beheben Sie das Spielzeug. Schützen Sie sich davor, indem Sie den Fix auch auf den ursprünglichen scheiternden Pfad anwenden und bestätigen, dass das ursprüngliche Symptom dort verschwindet — der minimierte Fall ist ein Werkzeug, um die Ursache zu finden, nie der Beweis, dass sie die Ursache war.
Verwenden
Die Karte ist Daten. Klonen Sie das Repository und importieren Sie sie über den Pfad — was über das Netz kommt, gilt als kontaminiert und wird bis zur Freigabe zurückgehalten. Das ist das gewünschte Verhalten und der Grund, warum es hier keinen Einzeiler-Installer gibt.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-reproduce-before-diagnosing/SKILL.mdIntegrität
SHA-256 der Datei in der veröffentlichten Fassung. Wer sie importiert, kann prüfen, dass das Empfangene dem entspricht, was diese Seite gezeigt hat.
9d70fa5a61992e3b79a2d0ab2afb592c41a7b63274efbdca0afec1724a5b8338