Belege
Jeder kann behaupten, ein Bug sei behoben. Diese Seite zeigt den Fix, den Test, der ihn absichert, und den Nachweis, dass der Test fehlschlägt, wenn der Bug zurückkehrt.
Generiert am 2026-10-03 aus tools/prove_regressions.py · 4 von 4 Regressionstests als nicht vakuös nachgewiesen.
Wie jeder Nachweis entsteht
- Führen Sie den Regressionstest gegen den behobenen Code aus: Er muss bestehen.
- Bearbeiten Sie den Quellcode, um den ursprünglichen Bug wieder einzubauen.
- Führen Sie denselben Test erneut aus: Er muss fehlschlagen, mit einem echten Assertion-Fehler. Ein Collection-Fehler zählt nicht: Er bedeutet, dass der Test nie gelaufen ist.
- Stellen Sie die Datei wieder her, prüfen Sie, ob ihr SHA-256 mit dem Original übereinstimmt, und führen Sie den Test erneut aus: Er muss wieder bestehen.
Der Assistent sagte Besuchern, der Webhook übertrage ihre Unterhaltung. Er überträgt nichts davon.
Commit e027e6b · abgesichert durch apps/gateway/tests/test_webhook_content_claim.py
Webhook-Payloads enthalten bewusst nur die FORM eines Turns (Eventname, Zeitstempel, Schrittzahl, Credits) und niemals dessen Inhalt. Auf die Frage, ob Webhooks das Gespräch enthalten, antwortete der Assistent: 'Ja, jede Webhook-Payload enthält den vollständigen Gesprächsverlauf für diesen Turn.' Das ist das genaue Gegenteil der Garantie, gegen die die Allow-List getestet wird. Vor dem Fix gemessen: 2 Erfindungen in 6 Läufen.
| Korrigierter Code, Testläufe |
BESTANDEN |
21 passed in 1.15s |
| Bug wieder eingebaut, derselbe Test |
ABGEFANGEN |
8 failed, 13 passed in 1.20s |
| Datei wiederhergestellt, Test läuft |
BESTANDEN |
sha256 a8d4cb0b10787eff… |
Der Test ist nicht trivial erfüllt: Er schlägt fehl, wenn der Bug zurückkehrt.
Wir haben Inhabern gesagt, sie sollen auf eine Dashboard-Karte klicken, die es nicht gibt.
Commit b4a203a · abgesichert durch apps/gateway/tests/test_card_names.py
Die Wissensdatenbank, die Doku und eine Starter-Kachel wiesen Inhaber alle an, eine Karte namens „Send turns to a webhook“ zu suchen. Die echte Dashboard-Karte heißt „Send events to your own system“. Der Name wurde beim Schreiben des Wissensbereichs erfunden und ungeprüft an drei Stellen übernommen. Gemessen: 2 von 2 Einrichtungsantworten nannten ein Bedienelement, das es nie gegeben hat.
| Korrigierter Code, Testläufe |
BESTANDEN |
5 passed in 1.12s |
| Bug wieder eingebaut, derselbe Test |
ABGEFANGEN |
3 failed, 2 passed in 1.23s |
| Datei wiederhergestellt, Test läuft |
BESTANDEN |
sha256 f6348e1a5bbae209… |
Der Test ist nicht trivial erfüllt: Er schlägt fehl, wenn der Bug zurückkehrt.
Die Begrüßung im Dark Mode wurde mit 1.73:1 dargestellt, war damit praktisch unsichtbar, und die Prüfung hätte das nicht erkennen können.
Commit ca47f41 · abgesichert durch apps/studio/test/themeContrast.test.mjs
Gefunden anhand eines Screenshots von einem echten iPhone, nicht durch einen Test. Die Begrüßung war fest auf #3a3a3c codiert, was gegenüber dem Dark-Mode-Panel bei 1.73:1 liegt - weit unter dem Minimum von 4.5:1 und kaum lesbar. Jeder Erstbesucher im Dark Mode sah sie. Der Fix leitet die Farbe über die Theme-Variable --pw-mist, sodass sie dem Panel folgt; der Guard berechnet jetzt für jedes Theme-Paar das tatsächliche Kontrastverhältnis, statt darauf zu vertrauen, dass eine Farbe gesetzt wurde.
| Korrigierter Code, Testläufe |
BESTANDEN |
pass 5, fail 0 |
| Bug wieder eingebaut, derselbe Test |
ABGEFANGEN |
pass 3, fail 2 |
| Datei wiederhergestellt, Test läuft |
BESTANDEN |
sha256 54f8802b444b6194… |
Der Test ist nicht trivial erfüllt: Er schlägt fehl, wenn der Bug zurückkehrt.
Ein fehlgeschlagener Turn ließ den Besucher endlos an einem toten Stream warten.
Commit 4bcc691 · abgesichert durch apps/studio/test/streamError.test.mjs
Als der Modellaufruf fehlschlug, schickte der Server korrekt einen Error-Frame, aber das Widget schrieb die Meldung in ein Element, das der Governance-Trace-Zweig bereits ausgeblendet hatte, und klappte den Trace nie zusammen. Besucher sahen „Reading your message“ endlos pulsieren, bei einem Turn, der bereits fehlgeschlagen war: kein Fehler, keine Wiederherstellung, keine Möglichkeit, es zu erkennen. Der Fehlertext wurde korrekt zugewiesen und nirgends angezeigt. Gefunden während eines echten Ausfalls, als das Guthaben des API-Kontos aufgebraucht war.
| Korrigierter Code, Testläufe |
BESTANDEN |
pass 4, fail 0 |
| Bug wieder eingebaut, derselbe Test |
ABGEFANGEN |
pass 2, fail 2 |
| Datei wiederhergestellt, Test läuft |
BESTANDEN |
sha256 54f8802b444b6194… |
Der Test ist nicht trivial erfüllt: Er schlägt fehl, wenn der Bug zurückkehrt.
Betriebsprotokoll
Was hinter der Plattform existiert und was ungetestet ist. Nur das, was ein Skript oder ein Log zeigen kann.
- Backups: nächtlich um 03:17 UTC, pg_dump --clean --if-exists, gzip; nach jedem Lauf auf ein privates Git-Remote gepusht; neuester
20261003T031701Z; 29 Dumps aufbewahrt.
- Wiederherstellungsübung 2026-10-03: Dump
20261003T031701Z in 2 s in einen Wegwerf-Container pgvector/pgvector:pg16 auf demselben Host wiederhergestellt: 34 Mandanten, 270 Wissenszeilen, 47 Tabellen. Der Dump stammt von 03:17 UTC; um 13:26 UTC entfernte die geplante Demo-Bereinigung einen verwaisten Demo-Mandanten, der älter als 30 Tage war (Gateway-Log), daher zeigt die Wiederherstellung einen Mandanten mehr als das Live-System zum Zeitpunkt der Übung.
- Rollback: Website: tools/deploy-site.sh --rollback (ein zweiter Symlink-Wechsel auf das vorherige Release); Studio: tools/deploy-studio.sh --rollback (vorheriges Image, mit Health-Check).
- Wiederherstellungsziele: keine zugesagt. Der nächtliche Dump begrenzt den Datenverlust auf einen Tag; keine angegebene Wiederherstellungszeit.
- Ungetestet: Last über eine Instanz hinaus; Multi-Region-Failover; Wiederherstellung auf einem anderen Host.
Aus docs/ops-record.json, geschrieben von der Wiederherstellungsübung (docs/runbooks/db-backup.md).
Fragen Sie zu jedem Defekt hier und dazu, wie sein Test die Korrektur belegt.
- Zeigen Sie mir einen echten Bug, den er gefunden und behoben hat
- Woher wissen Sie, dass ein Test fehlschlagen kann?
- Was ist noch offen?