Fehlerbehebung

Fehler beheben

Finde die Grundursache. Behandele kein Symptom. App oder Bibliothek ändert daran nichts.

Dieser Skill lädt prove-it erst nach einer grünen Reparatur und nur, wenn der Benutzer es auswählt oder bereits um einen Beweis gebeten hat. Er überschreibt keine CopilotKit-Debug-Skills.

Wann verwenden

Laden, wenn ein Fehler vorliegt: fehlgeschlagener Test, rote CI, unerwartetes Ergebnis, Stacktrace oder der Benutzer sagt, es sei kaputt / repariere das.

Überspringe Greenfield-Features ohne Fehler. Überspringe Dokumentation und reine Typbearbeitungen.

Harte Bedingungen

1. Keine Reparatur, bis die Ursache aus Logs ermittelt ist. Kein „Versuch ein paar Dinge“.
2. Mindestens drei Hypothesen auf dem heißen Pfad, an unterschiedlichen Stellen (unsere Funktion, Aufrufer, Abhängigkeit).
3. Debug-Logs vor und nach jedem hypothetischen Pfad. Wenn eine Drittanbieter-Bibliothek auf dem Spiel einen Debug-Modus hat, schalte ihn für diese Jagd ein.
4. Wenn die Ursache ermittelt ist: Lösche jedes Log, das dieser Skill hinzugefügt hat, und schalte das Drittanbieter-Debug aus. Schreibe dann den fehlschlagenden Test. Dann reparieren. Logs dürfen nicht in die Reparatur gelangen.
5. Überspringe, lösche oder deaktiviere den fehlschlagenden Test nicht, um grün zu werden. Verschlucke den Fehler nicht (|| true, leerer catch). Erhöhe kein Timeout, um einen Wettlauf zu verstecken.
6. Repariere die Grundursache sowie dasselbe Muster in dieser Datei / dem benachbarten Modul. Kein zusätzliches Refactoring.
7. Lade prove-it nicht, es sei denn, der Benutzer wählt es aus oder hat bereits darum gebeten, diese Reparatur zu beweisen. Eine grüne Suite ist kein Beweis. Standardmäßig überspringen.

Heißer Pfad

Vom fehlschlagenden Test (oder der Benutzeraktion) den Stack hinunter bis zur Fehlerzeile, plus die Funktionen, die dort aufgerufen werden und die selbst aufgerufen werden.

Beginne dort. Eliminiere. Eingrenzen. Erweitere nur, wenn alle Hypothesen auf diesem Pfad tot sind.

Verfahren

Verfahren 1: Lesen

1. Lies den vollständigen Fehler, Stack oder CI-Log. Jede Zeile.
2. Lies den fehlschlagenden Testkörper, falls vorhanden.
3. Lies den Diff, der ihn wahrscheinlich eingeführt hat, falls vorhanden.
4. Bearbeite noch nicht.

Verfahren 2: Hypothesen

1. Kartiere den heißen Pfad (Dateien und Funktionen).
2. Schreibe mindestens drei Hypothesen: „Der Fehler wird durch X verursacht, weil Y.“ Sie müssen den heißen Pfad abdecken (nicht drei Schätzungen an einer Zeile).
3. Wenn du keine drei schreiben kannst, hast du nicht genug gelesen. Kehre zu Verfahren 1 zurück.

Verfahren 3: Instrumentieren

1. Überprüfe für jedes in einer Hypothese genannte Drittanbieter-Paket seine Dokumentation auf ein Debug-Flag oder eine Umgebungsvariable. Falls vorhanden, schalte es ein.
2. Füge temporäre Logs vor und nach jedem hypothetischen Zweig hinzu (Eingabe rein, Ausgabe raus). Verwende den vorhandenen Logger des Repos oder console. Füge kein Logging-Paket hinzu.
3. Reproduziere einmal. Lies die Logs. Streiche Hypothesen durch, die die Logs widerlegen.
4. Wenn alle drei tot sind, erweitere den heißen Pfad um einen Schritt (den nächsten Aufrufer oder die nächste Abhängigkeit). Neue Hypothesen. Neue Logs. Eliminiere erneut.
5. Wenn eine Ursache ermittelt ist: lösche alle Logs, die dieser Skill hinzugefügt hat. Schalte das Drittanbieter-Debug aus. Bestätige, dass der Arbeitsbaum keine dieser Logs mehr enthält.

Verfahren 4: Fehlschlagender Test, dann reparieren

1. Schreibe einen Test, der wegen dieses Fehlers fehlschlägt (rot). Unabhängiger erwarteter Wert. Überspringe diesen Schritt nicht.
2. Führe ihn aus. Er muss aus dem von dir genannten Grund fehlschlagen.
3. Repariere nur die Grundursache. Repariere auch Kopien desselben Fehlers in dieser Datei / dem benachbarten Modul.
4. Führe diesen Test aus (grün). Führe dann die vorhandenen Tests für dieses Paket / die Suite dieser Datei aus.
5. Wenn ein neuer Fehler auftritt, behandle ihn als neuen Fehler. Beginne bei Verfahren 1. Liefere die erste Reparatur nicht über einem neuen Bruch aus.

Verfahren 5: Optional beweisen

1. Nachdem die Suite für dieses Paket grün ist und die Logs verschwunden sind, frage einmal. Optionen: prove-it laden oder überspringen. Standardmäßig überspringen.
2. Warte. Lade prove-it nicht, bis er es auswählt.
3. Wenn er in diesem Gespräch bereits darum gebeten hat, diese Reparatur zu beweisen, überspringe die Frage. Lade prove-it.
4. Bei überspringen: sage, dass die Reparatur nicht bewiesen ist als Benutzerpfad. Behandle die grüne Suite nicht als Beweis. Verfahren 6.
5. Wenn er prove-it auswählt: lade prove-it und folge ihm. Dann Verfahren 6.
6. Klicke nicht durch die App, rufe nicht die API auf und schreibe keinen Beweisbericht innerhalb dieses Skills. Diese Arbeit gehört zu prove-it.

Verfahren 6: Stopp

Nach dem Überspringen oder nachdem prove-it zurückgekehrt ist, anhalten.

Entscheidungsbaum

• Fehler im Spiel → Verfahren 1 → 2 → 3 → 4 → 5 → 6.
• Kann nicht reproduziert werden → anhalten. Sage nicht reproduziert. Frage nach Schritten. Rate nicht bei der Reparatur.
• Logs widerlegen jede Hypothese auf dem heißen Pfad → erweitern, erneut Verfahren 2.
• Test nach der Reparatur immer noch rot → falsche Ursache. Mache die Reparatur rückgängig. Zurück zu Verfahren 2.
• Gleiches Muster in der nächsten Funktion → repariere es in derselben Änderung (Harte Bedingung 6).
• Suite grün, noch keine Beweisfrage → Verfahren 5 (fragen, Standard ist überspringen).
• Benutzer hat bereits darum gebeten, diese Reparatur zu beweisen → lade prove-it, dann Verfahren 6.

Rote Flaggen

Signal	Was es bedeutet	Stattdessen tun
Eine Hypothese, dann ein Patch	Geraten	Verfahren 2. Drei auf dem heißen Pfad.
Reparatur ohne Logs	Keine Eliminierung	Verfahren 3.
console.log im Diff immer noch vorhanden	Logs nicht gelöscht	Verfahren 3 Schritt 5. Dann der Test.
DEBUG=* von Drittanbieter noch eingeschaltet	Jagd-Flag ausgeliefert	Schalte es zusammen mit den Logs aus.
.skip / fehlschlagenden Test löschen	Symptom	Repariere den Code.
`		true` / leerer catch
Längeres Timeout	Versteckter Wettlauf	Repariere den Wettlauf.
Refactoring während der Reparatur	Vorbeifahrt	Nur Grundursache + gleiches Muster.
Testlauf im gesamten Monorepo	Ungefragt	Dieses Paket / diese Suite.
„Funktioniert auf meinem Rechner“	Andere Umgebung	Gleicher Befehl / gleiche Bedingungen wie der Fehler.
prove-it ohne Frage laden	Ungefragter Beweis	Verfahren 5. Standardmäßig überspringen.
Mini-Browser-Durchlauf innerhalb dieses Skills	Duplikat von prove-it	Lade prove-it, nachdem sie es ausgewählt haben.
„Tests bestanden, also ist es bewiesen“	Grüne Suite als Beweis behandelt	Verfahren 5. Überspringen bedeutet nicht bewiesen.

Fehlerbehandlung

• Nicht reproduziert: sage das. Liste auf, was du ausgeführt hast. Erfinde keine Reparatur.
• Kein Debug-Modus für die Abhängigkeit: überspringe diesen Schritt. Protokolliere trotzdem unseren Code auf dem heißen Pfad.
• Logs sind riesig: protokolliere nur die hypothetischen Zweige, nicht jede Zeile in der Datei.
• Fehlschlagender Test kann noch nicht geschrieben werden (kein Rahmen): ein Ein-Datei-Skript, das den Fehler behauptet, ist der Ersatz. Immer noch rot, dann reparieren, dann grün.
• Reparatur lässt einen anderen Test fehlschlagen: Verfahren 1 für diesen Fehler. Schiebe die erste Reparatur erst, wenn die Kaskade behoben ist.
• prove-it fehlt auf diesem Agenten: sage das. Biete Überspringen an. Erfinde kein zweites Beweisverfahren hier.
• Sie wählen prove-it, überspringen es dann darin: die Reparatur ist nicht bewiesen. Verfahren 6.

Dieser Skill platziert keine Helfer oder schreibt Dokumentation. Beweis ist nur Verfahren 5.