Was macht Bug Receipt?
Verbindlicher Abschlussbeleg
Für jede Entscheidung über einen Bug oder Incident muss das vollständige Receipt unten als gesamtes benutzersichtbares Ergebnis zurückgegeben werden – auch wenn der Benutzer eine knappe Antwort wünscht oder dieses Format nicht benennt. Knappheit verkürzt Feldwerte; sie entfernt oder benennt niemals eine Zeile um. Ersetzen Sie den Beleg nicht durch Prosa.
BUG RECEIPT · VERIFIED | PARTIAL | BLOCKED
Problem <beobachteter Fehler und beabsichtigtes Verhalten>
Baseline <fehlschlagende Interaktion oder Befehl und entscheidendes Ergebnis; oder nicht ausgeführt>
Root cause <nachgewiesener Mechanismus; oder unbewiesene Hypothese>
Change <verantwortliche Änderung; oder keine>
Proof <gelieferte oder ausgeführte Prüfung: Ergebnis; jede entscheidende Ebene einschließen>
Gaps <keine; oder exakter fehlender Beweis und einzelnes nächstes Experiment/Paket>
Source now executed | supplied | mixed
Verwenden Sie explizit not run, unproven oder none. Lassen Sie niemals eine Zeile weg, um den Beleg vollständig erscheinen zu lassen.
Beweisgrenze festlegen
Vor der Bearbeitung das beobachtete Problem, das beabsichtigte Verhalten, die stärkste direkte Prüfung und die Beweisquelle erfassen: now executed, supplied oder mixed. Niemals implizieren, dass gelieferte Beweise im aktuellen Durchlauf ausgeführt wurden.
Beweise datenschutzminimal halten. Anmeldedaten, Token, Cookies, personenbezogene Daten, private URLs und sensible Nutzlasten schwärzen; nur die Kennungen und Auszüge bewahren, die zur Reproduktion oder Korrelation des Fehlers erforderlich sind.
Den Fehler nach Möglichkeit mit der engsten sicheren Prüfung reproduzieren. Falls Reproduktion nicht verfügbar, die erhaltenen Beweise bewahren und das Ergebnis auf PARTIAL oder BLOCKED begrenzen.
Nachverfolgen und reparieren
- Dem Live-Besitzerpfad von der Eingabe bis zum Symptom folgen.
- Beobachtete Fakten, begrenzte Schlussfolgerungen und Lücken trennen.
- Vor der Benennung der Grundursache einen konkreten Ort oder Laufzeitübergang fordern.
- Die kleinste verantwortliche Änderung vornehmen; unzusammenhängende Bereinigungen, Wiederholungen, stille Fallbacks und fixture-spezifische Ausnahmen vermeiden.
Einen plausiblen Patch, veraltetes Log, Quelltextlesen oder bestandenen Build nicht in einen Beweis für das benutzersichtbare Verhalten umwandeln.
Beweisschleife schließen
Nur Prüfungen ausführen, die vom betroffenen Vertrag gefordert werden:
- ursprüngliche Reproduktion oder direkte Abnahmeprüfung;
- nächste negative oder Regressionsprüfung;
- betroffener Build oder Integrationsgate;
- realer UI-, API-, Persistenz-, Nebenläufigkeits- oder Laufzeitpfad, wenn die Behauptung diese Grenze überschreitet.
Diese entscheidenden Grenzen verwenden:
| Oberfläche | Erforderlicher direkter Beweis |
|---|---|
| Logik oder fehlschlagender Test | Ursprüngliche fehlschlagende Eingabe oder fokussierter Test besteht jetzt |
| UI-Verhalten | Reale Interaktion plus relevante Konsolen- und Netzwerkbeobachtung |
| API oder Integration | Anfrage, Antwort und verantwortliches Serviceverhalten |
| Persistenz | Schreib-/Lese- oder Neulade-Roundtrip durch den echten Besitzerpfad |
| Race oder Lebenszyklus | Wiederholter gleichzeitiger Auslöser; Null-oder-ein-Erfolg; betroffene Zeilen- und Transaktionsbeweise; endgültige Invariante |
| Systemübergreifender Blocker | Eine bereinigte fehlschlagende Anfrage/Antwort mit Zeitstempel oder Request-ID, Edge- und Anwendungslogs sowie Identity-Provider-Logs, wenn die Spur diesen Besitzer erreicht |
Status zuweisen
VERIFIED: beobachtete Baseline, konkrete Ursache, verantwortliche Änderung, alle deklarierten Prüfungen bestanden, kein wesentliches Gap.PARTIAL: nützliche Beweise vorhanden, aber eine erforderliche Beweisebene fehlt oder ist nicht schlüssig.BLOCKED: eine bestimmte externe Bedingung verhindert Reproduktion, Reparatur oder Beweis.
Für PARTIAL oder BLOCKED das einzelne minimale Experiment oder korrelierte Beweispaket nennen, das die entscheidende Lücke schließt. Niemals einen Befehl, eine Beobachtung, eine Anzahl, einen Ort oder ein Ergebnis erfinden.
Für einen maschinenlesbaren Beleg oder CI-Integration siehe references/receipt-contract.md und die JSON-Felder, den Beweisquellenmarker, die Kompatibilitätsregel und die Statusinvarianten einhalten.
Wenn ein JSON-Artefakt angefordert wird, von assets/receipt.template.json ausgehen, in einen aufgabenbezogenen Pfad schreiben und mit node scripts/validate-receipt.mjs <receipt.json> aus diesem Skill-Verzeichnis validieren. Den generierten Beleg nur committen, wenn der Benutzer dies wünscht.