Debug-Modus
Starten Sie eine Sitzung nur, wenn der aktuelle Benutzer $debug-mode aufruft, "Debug-Modus" sagt oder instrumentiertes Debugging anfordert.
Setzen Sie fort, sobald eine aktive Debug-Sitzung besteht, auch nach Benutzerantworten oder Kontextkomprimierung.
Die Sitzung wird aktiv, wenn Schritt 3 den Server armiert.
Sie endet erst nach der Bereinigung in Schritt 8 oder nach explizitem Abbruch.
Wenn keine dieser Bedingungen zutrifft, stoppen Sie vor Analyse, Sammlung oder Instrumentierung.
Dieser Workflow baut auf dem verwandten trace-mode-Workflow auf.
Er erweitert Standortnachweise durch Korrektur, Verifikation und Bereinigung.
Die verwandten Skripte erfordern Node.js 24 oder höher.
Führen Sie diese Beweisschleife aus:
Code analysieren -> Hypothese aufstellen -> mit trace-mode tracen -> beweisen -> korrigieren -> verifizieren -> bereinigen
Arbeiten Sie autonom durch Instrumentierung. Die erste geplante Benutzerinteraktion ist der Reproduktions-Checkpoint. Reproduktion und Verifikation sind Tore.
Checkpoint-Invariante: Jeder manuelle Reproduktions- oder Verifikationsversuch erfordert einen neuen Checkpoint.
Die Toolverfügbarkeit allein bestimmt den Pfad: Wenn die native request_user_input von Codex aufgelistet ist, MÜSSEN Sie diese aufrufen;
andernfalls rufen Sie den Pi-Auswähler auf, wenn dieser aufgelistet ist; verwenden Sie die genaue Klartextvorlage nur, wenn keiner der interaktiven Pfade ausgeführt werden kann.
Der native Toolaufruf ist der Checkpoint; Kommentare oder eine endgültige Antwort können ihn nicht ersetzen.
Ein nativer Abbruch lässt das Tor offen, und ein vorheriges Ergebnis autorisiert nur seinen aktuellen Versuch.
1. Analysieren Sie den Codepfad
Beginnen Sie die Repository-Arbeit ab dem gemeldeten Symptom. Lesen Sie relevante Einstiegspunkte, Handler, Zustandsübergänge, vorhandene Logs und aktuelle Änderungen. Zeichnen Sie mögliche Pfade vom Auslöser des Benutzers zum beobachteten Ergebnis. Schreiben Sie eine Fehlerkarte:
- Symptom und erwartetes Verhalten
- Bekannter Auslöser, Route, Befehl, Eingabe oder Testdatensatz
- Möglicher Laufzeitpfad und umstrittene Grenzen
- Relevante Umgebung, Häufigkeit, Änderungen und Beweise
- Beobachtbares Akzeptanzkriterium
Zeichnen Sie nicht verfügbare Fakten als unknown auf.
Klären Sie folgenreiche Unbekannte durch Code-Lektüre oder unterscheidende Laufzeitsonden.
Abgeschlossen, wenn: ein möglicher Pfad Auslöser und Symptom verbindet und jeder umstrittene Zweig eine benannte Sondengrenze hat.
2. Bauen Sie die Hypothesenmatrix auf
Schreiben Sie zwei bis fünf geordnete Hypothesen, bevor Sie Sonden hinzufügen. Verankern Sie die Matrix in der Code-Analyse und verfügbaren Beweisen. Verwenden Sie diese Form:
H1 <kurze Ursache>
Vorhersage: <Laufzeitzustand, Pfad oder Timing>
Sonde: <Ereignisnamen und Codestellen>
BESTÄTIGT, wenn: <spezifische Datensatzbedingung>
ABGELEHNT, wenn: <spezifische Datensatzbedingung>
Eine Hypothese ohne konkrete Vorhersage erfordert weitere Code-Lektüre. Bevorzugen Sie Sonden, die mehrere Hypothesen unterscheiden.
Abgeschlossen, wenn: jede Hypothese falsifizierbare Bedingungen und eine geplante, unterscheidende Sonde hat.
3. Tracen Sie durch den Trace-Modus
Lesen Sie das verwandte trace-mode-Skill.
Verwenden Sie dessen Schritte zur Ereignisplanung, Serverstart und Instrumentierung mit der Fehlerkarte.
Lesen Sie references/probes.md für die Debug-Ereigniserweiterung.
Kehren Sie vor seinem eigenständigen Trace-Checkpoint hierher zurück.
Dieser Workflow ist der Aufrufer. Der Trace-Modus-Workflow muss aktive Sonden und die fünf Serverwerte zurückgeben.
Abgeschlossen, wenn: jede Hypothese eine aktive Sonde hat und alle fünf Serverwerte bekannt sind.
4. Durchqueren Sie das Reproduktionstor
Lesen Sie references/checkpoints.md, bevor Sie den Pre-Fix-Checkpoint präsentieren.
Führen Sie das Pre-Fix-Protokoll über den oben ausgewählten Checkpoint-Pfad aus.
Warten Sie dann und leiten Sie dessen Ergebnis über die Zustandstabelle weiter.
Jeder Wiederholungsversuch kehrt mit einem neuen interaktiven Aufruf durch dieses Tor zurück.
Abgeschlossen, wenn: ein gültiges Ergebnis A, B oder C phasengerecht weitergeleitet wurde.
5. Beweisen Sie die Ursache
Nach Pre-Fix A lesen Sie die aktuellen Sitzungsdatensätze in LOG_FILE, bevor Sie Produktcode bearbeiten.
Bestätigen Sie, dass jede erwartete Sonde vorhanden ist, inspizieren Sie dann die Datensätze in Dateireihenfolge und vergleichen Sie die relevanten Werte mit jeder Hypothesenvorhersage.
Klassifizieren Sie jede Hypothese als BESTÄTIGT, ABGELEHNT oder UNENTSCHIEDEN.
Schreiben Sie den Beweisbericht:
H1 <kurze Ursache>
Status: BESTÄTIGT
Beweis: <spezifische Ereignisse und Werte>
H2 <kurze Ursache>
Status: ABGELEHNT
Beweis: <spezifische Ereignisse und Werte>
Akzeptanz: <ein beobachtbarer Satz>
Nächste Aktion: <kleinste Korrektur für die bestätigte Ursache>
Fehlende erwartete Sonden blockieren die Bestätigung. Kehren Sie zu Schritt 2 zurück, wenn jedes Ergebnis abgelehnt oder unentschieden ist.
Abgeschlossen, wenn: aktuelle Laufzeitdatensätze eine erklärende Ursache mit einem beobachtbaren Akzeptanzkriterium bestätigen.
6. Führen Sie die evidenzgebundene Korrektur durch
Nehmen Sie die kleinste Änderung vor, die die bestätigte Ursache angeht.
Halten Sie jede Sonde aktiv.
Ändern Sie Ereignisse auf runId: "post-fix".
Fügen Sie einen fokussierten Regressionstest hinzu, wenn das Verhalten automatisierbar ist.
Abgeschlossen, wenn: jede Produktbearbeitung auf die Ursache zurückgeht und Post-Fix-Beweise bereit sind.
7. Durchqueren Sie das Verifikationstor
Präsentieren Sie den Post-Fix-Checkpoint aus references/checkpoints.md über den ausgewählten Pfad.
Warten Sie dann und leiten Sie dessen Ergebnis über die Zustandstabelle weiter.
Jeder spätere Verifikationsversuch erfordert einen weiteren interaktiven Aufruf.
Abgeschlossen, wenn: der Benutzer Post-Fix B für das genannte Akzeptanzkriterium zurückgibt.
8. Mechanische Bereinigung
Entfernen Sie jede markierte Region LOG_SERVER_PROBE <session_id>.
Suchen Sie nach der Sitzungs-ID, LOG_SERVER_PROBE und beiden Regionsformen.
Entfernen Sie kopierte Hilfsfunktionen und alle temporäre Instrumentierung.
Löschen Sie LOG_FILE, es sei denn, der Benutzer fordert die Aufbewahrung der Beweise an.
Lassen Sie den gemeinsamen Server laufen, es sei denn, der Benutzer fordert das Herunterfahren an.
Führen Sie relevante Prüfungen durch und inspizieren Sie das endgültige Diff.
Abgeschlossen, wenn: Marker- und Sitzungssuchen keine Übereinstimmungen im Repository ergeben, Prüfungen bestanden sind und nur Produktänderungen übrig sind.
Ausnahmezweig
Lesen Sie references/troubleshooting.md nur, wenn Sammlung, Reproduktion oder Lieferung fehlschlagen.